OpenJDK 14 Has Some Performance Improvements But OpenJDK 8 Still Strong

[Delgarde]

That and IBM WebSphere still doesn't offer anything higher than Java 8 atm, unless you want to use Liberty

Yeah, Java 8 persists in enterprise because the big vendors are so slow supporting anything newer. Even WebLogic — an Oracle product, and in theory the flagship application server — doesn't anything past 8 yet.

[Delgarde]

And Java 9 didn not break any backwards compatibility. Java 9 simply put a mechanism in place to keep internal classes from being outside accessible. Several libraries were making use of those classes (despite there being a warning from day 1 that that may create compatibility issues). Module system was postponed from Java 7 to Java 8 and eventually Java 9 largely to give those libraries time to adapt.

Actually, he's correct — Java 9 and later *have* dropped a number of public APIs... notably, CORBA and JAXB. It's the right thing to do — they should always have been external dependencies instead of tying them to Java release cycles — but it's a breaking change for a lot of enterprise apps which now need to ship them as external dependencies...

[bug77]

Not if you are deploying your Java applications to Kubernetes in Docker/OCI containers, and you care about reducing the size of the images as much as possible.

You can't use the module system reliably, in part because several high-profile libraries haven't been converted to modules yet. When you can't use something reliably in production, you don't use it at all

