I think it's a bit premature to call Java, one of the most widely used programming languages in the world, dead or dying. Most software developers may not like the language, but it's about as close to dead as C++... which is to say, not at all.
And Kotlin, Scala, Clojure, Ceylon, JRuby, Nashorn (Node.js for the JVM) all extend Java's life along with the life of the JVM because they all can call Java code easily.
As I mentioned upthread, Oracle's Graal project takes the JVM a few steps further and will probably prolong its life. The currently open part of Graal is http://openjdk.java.net/projects/graal/ the whole project is at http://www.oracle.com/technetwork/or...iew/index.html I'm going to summarize it as I understand it, so I may get some details wrong. I got most of what I know from the video at https://www.infoq.com/presentations/polyglot-jvm-graal
For anyone that doesn't feel like wasting 40 minutes on the video:
1. They want to make an intermediate representation of programming languages in the JVM, so it's easier for more languages to be ported to the JVM, for more of the non-Java languages on the JVM to get near Java level of performance, and also easier for languages on the JVM to interoperate with each other. Right now, for example, it's extremely easy to call any Java code from Kotlin, Scala, Clojure, or JRuby but you have to do extra work with your Kotlin, Scala, Clojure, or JRuby code to call it from Java. Graal reduces that work to call other languages from Java.
2. Graal supports ahead-of-time compilation, so that most JVM applications can be compiled into something that has none of the usual JVM startup overhead in time or memory. The ahead-of-time compilation doesn't support dynamic classloading, though. (Which is only reasonable - you can't compile a class file to native ahead-of-time if the class file isn't provided until your ahead-of-time program is already running.)
But the second item is only available in the Oracle JDK. I'm not sure how it would work with the OpenJDK GPLv2 license anyway - since the AOT compiled code gets some components of the JVM runtime built into the resulting program, I imagine the whole thing has to be released GPLv2. That's fine with me, but none of my employers would like it.
And Kotlin, Scala, Clojure, Ceylon, JRuby, Nashorn (Node.js for the JVM) all extend Java's life along with the life of the JVM because they all can call Java code easily.
As I mentioned upthread, Oracle's Graal project takes the JVM a few steps further and will probably prolong its life. The currently open part of Graal is http://openjdk.java.net/projects/graal/ the whole project is at http://www.oracle.com/technetwork/or...iew/index.html I'm going to summarize it as I understand it, so I may get some details wrong. I got most of what I know from the video at https://www.infoq.com/presentations/polyglot-jvm-graal
For anyone that doesn't feel like wasting 40 minutes on the video:
1. They want to make an intermediate representation of programming languages in the JVM, so it's easier for more languages to be ported to the JVM, for more of the non-Java languages on the JVM to get near Java level of performance, and also easier for languages on the JVM to interoperate with each other. Right now, for example, it's extremely easy to call any Java code from Kotlin, Scala, Clojure, or JRuby but you have to do extra work with your Kotlin, Scala, Clojure, or JRuby code to call it from Java. Graal reduces that work to call other languages from Java.
2. Graal supports ahead-of-time compilation, so that most JVM applications can be compiled into something that has none of the usual JVM startup overhead in time or memory. The ahead-of-time compilation doesn't support dynamic classloading, though. (Which is only reasonable - you can't compile a class file to native ahead-of-time if the class file isn't provided until your ahead-of-time program is already running.)
But the second item is only available in the Oracle JDK. I'm not sure how it would work with the OpenJDK GPLv2 license anyway - since the AOT compiled code gets some components of the JVM runtime built into the resulting program, I imagine the whole thing has to be released GPLv2. That's fine with me, but none of my employers would like it.
Comment