
Java is still available at zero-cost - lemming
http://blog.joda.org/2018/08/java-is-still-available-at-zero-cost.html
======
euske
Honest question: How often do people upgrade their production language?

Me: once in a decade, maybe. I'm still perfectly happy (and productive) with
C# 3.5, Java 7 and Python 2. I'm grudgingly moving forward because the old
toolchains are being deprecated now, but my codes aren't significantly
improved because of a few fancy idioms available in a new language, and it
barely affects the design decisions. Upgrading your library or framework can
be more often, but I tend to still be fairly conservative. Upgrading your
language for production twice a year sounds crazy to me.

~~~
cdoxsey
With Go: every release. Free performance improvements and backwards
compatibility. It also doesn't require anything installed on the server, so
it's just updating a ci script.

~~~
eftychis
Go is kind of special, as it is new relatively and the initial implementation
of every feature is usually the most basic possible. Thus, every new version
there is space for a lot of improvements. What I mean: the garbage collector
is/was for all intents and purposes Dijkstra's late 70s ('78) tricolor
algorithm.

They eliminated re-scanning of the stack on Go 1.7 by adding a hybrid write
barrier which is 90's work (found the proposal:
[https://github.com/golang/proposal/blob/master/design/17503-...](https://github.com/golang/proposal/blob/master/design/17503-eliminate-
rescan.md)). So Go is by no means state-of-the-art performance wise. That is
not bad and has its benefits, one of them being that you can improve with
every release.

~~~
majewsky
> So Go is by no means state-of-the-art performance wise.

Yet Go is blazingly fast compared to most other languages that are widely used
for web server development (except, maybe, Java).

~~~
Recurecur
Well, that's a heavily caveated statement.

It seems, given the end of Moore's "Law", as well as environmental concerns,
that language efficiency will get more attention. It'll be interesting to see
if languages like Swift, Rust, and Julia can gain traction for web
development.

I wonder how uptake has been for IBM Kitura so far...

------
MBCook
I have a friend working at a company that is having “very important”
discussions about this.

They need to keep up with security patches (for obvious reasons) but the six
month limit has them scared. The consensus seems to be that they don’t believe
they can keep up with an upgrade schedule that fast and are thus forced to pay
for support from someone or hope that the community backports security fixes
far enough for the rate at which they feel comfortable upgrading.

It doesn’t sound like they actually know what their upgrade rate would be, but
they’re sure that it’s much slower than six months.

~~~
peanutz454
I am not sure I completely understand the implications of this. But, if
OpenJDK is the reference implementation, and as long as someone is going to
maintain Java 11, there really isn't much to worry. I worked for a company
that completely relies on Java. They also relied on Apache, so they had on
their roles two developers that wrote code for Apache and Tomcat. Making wild
guesses here but - if OpenJDK project gets 300 companies with one contributor
each to write code for them, they will continue supporting Java 11.
Maintaining Java is in some way a responsibility of every company that
benefits from it. Or maybe I am so out of touch with technology that I am
absolutely wrong.

~~~
MBCook
The question is, and we won’t know the answer until this is been going on for
a while, how many releas(es) back will continue to get security updates from
the community.

Will they decide on arbitrary long-term releases? Maybe 11 and 15 and then 19
get three years of support?

Or will the community extend the length of security patch releases by some
sort of fixed margin, say 6 to 12 months, and leave it at that.

Right now no one truly knows how it’s going to work out.

I find it interesting that a company that pushes out updates much more
frequently than every six months is uncomfortable updating the software THEY
use every six months.

It’s not like there should be big breaking changes problems, you can rely on
the TCK to know that your code will continue to work.

~~~
jerven
We know that RedHat is aiming to support Java 11 LTS for a minimum of 6 years
and OpenJDK8 till the end of life of RedHat7.x

