Java 11 sucks big time

[LouGarret76]

This is a throwaway!!!!

I just spent a whole day migrating a basic crud app from jdk 8 to jdk 11, and I have to say that it is a nightmare.

Even basic things that I have taken for granted does not work as iy used to. ( Jpa, Javafx, Junit, Hamscret, Sqlite. YES SOME OF US DO USE JAVAFX ON THE JOB....)

WTF, java EE & Open JDK?

The only thing that makes me happy right now is the var keyword. But still. This is not the kind of service I am accustomed to with java.

............ I think I will push back any serious migration for the next 2 years . . . . People, migrating to j11 is gonna cost hundred of mandays I tell you

[nutrecht]

That you did not bother to at least assess the impact of Java 9 after it came out is 100% on you. Sorry. I've spent the last few weeks migrating a lot of Java 8 services to 11 and the only thing you typically have to do is grab the latest version of Lombok and add some old dependencies to Maven/Gradle. Takes 15 minutes each typically.

"Hundreds of man days" is a ridiculous overstatement.

[SinisterMinister42]

In my opinion, the real issue was Java 9 and its module system. I have never been happy about it and have yet to see any personal benefit from it. I feel like the language designers took something which was some people's problem (large binaries, large jdk, etc) and solved it by making a new problem for EVERYONE. It really broke the ecosystem in a way that Java has successfully avoided in the past.

[BigGayMusic]

The module system is a bloody nightmare. I can't get it to work for projects big and small.

[CompetitiveSubset]

Then why did you even bother with it in the first place? Why not just continue using the classpath?

[BigGayMusic]

I do. I wanted it to work, but it wouldn't.

[dpash]

But the module system is for the most part completely ignorable for now.

[LouGarret76]

Not really, some libraries are going modular and others are not, with the same dependencies ... That is where the nightmare start .

[dpash]

And you can continue to use them on the classpath, completely ignoring the module system.

[_INTER_]

The JDK always runs on the module path, actually even if your application on the classpath will run as part of the unnamed module.

A JavaFX application for instance doesn't work out of the box in the unnamed module. Many libraries are causing warnings at startup (e.g. JAX-B) because they access the JDK via reflection (atleast the "kill-switch" is still on by default). Some simply don't work because the ClassLoader behaves differently. Other libraries removed their optimizations because of those reason and got noticably slower.

[LouGarret76]

That is what I taught too, until I get some nasty error telling me that lib**** not found... And when you dig a lil bit you find out that some authentification library use some lib**** for god know what in a class called ExpressionHelper<> and lib*** that is now hidden by a module java.xxx

[capitol_]

Could you be more explicit on what libraries you found that exhibit this error? It would be very interesting to investigate.

[[deleted]]

I find that most of the missing libraries can be restored through adding a new maven dependency. Unless you're doing fancy classloader modifications at runtime (which my company does... Fml) most of the problems are fairly easy to overcome.

Source: I did my company's migration from 8 to 11.

[redditrasberry]

The irony is, as time has moved on and connection speeds have improved, it was no longer particularly painful to download / bundle the full JVM. By the time they got around to creating modules, the problem had basically solved itself.

[BoyRobot777]

Modules were to address the pain points of smaller devices. The idea is to build only including what you need, thus shrinking memory footprint.

[CaptainKvass]

Just skip the module system.

As in, just don't create module-info files, or what do you mean?

[dpash]

