Hacker News Reader

Comment by ocdtrekkie | Hacker News Reader

Meanwhile, most enterprise apps still seem to only work with JRE 8. And those which I know of have elected to replace Java rather than upgrade.

View on HN

8? I see more 7 or even 6. Until recently I actually thought 8 was the latest until I needed to develop a small project and discovered we were at 11.

Actually, looking at the version history, I guess it's not weird that I thought 8 was pretty recent, as until 1.5 years ago (Sept '17) it was actually the latest and it is still supported until 2020 (unlike 9 and 10).

    v6  2006
        2007
        2008
        2009
        2010
    v7  2011
        2012
        2013
    v8  2014
        2015
        2016
    v9  2017
    v10 2018 
    v11 2018 again
    v12 2019

Java 8 is supported until 2023.

Funny enough, Java 11 will be end of life the following year. It's not even worth migrating to, better jump to java 15 then.

https://access.redhat.com/articles/1299013

Java 11 isn't worth migrating to because it's end of life is 2024, more than 5 and a half years from now? That's a little extreme.

You have to realize that the first LTS release after 8 was v11 which was released only a bit over 6 months ago. V12 is a non LTS release. So v8 is going to be around for a while. Adding to this is the rather substantial refactoring that happened due to the introduction of modules in v9. This is creating more than the usual amount of porting headaches. IMHO v8 to v9 was by far the most disruptive Java release ever in that sense.

Part of the issue is that a lot of libraries target jdk 8 since that's what Android supports.

Actually libraries that target Android need to use Java 7, unless they want to constrain their users to API 26+.

Is newer Android fully JVM-8 compatible? It'd be great to be able to start using Scala 2.12 even if it means I have to restrict to new devices only.

Not really, a lot of desugering still takes place into DEX bytecodes.

Stuff like lambdas take extra memory, because they convert into anonymous innerclasses instead of invokedynamic.

As far as I'm concerned that's an implementation detail. If I can take arbitrary JVM8 code and run it and expect a correct result then that's a huge improvement for my purposes.

What are they replacing it with?

I see a lot of business apps that use Java on the client side with the JRE. From my observation, they're tending to move towards HTML5 clients, rather than updating to more modern Java versions. The fact that the January 2019 security update, 8u201, is the last version of Java 8 commercial entities can use for free, has pushed this a bit, it seems.

> The fact that the January 2019 security update, 8u201, is the last version of Java 8 commercial entities can use for free, has pushed this a bit, it seems.

Isn't OpenJDK providing updates for Java 8 through to September 2023? 8u202 is published ...

https://adoptopenjdk.net/support.html

I wonder how many of that web-based client solutions (outside of SV) will be built on Oracle APEX.

What stacks are being picked by enterprise for these sorts of projects? C#?

Well, most of JavaEE is still stuck on JDK8, unfortunately. Last I heard that Payara is maybe getting JDK11 support in Q2, and OpenLiberty currently only supports JDK11 on OpenJ9.

replace with another jvm hosted language ? like scala / kotlin /clojure ?

We have quite a couple of them running happily with Java 11.

Were there any hiccups in the upgrade?

Donald Smith the (one of?) product manager of Java at Oracle did a talk for the London Java Community[1] recently. He briefly mentioned that getting onto Java 9 was the hard part, 10->11->12 are significantly easier due to the far smaller number of changes in the release.

The meetup was recorded[2]. I can't tell you how far through he mentions it, but its a good talk to watch as he goes into some of their rationale for their approach.

[1] https://www.meetup.com/Londonjavacommunity/events/258987722/ [2] https://www.youtube.com/watch?v=RWpo92OBaNA

I've done this a few times. Most are due to reflection limitations with the newodule system.

They can be worked around by adding exceptions to removal of reflection metadata largely. Kinda a PITA but not too hard.

Active libraries have pretty good Java 11 support these days though. It's really improved a lot on the past year or two

> Active libraries

So my upgrade is going to be tremendously hard for this application, then. Good to know

Haha yeah it might be a PITA. Unless your app is huge it shouldn't take more than a couple days though.

Basically a compile run fix reflection loop until you stop getting errors :'(

To Java 9 yes, mostly due to third party dependencies and the move to modules.

To Java 11 you might have additional hiccups when using JavaFX, or the JEE libraries that were also being bundled with the Java SE.

Which wasn't our case.

Reply on news.ycombinator.com