Source
[https://access.redhat.com/articles/3409141](https://access.redhat.com/articles/3409141)

------
roenxi
Up until around 2008, clock speed was increasing rapidly and the bottleneck to
systems performance kept changing. Software was being obsoleted in a mater of
years. Then things started changing; evidenced perhaps by Windows upgrades
suddenly becoming a lot less relevant and Apple starting to steamroll more
modular computer builders like Dell.

Mark my words, there will come a day where continuously upgrading software
will start to have a clearly higher cost than old, boring and stable. 2018 to
me is the first year that a software platform can have had a true decade to
stabilise in an environment that isn't constantly shifting and changing at a
hardware level.

Maybe trends like in graphics cards will shake things up, but I believe the
advantage is going to move to stable, slow upgrading, well supported platforms
with large bases of well trained developer. Reducing LTS windows will be a
disadvantage for the Java ecosystem.

~~~
bognition
The drive to move quickly with software wasn't to keep up with ever changing
hardware, it was to respond quickly to the market. Treat every release like an
experiment. The more experiments you can run the more likely you are to
understand and solve the needs of your users.

Why would someone pick software that get feature releases and bug fixes on a
yearly cycle when similar software is available that has weekly or daily
releases.

~~~
Barrin92
>The more experiments you can run the more likely you are to understand and
solve the needs of your users.

There is an interesting chapter for this in Donella Meadows thinking in
Systems

 _Oscillations! A single step up in sales causes inventory to drop. The car
dealer watches long enough to be sure the higher sales rate is going to last.
Then she begins to order more cars to both cover the new rate of sales and
bring the inventory up. But it takes time for the orders to come in. During
that time inventory drops further, so orders have to go up a little more, to
bring inventory back up to ten days’ coverage. Eventually, the larger volume
of orders starts arriving, and inventory recovers—and more than recovers,
because during the time of uncertainty about the actual trend, the owner has
ordered too much. She now sees her mistake, and cuts back, but there are still
high past orders coming in, so she orders even less. In fact, almost
inevitably, since she still can’t be sure of what is going to happen next, she
orders too little. Inventory gets too low again. And so forth, through a
series of oscillations around the new desired inventory level. As Figure 33
illustrates, what a difference a few delays make!_

Faster is not always better, especially in systems with delays. By reacting to
initial cues prematurely you can easily end up in permanent disarray that
simply turns into a chaotic feedback loop. It is often worthwile to upgrade
patiently, so one can actually gauge long-term effects instead of reacting to
noise. Changing the consumer experience is a conversation.

~~~
bognition
We're talking about two completely different things here. I'm talking about
responding to direct customer requests differently which strikes me
(potentially naively) as a different thing than managing a supply chain.

------
mevile
Java moving to 6 month release cycles is good. OpenJDK is good. RedHat
providing long term support is good. All of this is good.

Where I'm worried this fails is with dependencies. Also in the context of
developing plugins for other Java projects. For example building a plugin for
IntelliJ and the different versions of IntelliJ users may have.

~~~
koolba
Java has legendary backwards compatibility and has had that since the first
public release. That’s not going anywhere.

~~~
rhencke
I do wonder if that will be slowly changing under new ownership. Java 9 and 10
had some pretty risky changes, compared to the prior releases. Take a look at
the migration guide.

[https://docs.oracle.com/javase/10/migrate/toc.htm#JSMIG-
GUID...](https://docs.oracle.com/javase/10/migrate/toc.htm#JSMIG-
GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6)

Usually you don't see sentences like 'For every tool and third-party library
that you use, you may need to have an updated version that supports at least
JDK 9.', nor 'Check the websites for your third-party libraries and your tool
vendors for a version of each library or tool that’s designed to work on JDK 9
or 10.' as things to watch for in a Java release.

~~~
MBCook
“Compared to previous releases“ is the issue there.

They removed classes that they had been telling people not to use for...
well... since they were put in.

It had to happen someday. The fact that they let it go on for, what, most of
two decades? That’s commitment to backwards compatibility.

With the new module system they can make sure that this doesn’t happen again.

------
scarface74
Just for comparison....

Microsoft supports .Net Core LTS releases for three years....

[https://www.microsoft.com/net/support/policy](https://www.microsoft.com/net/support/policy)

~~~
flukus
Did they learn the definition of "long term support" from phone manufacturers?

.net 1.1 (I looked this up when I had to install it earlier this week...) was
supported for 10 years until 2013 and as part of Windows Server 2003 (32 bit)
it was supported until 2015 so it looks like they're going backwards too.

~~~
scarface74
.Net Core (open source) and .Net Framework (Windows Only) have different
support policies.

.Net Framework has a much longer support lifecycle.

[https://support.microsoft.com/en-us/help/17455/lifecycle-
faq...](https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-
framework)

------
no_wizard
One could argue that LTS software is just a trap (and a particularly lucrative
one). I know that this is likely a couple factors that allow me to say this
namely

1\. I can rule over our dependency and technology choices with an iron fist if
need be

2\. I live in on post 3.6+ Python as our main language and for anyone with
good CD/CI you can always run your tests against the master branch and latest
dev builds at least one or two versions ahead

Okay so with that said, I feel like LTS versions of software are a trap for
this reason. You end up in situations where there is so much pain with
upgrading that you end up spending more either more time slogging through
incompatibilities in the upgrade pipeline the longer you put it off the worst
this gets, or you end up in situations where you have to maintain a forked
Verizon’s if the code base while you upgrade things or you have to do a lot of
monkey patching and work around to just get things running (famously this is
the approach GitHub used to upgrade from different versions of Rails)

The alternative is to pay money to companies that will maintain the version of
what you are using, but even then you inevitably have to move forward and that
leads to nasty vendor lock in

I personally believe that having a robust CD/CI platform and a well tested
code base allows you to by pass this whole charade. We always have our code
tested against the next next incremental release in testing, the next versions
dev branch and a rolling git pull and build that tests our code base. We
really do expect things to break but it lets us plan with our working code
quite accurately to avoid this problem altogether and now we largely update
pretty close to release cadence.

I don’t know if this helps anyone but I suggest doing software development in
this fashion will save you a ton of headache. Being up to date with rolling
release strategies has helped our productivity immensely because we can think
about our dependencies and we have really whittled down to just a few core
ones l. At a certain point we also formed some of the smaller ones and find
maintaining those ourselves has been a flawless experience

~~~
cwyers
Not upgrading your dependencies in-line with upstream is a form of perverse
technical debt -- perverse because most technical debt is incurred to get new
features/releases quicker, whereas the technical debt from not upgrading is
incurred to simply stay where you are.

~~~
mikekchar
People really don't understand the cost of bit rot -- especially business
people. If it worked 10 years ago, and it hasn't changed, why can't we use it
now? I happen to have an old Rails project that my team has to maintain. Rails
2, Ruby 1.8.7. When we stopped being able to even compile Ruby 1.8.7 with the
latest versions of GCC, I finally got approval to upgrade.

Things that business people can't understand is that nobody supports the
language version any more and you can't build it with modern tools. You can't
run the old OS any more, which has the old tools to build your code because
the OS doesn't run on new hardware. I've been in the situation where I've had
a server that was practically unique. It was so old that the only hardware
that could run it, was the machine that was already running it. If that died,
it was game over. (I should probably mention that I tend to specialise in
difficult legacy situations in my career ;-) ).

The idea that you need to do maintenance work on your software, _even without
fixing bugs and without adding features_ , is incredibly difficult for
business people to swallow. So they naively allow the situation to get very,
very bad (and then they have to hire someone like me).

~~~
cwyers
Right. If you stick with the herd, it's easy to find other people who are in
your situation and share the burden of upkeep. Sticking on a platform past its
prime means taking on a far larger share of the support burden yourself.

------
needle0
Nice idea on clarifying what the word "free" means in this context (gratis,
not libre) by prefixing it with a dollar sign. This is the first time I saw
this, is this usage widespread?

~~~
medgno
I've never seen it either and found it to be immediately clear. I wonder what
similar prefixes could be used for "libre not gratis" and "libre and gratis".
I know that "Free" could stand in for the second, but it's more ambiguous than
"$free" was in this article.

------
ToFab123
On a scale from 1 - 10 it gonna suck 15 when the tech you rely on is being
bought by Oracle.

~~~
afroboy
Actually Java got saved by Oracle, and Java 8 would never happened under Sun
management. let's say Java got mush mush better under Oracle. i know how hard
the truth is by telling someone Oracle did something good but actually it did.

~~~
iamcreasy
I didn't keep up when it happened. What happened with Sun?

------
bradleyjg
The TL;DR is that Red Hat and IBM are going to take over from Oracle as
primary maintainers of java 8 (in the form of openjdk) after January 2019.
That is likely to last through at least 2022.

Going forward Oracle will be primary maintainers of openjdk for each new
version of java for six months. Every third version (starting with 11) the
hope and expectation is that RH, IBM, et al will take over after those six
months are up and continue to support those versions for at least several
years.

~~~
flukus
That sounds like a disaster, the developers at oracle no longer have any
personal incentive when it comes to producing quality, maintainable software
because it is no longer a problem they have to deal with. Because they're not
feeling any personal pain from bad decisions they will no longer learn from
them.

This is close to the consultancy business model that's been at the root of so
much bad software.

~~~
MBCook
What makes you say that? The Oracle JDK IS the Open JDK, only with a few extra
features. At least that’s my understanding. A shared code base.

If they do a terrible job of sticking a feature in they’re going to have to
keep handling it until it’s cleaned up or removed.

------
lowry
The author exposes his agenda by downplaying Oracle's decisions that impact
Java availability to businesses and FUDing other options, e.g. he says that
RedHat will push security fixes to OpenJDK first and repackage afterward, as
if it was something bad.

------
sleepychu
What does this mean for me as an engineer who writes Java every day?

~~~
agibsonccc
Use openjdk instead. By default on linux, that's what will continue to happen.
You won't really be impacted by this.

~~~
MBCook
There’s no need to use Open JDK.

If that’s your preference or you have some other reason (like the fact it’s
probably pre-installed in a Linux distribution) there’s nothing wrong with it.

But there’s absolutely no need for a developer to switch off of Oracle unless
you absolutely cannot move to Java 9 or newer.

~~~
jerven
Java 9 is already no longer supported. If you haven't moved yet go directly to
11.

As after 11 there are no features in OracleJDK that are not in OpenJDK I would
think moving to the vendor supported (Open)JDK on your linux system is the
smart default thing to do.

------
tannhaeuser
Was RMS right after all?

[1]; [https://www.gnu.org/philosophy/java-
trap.en.html](https://www.gnu.org/philosophy/java-trap.en.html)

------
adamson
> Build OpenJDK yourself. [...] I suspect this not a very realistic choice for
> most companies.

Are they saying that most firms don't have the ability to build software
themselves, or is this a situation particular to Java where they don't
backport security patches and most firms aren't on the latest major?

~~~
MBCook
Right now I would expect that basically every company using Java is using the
official Oracle version. They’ve never had to worry that they can’t get
security patches for the version released 14 months ago.

Practically everyone can use OpenJDK as a drop in replacement. But right now
we don’t know how long security patches will continue for each release.

I would hope most firms are on Java 8 now. It wouldn’t surprise me to see
people who are still on six or seven.

Nine/ten had a compatibility break (by removing access to internal packages
that no one was supposed to be using). Many companies haven’t upgraded because
of that. Lots of very popular Java libraries weren’t ready or depended on
other libraries that weren’t ready, so upgrading may have been difficult even
if you wanted to.

That seems to be a one time thing though. At this point I don’t see why
companies shouldn’t be able to upgrade relatively frequently to the latest
major release.

------
didip
I am not well-verse in Java world and curious about one thing.

The valuable part of Oracle JDK is the GC. For example G1 is only going to be
available on OpenJDK 9. What if there's a new GC being developed, will OpenJDK
have the new GC?

~~~
MBCook
My understanding is that Open JDK is where all Java language development takes
place now.

It’s only some special enterprise features that aren’t part of the language
itself that are restricted to the paid version of the Oracle JDK.

~~~
jerven
Were (past tense) there is nothing in Oracle JDK 11 that is not in OpenJDK 11.

~~~
MBCook
Oh, I thought there might still be some high end EE stuff.

Thanks for the clarification.

------
wheresvic1
Kudos to RH. Here's hoping that we don't have to keep adding JIRA issues to
update Java every 6 months. I have enough of this on the Javascript side as it
is..

------
pejrich
If Java is open and free, then why did Android decide to rewrite Java? I
notice a lot of companies seem to avoid Java so there must be some sort of a
catch.

~~~
realusername
Android is quickly moving away from Java to make Kotlin the default language
nowadays, it's probably in part due to the Java lawsuit (and in part to add
language features quicker without changing the VM).

~~~
pjmlp
They aren't rewriting the Java parts.

Kotlin just gets an additional library to make some SDK usage a bit easier.

~~~
realusername
No indeed but they are clearly phasing out Java as the default language in the
future, I don't see much plan to fully adopt Java 8 (only partial support for
now) and Java 9 (no support) for Android. Since they are using their custom
ART Runtime, it's not even impossible they would add VM instructions specific
to Kotlin in the future (I don't have any knowledge of that yet but that would
not surprise me).