I mean, look at this guy: https://jaxenter.com/java-14-intervi...tz-169860.html (second question)
He needed not one, but two Java Champions (yeah, I know, they're not what they were once) to figure out how set up the project.

[Michael_S]

I'm quite sure that you all Java haters has been saying for years that Java is too verbose and painful to write, and now I discover that we Java developers use it because it is FAST to write code with it?

Nice!

So, i give you some hint:

* Java is nice to work with, and it gives you performances too!
* It gives you an ecosystem of tools without equals.
* It allows you to write portable, maintenable and robust code.

Stop hating, or at least try to get better doing it!

I've spent the last fifteen years working in java and I *do* hate it. But crucially, I don't hate it for performance reasons and it bugs the hell out of me when people spread FUD about Java performance.

[bug77]

Actually, he's correct — Java 9 and later *have* dropped a number of public APIs... notably, CORBA and JAXB. It's the right thing to do — they should always have been external dependencies instead of tying them to Java release cycles — but it's a breaking change for a lot of enterprise apps which now need to ship them as external dependencies...

CORBA may have gone the way of the Dodo (I wouldn't know, I managed to never run into it in over 15 years of Java ), but JAXB is still there: https://docs.oracle.com/javase/9/doc...d-summary.html
If modules did their thing, being in the JDK or an external dependency wouldn't even matter much. Sadly, this not the case just yet.

[caligula]

I've spent the last fifteen years working in java and I *do* hate it. But crucially, I don't hate it for performance reasons and it bugs the hell out of me when people spread FUD about Java performance.

Java doesn't really differ from C, Python, or PHP here. People are stuck with old versions and the new ones still aren't good enough. For example not everything listed here has been fixed yet https://eev.ee/blog/2012/04/09/php-a...of-bad-design/

The Graal platform is probably a step in a better direction, but having spend few hours compiling stuff with Graal, I'm not really convinced. It's a horribly complex platform for just compiling stuff. Also having any reflection in the mix makes it amazingly brittle. Also look at the compile time - it's absolutely abysmal compared to similar size projects & gcc.

JavaFX might be ok, but it's still slower than many gaming oriented native libraries. People also expect weakly typed web languages these days, not something compiled.

Java also desperately needs better compilers for data oriented programming. The lack of unsigned types and inability to disable array bounds checking by force makes many standard algorithms twice as slow as C/C++.

[Michael_S]

Java doesn't really differ from C, Python, or PHP here. People are stuck with old versions and the new ones still aren't good enough. For example not everything listed here has been fixed yet https://eev.ee/blog/2012/04/09/php-a...of-bad-design/

The Graal platform is probably a step in a better direction, but having spend few hours compiling stuff with Graal, I'm not really convinced. It's a horribly complex platform for just compiling stuff. Also having any reflection in the mix makes it amazingly brittle. Also look at the compile time - it's absolutely abysmal compared to similar size projects & gcc.

JavaFX might be ok, but it's still slower than many gaming oriented native libraries. People also expect weakly typed web languages these days, not something compiled.

Java also desperately needs better compilers for data oriented programming. The lack of unsigned types and inability to disable array bounds checking by force makes many standard algorithms twice as slow as C/C++.

I think Java made an enormous leap forward with version 8 (lambdas, streams, default method implementations in interfaces). And releases since then have added nice factory methods for immutable sets, lists, and maps (hash tables in other languages, not function application), type inference for local variables, multiline strings, better case statement syntax, and more. So despite the warts, those are all big improvements and I see the gap between Java and Kotlin, for example, being chipped away.

But as I've said in other threads, I've come to believe inheritance is a mistake. Object-oriented-programming by interfaces and implementations is fantastic. But just about every non-trivial proprietary and open source Java project I've encountered has descended into inheritance hell. At work they pay me a lot of money to do battle with a twelve year old million line monstrosity that has five level class hierarchies all over the place and ten level hierarchies in a few. But that kind of madness is not an oddity in my experience with Java.

I'm sure many other programming languages and their features lead to separate sets of anti-patterns. But after you turn 82 corners in the Java world and bang your head into inheritance abuse at each corner, you come to realize the problem is the language and not just the engineers.

The languages Haskell, Go, Rust, Julia, and Zig, among others, were designed with the conscious choice to omit inheritance. Granted, the industry is dominated by languages that do have inheritance: C++, Java, Python, C#.

[Delgarde]

CORBA may have gone the way of the Dodo (I wouldn't know, I managed to never run into it in over 15 years of Java ), but JAXB is still there: https://docs.oracle.com/javase/9/doc...d-summary.html
If modules did their thing, being in the JDK or an external dependency wouldn't even matter much. Sadly, this not the case just yet.

Strictly, I think that both are _technically_ still included in Java 9, but you need to pass certain command-line options to make them available... they've been moved to modules not included by default. For practical purposes, that's still an API break, since code importing them will no longer compile or run without additional work.

As to modules, I think that's been a total failure. The concept was compelling when they first announced it, but nobody seems to actually be using it... e.g. libraries may support it, but they rarely mention modules in their documentation... project-templates like Spring Initializr don't create module-info files, development tutorials never use it. Pretty sure that long-term, everyone is staying with the Maven/Gradle approach, nobody using the platform support....

[Jonjolt]

Java doesn't really differ from C, Python, or PHP here. People are stuck with old versions and the new ones still aren't good enough. For example not everything listed here has been fixed yet https://eev.ee/blog/2012/04/09/php-a...of-bad-design/

The Graal platform is probably a step in a better direction, but having spend few hours compiling stuff with Graal, I'm not really convinced. It's a horribly complex platform for just compiling stuff. Also having any reflection in the mix makes it amazingly brittle. Also look at the compile time - it's absolutely abysmal compared to similar size projects & gcc.

JavaFX might be ok, but it's still slower than many gaming oriented native libraries. People also expect weakly typed web languages these days, not something compiled.

Java also desperately needs better compilers for data oriented programming. The lack of unsigned types and inability to disable array bounds checking by force makes many standard algorithms twice as slow as C/C++.

Graal isn't just the native image tool, check out this video from Twitter https://www.youtube.com/watch?v=PtgKmzgIh4c

Also Java can remove bounds checking in the (C2 I think?) if it finds it safe to do so.

[bug77]

Strictly, I think that both are _technically_ still included in Java 9, but you need to pass certain command-line options to make them available... they've been moved to modules not included by default. For practical purposes, that's still an API break, since code importing them will no longer compile or run without additional work.

As to modules, I think that's been a total failure. The concept was compelling when they first announced it, but nobody seems to actually be using it... e.g. libraries may support it, but they rarely mention modules in their documentation... project-templates like Spring Initializr don't create module-info files, development tutorials never use it. Pretty sure that long-term, everyone is staying with the Maven/Gradle approach, nobody using the platform support....

Not disagreeing with the first part, that is correct.

About the second part: the problem as I see it is until the native tool takes off, the only thing you can do with modules is the same thing we've been doing for years and splitting stuff into an API and one or several implementation JAR files. But that will take a (long) while. My gut feeling is Java is actually running out of contributors.
If Java truly broke compatibility at version 9 and required the use of modules, the landscape might have been different today. Still we'd gain little in return, download size is just one (and probably the smallest) problem Java has in microservices world.