Slashdot Mirror
'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."
"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."
I bet there's more new code being generated for Java than pretty much any other language for one simple reason, Android.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I know of no new development done on java applications
Come on, Java server development is still going strong
I mean, some companies are still using Cobol, and you think Java is going anywhere?
Not to mention not all Android developers have moved to Kotlin, that is a many year process - in the meantime there is a ton of Android Java code, and even new apps being developed in Java until widespread Kotlin expertise ramps up.
"write once, run everywhere". fucking pack of lies that is.
Why? That actually worked well. In the past I worked on desktop Java apps that I could run across various systems (and still work today).
When I moved to server development, we would sometimes shift between systems like Solaris and Linux or some BSD variants, but while we may have had to tune the VM we did not change the code...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
No one in your company doing Java? Well that settles it, shut it all down! Java is the #1 language but TheGreatefulNet doesn't use it in his company, time for all Java development to cease.
I don't think Java is dying or anything like that, but a lot of Android development is being done in Kotlin now.
Many large new projects are in Java at companies like Google and Amazon. Google doesn't use Python for big projects, but instead picks C++, Java, or Go.
I also have no idea how India was brought into this.
Java is as fast as C for the most part and is the backbone of a significant number of applications. Python could not handle the set of problems Java has solved and continues to solve. Call me in twenty years when Python has done something other than fill in some small gap in the computing space. That is all.
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.
Enjoy life! This is not a dress rehearsal.
> 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.
I'll see your senator, and I'll raise you two judges.
"It will probably be big and popular in another 20 years"
No, Oracle has pretty much fixed THAT problem, I'd say.
The real problem, and this is a problem that many newly created languages and systems have decided to happily and neglegently copy, is the fact that Java was the first language to merge it's grammar and it's libraries under a single banner.
It was an idiotic idea then, and it's an idiotic idea now. Because of this one core terrible decision, backwards compatibility is now a nightmare for literally anything that follows this ridiculous paradigm.
With C/C++, there is the core language. Because of that modularity, each can be updated independently of the other unless the core language introduces a breaking change. Which it generally doesn't, because the people overseeing C still have the ethics required to put their target audience first before their own personal convenience.
Java: write now, wrong later.
Extraordinary claims demand extraordinary evidence.
If you want a program to execute under a second, then write it in C, or another compiled language.
However, if the program is likely to be running a minute or more, than a well written Java program will most likely out perform a well written C program. Because in Java, the code parts that are executed intensely, will be compiled into native machine code optimized for that run time profile by the Just-in-Time Java compiler that is part of the JVM. The JIT can even in-line code that is at the end of a long pointer chain.
Big enterprise applications running on on big multi-core count computers with a terabyte of RAM can make effective use of Java for long running programs. As the JVM makes good use of the multicores and gobs of RAM.
I once ran a silly benchmark, and found that the JVM/JIT had created 2 threads to run code in the same method, because it had found that my 2 large for loops could be run in parallel.
I have programmed in over 25 languages, including COBOL, C (I actually was paid to teach C to experienced programmers one year), ARM3 assembler, and Python. Found Python had some good points, indenting eliminated brackets and no need for lots of semicolons, but I found it too gimmicky and didn’t handle multi-threading very well compared to Java.
I’ve found Java quite effective for writing short programs of less than 100 lines to explore mathematical ideas, like how many polygons can meet at a snugly at a point(see http://math.ucr.edu/home/baez/...). So Java does not need massive projects to be really useful.
Cross platform support is also good. I wrote a Java Application to find duplicated files on my Linux box, and a friend had no problems running it on his Microsoft box.
I find Java is my favourite language, though I also have things I don’t like about it. No language is perfect, and there are many considerations to be taken into account for selecting a language for development.
I'm not surprised that Java 9 and later is seeing limited traction, especially since you still have to jump through hoops to download the JRE for Java 9 or later.
If you actually go to Oracle's Java.com runtime download site, they suggest the latest version of Java 8.
I program in Java professionally, and I have to say you really did a good job explaining what's good about Java in your post. The multi-threading thing in particular is a huge deal, as I haven't found another language that truly excels at multi-threaded development like Java does, at least with the same quality of life as Java provides (languages like Python and Ruby provide better development quality of life in my opinion, but without the excellent multi-threading support...or a type system, and many other things that would take a while to get into).
I also feel like recent improvements to the Java language (basically Java 7 & 8) may give it a new lease on life, though I think the long term picture for Java is pretty grim, because it's held back by historical baggage and Oracle. In particular, even if Java doesn't lose ground to newer non-JVM languages like Python, then Java will lose ground over time to Kotlin and other JVM-based languages like Scala or Groovy. These newer JVM languages simply don't have the historical baggage of Java (and if you love Java but haven't tried out Kotlin you really should).
Also, another problem for all of these JVM-based languages is that Oracle's recent licensing of the JVM is troubling. That said, it can survive this thanks to OpenJDK and other open source JVM initiatives, but we may be in for some rocky times in Java-land.
I’ve found Java quite effective for writing short programs of less than 100 lines to explore mathematical ideas, like how many polygons can meet at a snugly at a point(see http://math.ucr.edu/home/baez/...). So Java does not need massive projects to be really useful.
I recently discovered and learned Julia, and I think it's the ideal language for these kinds of math exploration problems. It combines the raw firepower of languages like C and a developer quality of life that exceeds even the best languages I've seen previously. It's very popular with the High Performance Computing crowd. It has high level features that no other popular language has, such as multiple dispatch, though it manages to be a very practical language at the same time. It also has some surprisingly nice libraries in certain areas, like their graph theory library. I think it has a very bright future ahead of it. If you haven't tried it, you really should (or if you tried it a few years ago, you should give it another spin now that it's at version 1.0).
That said, even Julia isn't perfect (yet?). Right now the biggest problem is that while it has excellent HPC support, it's still lagging behind on its multi-threading support. Basically, it currently assumes that you are fine with running your additional threads inside other processes (possibly on other machines), and Julia makes this very easy for the developer to accomplish, though it's not quite the same as having cheap in-process threads like in Java. Another issue, specific to enterprise development, is that the ecosystem is still evolving VERY rapidly, even though the language has finally settled into version 1.0, so libraries shift under your feet all the time (though fortunately, they have a top notch package management system to handle library versioning). Oh, also start up times can be pretty bad due to how compilation works (basically, you can pre-compile code, but it's easy to end up having to compile at least some of the program on startup rather than ahead of time), but there are solutions to this most of the time and it buys a lot of positives (though it can be especially annoying when a library didn't optimize their startup times).
I'm also somewhat concerned about the use of garbage collection in Julia. Some recent results make me think that automatic reference counting may be the future in this area. While this concern applies to Java as well (there's a reason Java programs are so memory hungry!), it's compounded in Julia because it complicates the bridging of C and Julia, which would otherwise be seam