~~~
pjmlp
That will only happen when Android Frameworks and lower level stack gets
rewriten in Kotlin.

No mention of Kotlin in Treble documentation, only Java and C++.

It is like hoping UNIX derivatives will use anything other than C on their
kernels.

AOSP commit messages show initial support for Java 9 and their clamp down in
reflection for private APIs done in Android P seems to be a step towards Java
modules.

I see an easier path just rebooting everything with Fuchsia than having them
rewriting Android in Kotlin.

------
TJSomething
Where is this is going to leave GraalVM and JIT for ARM? I believe both of
those are exclusive to Oracle. And I was kind of excited to use GraalVM.

~~~
kjeetgill
GraalVM has two versions, CE and EE. EE is closed but CE is open.

------
littlesheephtpt
Boy, that Ask.com toolbar must be super lucrative.

~~~
FactolSarin
Java: malware the moment you click install!

~~~
bitmapbrother
The irony is that you probably use Windows - the world's most insecure,
malware, virus and ransomware ridden OS in the world.

------
hyperpallium
Java is still available at zero- _price_

------
exabrial
Adoptopenjdk! Azul! OpenJRE! J9! choice is a great thing!

------
spydum
what worries me most is the muscle memory of developers downloading Oracle jdk
from oracle. If Oracle keeps is dark patterns, thousands of developers will be
using the commercial tool and on the hook for license fees.

