'Java 9, It Did Break Some Things': Oracle Bod Admits To Developers Still Clinging To Version 8 (theregister.co.uk)

Java has a problem -- the language and platform is evolving faster than ever, but many developers are stuck on the five-year-old Java 8. From a report: So why have developers not upgraded? Simply, Java 9 introduced major changes, including internal restructuring, new modularity (known as "Project Jigsaw"), and the removal of little-used APIs. These changes broke code, and even developers who are happy to make the necessary revisions have dependency issues. "We have problems with libraries that do not yet support the latest versions," said one QCon attendee.

"I want to explain why it was necessary," said Oracle's Ron Pressler, part of the Java platform group developing the language and lead for Project Loom. "There are billions of lines of code in Java, and Java 9, it did break some things. The reason is that Java is 20-something years old. It will probably be big and popular in another 20 years. We have to think 20 years ahead. The way the JDK was structured prior to Java 9 was just unmaintainable. We could not keep Java competitive if we had not done that change. That was an absolute necessity."

Comments

Too complex for new users

[bradley13]

Grumpy old man here, but a Java developer. Java is not, and never will be a functional language. Nonetheless, Java 8 just had to introduce lambda expressions, so that wannabes could kinda, sorta pretend that Java was functional. The main effect of lambdas, however, is to hide data types, so that weak developers don't actually know what interfaces and data types they are using.

So, doubling down on stupid, they introduce "var", so those weak developers really don't have to know what types they're using. Java will figure it out, or you can play pinball till it works.

Project Jigsaw, was it really necessary? Maybe, but I'm not entirely convinced. Certainly, the new module system is a PITA, since you now have to deal with both module-paths and class-paths, plus of course getting the permissions right.

Now, I know that Java is used for a lot of backend stuff, but JavaFX finally made Java actually really good at GUIs. Swing was a buggy mess that no one seemed to want to fix, but JavaFX got a lot of things really right. So, of course, Java 11 removed JavaFX from the core, making it a PITA precisely because of the module system introduced in Java 9.

- - - - -

Here's the important bit: Nowadays, I am a college professor, and I am faced with a problem: Students new to programming can no longer start with a current version of Java - the changes in Java 9/10/11 have made things just too complex for new users. I have rolled back to Java 8 for the moment. I have spoken with a number of other college level Java instructors, all of whom feel the same way.

The long term question will be: what language do we teach in our programming courses? It is entirely possible that we will move to a different language.

When your language is no longer being taught in schools, well, that's the beginning of the end.

Re:Would you start with Java today?

[DickBreath]

> If you are a Java guy . . .

Yes.

>would you start anew with Java today

Yes.

Java has excellent development tools. Fantastic story on refactoring of large code bases.

Java is very mature. Battle tested. Industrial Strength. Java has a history of backward compatibility better than most other languages. Especially Python 2 / 3, just to pick one example.

Java has an industrial strength managed runtime platform. First the Java (or Scala, Kotlin, etc) compiler translates your source code into JVM bytecode. That bytecode is platform neutral. When you start your program on the JVM (Java Virtual Machine), it initially runs by interpreting your bytecode. All your functions are dynamically profiled for cpu usage. The JVM watches for a CPU hotspot. That is, some function that is getting a higher than average cpu utilization.

As soon as the JVM detects a hotspot, that code is immediately dynamically compiled to native code by the C1 compiler. The C1 compiler rapidly generates un-optimized native code. That code is also scheduled by be recompiled by the C2 compiler in the near future.

Before long, the C2 compiler comes along and spends significant time compiling that code into highly optimized code. In aggressively inlines code. It is able to do optimizations that no "ahead of time" compiler (such as C) can do. This is because the C2 compiler can see the "entire" program. That is, all possible code that makes up the entire program which is running. So the C2 compiler can make changes that an ahead of time compiler cannot make. Even though different parts of the entire running system may be been written by different authors, at different periods in history. Furthermore the C2 compiler can compile into code that is SPECIFICALLY for the processor you are running on, including any processor specific extensions, like SSE2, etc. Again, something an ahead-of-time compiler (like C) cannot do and be able to run on all x86 processors. (But remember JVM bytecode runs on any JVM, even on microprocessors not yet invented today -- without recompiling your source code.)

Now imagine this. Your function calls My function. Both your and my function are dynamically compiled, and C2 optimized Your function by inlining My function into your code. Next, for some reason, My code is dynamically reloaded and updated within the running JVM. Now Your function has a stale copy of My old code. The JVM immediately switches Your code back to running Your bytecode via an interpreter. Before long, if your code is still a cpu hotspot, it will again get recompiled first by C1, and then later by C2.

Java's C2 compiler has been described as being probably one of the most sophisticated compilers there is -- even though its "source" language is JVM bytecode.

Next is Java's GC. Like Java's native compiler, Java's GC is the product of two decades of research by many researchers (due to the platform being open for many years). Java offers multiple GC choices. Each garbage collector offers multpile knobs for tuning your workload to run best. There presently is one company (Azul Systems) that makes a proprietary Java runtime with a proprietary GC that handles memory heaps of HUNDREDS of GIGABYTES. (yes, you read that correctly) And has only 10 ms GC pause times. The latest thing is Red Hat's Shenandoah GC which can handle several TERABYTES of memory with 10 ms GC pause times. Also the new ZGC that similarly handles TERABYTES of memory.

Why such big memory heaps? Because Java can run concurrently on many CPU cores (the most I've heard of is 768 cores) with lots of memory. Yes, folks, Java is used for SERIOUS workloads.

Even if you don't like Java the language, other languages compile to JVM bytecode -- and many can all interoperate with each other. The JVM (java runtime) is an industrial strength battle tested runtime for serious workloads.

Please call me when your Python or Node.js can do that.

I hope that answers your question.

Re:Change the motto:

[Anonymous Coward]

Java: write now, wrong later.