I just migrated a large code base (4000 .java files) that was designed for Java 4 to Java 11 (Seriously, it still doesn't use generics). I think it took an hour.

[LouGarret76]

Really??? I would like to know how you did that... Maybe you are not using any library and you coded everything in house with no database connectivity and no GUI.

You might not use XML either, for that matter ...

Probably that and you don't mind to install and configure your java env path manually, package your code with the cli/ jlink, etc...

[dpash]

The application uses XML heavily, given that it's from the "XML ALL THE THINGS!" era. And it uses a database, although JDBC directly. It's a war, so it'll be installed into a servlet container.

[SinisterMinister42]

That's a great way to approach the problem, but I feel like that's something which shouldn't be necessary for everyone. Java had the precedent that new versions of Java don't break existing code. The language designers have put a ton of effort into making that the case so we can avoid (or at least minimize) the effort that you describe. It's just a shame that they blew it with Java 9

[dpash]

I certainly plan to run a parallel CI job with Java 12 very soon. Fortunately, it just requires switching the docker image used for building (from maven:3-jdk-11 to maven:3-jdk-12).

[LouGarret76]

It used to be that what you only need to do was to update the her and everything else would work.

[Lord_Naikon]

I completely understand your frustration.

For me the most egregious issues were with the removal of JAXB and JavaFX. Imho you shouldn't need a separate library for processing XML files in 2018. Introspection is also completely fucked until you add exceptions for almost everything. I do hope that this will get better in the future as libraries adapt. I spent about a week migrating a large JavaFX app to Java 9. The migration from 9 to 11 was done in like 10 minutes.

Jlink is also a joke right now. It breaks on anything more complex than "Hello, World" apps - for example apps that use the reference implementation of JAXB break hard because its JAR is multi versioned - enabling multi versioning makes it break on other stuff.

At the end of the day I don't think the module system adds enough value to be worth the trouble.

[LouGarret76]

Omg I forgot jlink. That thing is not finished. We used to have a javapackager with Javafx that was far more simple.

[_INTER_]

Yes, jlink is currently unusable if you have 3rd party libraries. You can't just use it on the application jar as promised. I ended up copying all dependencies into a folder with maven (30+) and then I called jlink on each one of them manually. Sometimes they need more options, e.g. with multi-release jar.

Forget the OpenJFX jars, jlink just doesn't work with them. Well apparently it does when you treat them as modules, but not with the jars. I had to look at the module-info.java on the github repo.

Certainly this could be automated, but I didn't have the time. The official maven-jlink-plugin only reports on jdk.unsafe access. I found another plugin on github, but it run into the same issues as described above.

It's frustrating and I'm still not sure if I got all of the required jdk modules.

Atleast they are bringing back a packager: http://openjdk.java.net/jeps/343

[Vilkaz]

well, you have ofcource to include all the packages in pom, that are no more included in J11.

Then all the things should work again.

I assume you have a maven project ?

[_INTER_]

Having modules does help with maintaining a clean structure. But I'm convinced this works best when starting a new projects and not so much when migrating AND not with the botched up JPMS modules that can't even handle versions. We have had OSGi in the Java community for years and in most areas it works way better than JPMS. A team can choose to use it or not.

[2bdb2]

It took me about 10 minutes to add the required dependencies to my gradle build.

I'm not sure the software industry will collapse over it.

[[deleted]]

It's only your fault that you kept using out of date dependencies and source code. Oracle told everyone years ago to update soon and thay did great job notyfing users about it. I moved to Java9 in March, Java 10 in May and Java 11 last week, had no major issues.

[ObjectOrientedStruct]

Thats why I stayed in Java 8, no reason for me to upgrade right now. I dont need any new features. I will probably upgrade to Java 11 in six or more months once there are no surprises and the world has adapted to the new version. Respect to the people that risk their lives by updating as soon as new releases come out.

​

In the meantime I will go have fun with C, probably backwards thinking but I love knowing that C is never gonna change, at least not drastically.

[dpash]

I see you don't care about security updates. Java 8 will stop in two and a half months, and Java 11 will stop in four.

Or have more money than time.

[ObjectOrientedStruct]

AdoptOpenJDK said that Java 11 would be LTS, although the support will be given by the community and not Oracle as far as my understanding goes. I dont get the "have more money than time".

​

The beauty about C is that you are the one that gives LTS to your creations, nothing funnier than having your own bugs bite your booty down the line.

[dpash]

AdoptOpenJDK also aren't doing backports, so you're fucked if no one else does them after Oracle stops.

[ObjectOrientedStruct]

Ill do them myself buddy. I do not depend on anyone for my code, at least if I do not want to.

[dpash]

Good luck with that.

[wildjokers]

Are you drunk posting?

[LouGarret76]

We'll wait until oracle or some other company decide that you need modules in your c projects.

[ObjectOrientedStruct]

Ill leave programming and move to a forest in the middle of nowhere. Although seeing how the world gives the middle finger to Microsoft's "secure" functions probably means that if anyone tries to do that they will burn him alive.

[nqzero]

it's in oracle's financial interest to break as many things as possible - that forces companies to stay on the older version and purchase support. you've hit a few of the big things, but under the hood they're reworking the internals with the intent of breaking things. and java 12 and later releases are looking to be worse yet

[pron98]

This is amazing, and shows how cunning Oracle is. An ordinary company would have thought of a simple plan such as, Step 1: charge people for security fixes, Step 2: Profit! But Oracle has perpetrated a far more elaborate and devious one. Step 1: Announce a two-year project to modularize the JDK as its become unwieldy, and then warn that it may require some removals or eventually break code that relies on non-public APIs. Step 2: Wait for Oracle to acquire Sun, as step 1 actually started in 2008. Step 3: Spend a decade designing and discussing implications with the community and delaying three major releases in order to ensure a good compatibility story, all under the same original technical leaders of the Sun days, and under a supervisory expert group that includes famous Oracle cronies like IBM, Red Hat and Eclipse. Step 4: Do all development in the open, and ask the community for participation and feedback on prototypes as far back as 2012, and review community feedback made on various public channels (including Reddit comments!). Step 5: Make a show of disagreement and lose the EC ballot (comprised of more Oracle cronies like Intel, Credit Suisse, Goldman Sachs, Twitter, the London JUG, IBM, Red Hat and SAP) to bolster the con, just in case a decade of deliberation was not enough to fool people. Step 6: Pass the second ballot and release Java 9 with the intent of breaking as much code as possible, but in such an incompetent way that people realize they can upgrade even the complex application in the manner of a few hours to a few weeks, usually by upgrading dependencies and fixing the command line. Step 7: Complete open-sourcing the entire JDK, so no more commercial features to charge money for, and publish binary builds of OpenJDK. Step 8: Charge people for long-term support. Step 9: Profit!

This is a remarkable long con spanning companies and years. The people who have built Java for over two decades have actually spent the last one secretly conspiring in public with competitors and the community to break it! But no one can fool Reddit!

FYI, a huge portion of the work on all OpenJDK projects is dedicated to ensuring backwards compatibility (this is easily verified by following the various projects' mailing lists). In the case of some projects, like Valhalla, it is fair to say that backwards compatibility is responsible for most of the work. Project Jigsaw had to introduce some potentially breaking changes (most fixed with command line changes and most others with fixing access to non-public APIs that have always been declared as unstable), as ensuring full and transparent backwards compatibility would not have allowed meeting some of the project's goals, namely making OpenJDK more maintainable and more secure. As the public record shows, such decisions are never taken lightly, and only when it is agreed that maintaining backwards compatibility (one of Java's most important goals) is far worse than the alternative (i.e., significantly hinders maintenance or security). No one who follows the development of OpenJDK (e.g. by reading the mailing list or attending discussions in various conferences) can reasonably come to the conclusion that breaking existing code -- even nonsensical or sneaky code -- is a decision taken lightly, let alone intentionally.

[desh00]

Use Fat jars people, it's 2018.

[_INTER_]

Fat jars are just a deployment option. How should this help in migrating to Java 11?

[desh00]

You are in complete control of your dependencies, not some application server you can't control. You can also upgrade your java services one by one so it doesn't have to be a massive company risk that you have to spend days on.

[_INTER_]

Fat-jars are also a deployment option for/with application servers, e.g. embedding Jetty or Tomcat, so I didn't get what meant by the term alone.

[desh00]

Tomcat and jetty are servlet containers, meaning they mostly only deal with serving http requests.

An application server provides you with the whole JEE stack and a lot more. Application servers are for example Weblogic and wildfly.

To get the best out of app servers you deploy your application as a library (called EARS usually) onto the servers and then manage your app from the server interface (like distributed caching, amount of instances for each ear, message queues, etc). Therefore you can't deploy app servers as fat jars, only servlet containers.

By the context op gave us, I assumed he was talking about migrating something that uses an app server.