~~~
sdinsn
That is not how it works.

You can download the Oracle JDK and use it forever, commercially, for free.
You just won't get updates backported to your version unless you pay for long
term support.

~~~
spydum
Find that in writing. Everything I read says jdk 8 is the last free Oracle
jdk.

~~~
kjeetgill
Then read the article you're commenting on?

~~~
spydum
I did. Here is the money quote:

Firstly, it is not clear that there will be an Oracle JDK that is $free to
download. Despite my best attempts, I could not get 100% clarity on this
point, but see also this tweet.

~~~
MBCook
Oracle has never announced that they’re charging for their JDK. In all the
talk over this stuff over the last few years they’ve never said that. They’ve
been quite clear that it will still be free to download.

The only change is that free security patches will now be limited to six
months after a release.

------
drivingmenuts
Maybe it's time to start moving away from Java?

~~~
projektir
I'm curious what your preferred alternative to Java is?

~~~
scarface74
.Net Core. It’s maintained by a company that actually knows how to support a
platform.

~~~
tannhaeuser
The alternative is, and always has been, a language and runtime lib that is
spec'd in the open and has multiple implementations to choose from. Though
choices have become limited. Only C, C++, and JavaScript seem to fit the bill
AFAICS.

~~~
nextlittleowl
Or LISP.

~~~
svetlyak40wt
Common Lisp?

