This AOT compilation feature is interesting, didn't know that it is in JDK9 ... will it allow JDK9 libraries run on iOS? http://openjdk.java.net/jeps/295
AOT initial release in JDK 9 is provided for experimental-only use and is restricted to Linux x64 systems running 64-bit Java with either Parallel or G1 GC.
It sounds interesting until you remember what a hassle native compilation is:
1. you need to compile on the exact same CPU make on model that you will run on (for now there's not cross compilation)
2. you need to compile with the exact same memory settings, including GC selection, that you will run on
3. unless you're cool with binaries that are hundreds of megabytes you will first need to do a profiling run an determine which classes and methods you want to compile
4. you will need to decide if startup time or ultimate performance is more important than you
5. in the end you probably get a better startup time out of -noverify
So Jigsaw modules are shipped as part of JDK9 even those the JSR was rejected by the community (well, IBM, Redhat, and Maven/et al)?
I wonder how this is going to play out if it starts getting use. I'm guessing we'll see two types of jars published on Maven, maybe Jigsaw enabled and regular? (e.g. <classifier>jigsaw</classifier>?)
Is that why JDK9 is 350MB (Windows x64) vs 190MB for JDK8u144? I'm off to go explore more, but for something that's meant to be smaller and more modular, this was a bit of a surprise!
Edit: Also, I was sure Jigsaw was approved in the end; that's why we've had to wait until September.
> JDK 9 downloads are larger than JDK 8 downloads because they include JMOD files so that you can create custom run-time images. To learn about JMOD files see the Project Jigsaw Quick-Start Guide and JEP 282.
The javac compiler has a new option "--release" which can compile against previous Java releases 6, 7 and 8. So the new JDK bundles parts of the previous releases.
You can use Jigsaw to deliver smaller self-contained systems. It was never going to make the JDK itself smaller, just (maybe) help life for non-developers who have to use our crap.
Can it be used as a drop-in replacement for JDK 8 or there could be compatibility problems with popular libraries? As I understood, modules are optional and won't affect code which isn't modules-ready yet?
generally with every major release you can compile and target code to earlier JVMs with minimal, if any changes. I've heard that the module system is not backwards incompatible, and I would be shocked if it was incompatible with java 8 code out of the box
It broke android studio's jdk selector and it broke android gradle for me. Also eclipse needed a hack in eclipse.ini to even start. Looks like the ecosystem isn't ready yet.
I just got finished dropping it into a decent size Java8 SpringBoot project. The only thing it broke was something to do with JPA. I had to add some dependency for java.xml.bind and now everything works so thats cool.
There are a few weird incompatibilities around things that have been moved to modules that are disabled by default. This just bit me with the javax.annotation package (moved to a JAX-WS module and turned off by default; this can jack with containers that work with the PreDestroy/PostDestruct annotations but don't pull in the JSR250 dependency from Maven).
It will be hit and miss for a while until the ecosystem stabilizes. A project using Groovy/Griffon didn't build because of issues related to reflection and I had to disable a lot of the reflection "fences" introduced in JDK 9.
You're right in that JDK 9 highly values backward compatibility with JDK 8. However, there are still some caveats because of modularization of the JDK, that can affect your code (or your libraries) even when running on the classpath without modules:
- some Java EE technologies that are tradionally part of Java SE as well, won't resolve by default when compiling/running on the classpath (JAXB will be the most noticeable)
- JDK 9 strongly encapsulation internal implementation classes (think of types in com.sun.* and sun.* packages). When running on the classpath, there's a lenient form of strong encapsulation: you will get a warning on the console when reflectively using these types. In time, this lenient mode will be switched to a more strict enforcement. Ergo: time to wean code off the dependencies on internal implementation classes
The first restriction you'll probably run into (if you for example have a Spring application). The second restriction is more an issue for library maintainers (though you should start complaining to said maintainers if your application starts printing warnings)
All in all, it's not a 100% drop-in replacement, but it's close enough for most scenarios. The trick is to make sure your application will keep running in the future as well, when a more strict strong encapsulation regime will be enforced for classpath-applications as well.
(full disclosure: I'm author of Java 9 Modularity, O'Reilly, which covers many migrations scenarios as well. See https://javamodularity.com)
well, most of my java projects tend to be very broad in scope, so in those cases, it can potentially make a major impact in systems and API designs.. I'm being optimistic!
There are a few language enhancements. It's true the 9 isn't a revolutionary release for the Java language, but there are several useful changes.
This[1] is the best summary of what is in the release that I've read. The first section discusses language enhancements. Lots of cross references to JSRs and other material.
There is not going to be a Java 10. The next version of Java will be 18.3, to be released in March '18, followed by a release every 6 months. Those will not be "Java 9 feature releases" but "major" Java releases.
JDK9 brings a C1 and C2 JIT compiler for ARM targets without needing an Oracle licence (IANAL). Should be able to get much better performance on ARM now - previously it was interpreted unless you used a custom build with the AArch32 project's C1 JIT.
More likely "Graal" was derived from "Grails", since the English word grail came from the Old French graal. And from http://openjdk.java.net/projects/graal/ :
"The aim of this project is to expose VM functionality via Java APIs. Namely, we want to make it feasible to write in Java a dynamic compiler and interpreter for a language runtime. [...] Building on the compiler, we aim to develop a multi-language interpreter framework. Java will be just one member in the family of supported languages. The use of partial evaluation will allow the framework to deliver competitive performance."
This compiler and framework sounds like an attempt to provide a foundation for more Groovy/Grails-style ecosystems to be built on the JVM.
To me JDK9 and Jigsaw sounds like a viable alternative to Electron. Cross-platform, well-known mature language, distributable standalone app bundle includes the runtime and takes ~15-30 MB zipped or ~80MB unpacked on disk (I tried swing UI, but I would expect JavaFX to have similar results). I don't remember RAM usage details (I tried it a few weeks ago), but I wouldn't expect it to be higher than Electron's.
50 comments
[ 34.6 ms ] story [ 1216 ms ] threadThis AOT compilation feature is interesting, didn't know that it is in JDK9 ... will it allow JDK9 libraries run on iOS? http://openjdk.java.net/jeps/295
"AOT compilation of any JDK modules, classes, or of user code, is experimental and not supported in JDK 9."
...Unclear (to me) what that means
The Java 10 dev branch already has quite a few improvements.
Initially not, but, iOS is specifically mentioned here http://bugs.openjdk.java.net/browse/JDK-8167428
1. you need to compile on the exact same CPU make on model that you will run on (for now there's not cross compilation)
2. you need to compile with the exact same memory settings, including GC selection, that you will run on
3. unless you're cool with binaries that are hundreds of megabytes you will first need to do a profiling run an determine which classes and methods you want to compile
4. you will need to decide if startup time or ultimate performance is more important than you
5. in the end you probably get a better startup time out of -noverify
I wonder how this is going to play out if it starts getting use. I'm guessing we'll see two types of jars published on Maven, maybe Jigsaw enabled and regular? (e.g. <classifier>jigsaw</classifier>?)
Edit: Also, I was sure Jigsaw was approved in the end; that's why we've had to wait until September.
> JDK 9 downloads are larger than JDK 8 downloads because they include JMOD files so that you can create custom run-time images. To learn about JMOD files see the Project Jigsaw Quick-Start Guide and JEP 282.
Intel didn't vote at all. (on previous vote Intel voted yes)
As a result, this doesn’t work with Java 9 the same anymore, as basically all that stuff has been moved around.
- some Java EE technologies that are tradionally part of Java SE as well, won't resolve by default when compiling/running on the classpath (JAXB will be the most noticeable)
- JDK 9 strongly encapsulation internal implementation classes (think of types in com.sun.* and sun.* packages). When running on the classpath, there's a lenient form of strong encapsulation: you will get a warning on the console when reflectively using these types. In time, this lenient mode will be switched to a more strict enforcement. Ergo: time to wean code off the dependencies on internal implementation classes
The first restriction you'll probably run into (if you for example have a Spring application). The second restriction is more an issue for library maintainers (though you should start complaining to said maintainers if your application starts printing warnings)
All in all, it's not a 100% drop-in replacement, but it's close enough for most scenarios. The trick is to make sure your application will keep running in the future as well, when a more strict strong encapsulation regime will be enforced for classpath-applications as well.
(full disclosure: I'm author of Java 9 Modularity, O'Reilly, which covers many migrations scenarios as well. See https://javamodularity.com)
Still, no major language enhancements...
This[1] is the best summary of what is in the release that I've read. The first section discusses language enhancements. Lots of cross references to JSRs and other material.
[1] https://www.sitepoint.com/ultimate-guide-to-java-9
They'll probaby cherry pick some other language features along the way to Java 10.
https://www.sitepoint.com/ultimate-guide-to-java-9/#collecti...
Imagine being able to run Pandas and Reactjs and Spring using the same runtime.
https://github.com/graalvm/truffleruby
Java is now officially signalling that it wants to make building new languages as the future of Java.
Graal is also probably going to define the future of the JDK internals as well. http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...
But java9 is general availability for this .
"The aim of this project is to expose VM functionality via Java APIs. Namely, we want to make it feasible to write in Java a dynamic compiler and interpreter for a language runtime. [...] Building on the compiler, we aim to develop a multi-language interpreter framework. Java will be just one member in the family of supported languages. The use of partial evaluation will allow the framework to deliver competitive performance."
This compiler and framework sounds like an attempt to provide a foundation for more Groovy/Grails-style ecosystems to be built on the JVM.
http://www.google.com
Graal: http://openjdk.java.net/projects/graal/
Grails: https://grails.org
The words graal and grail do share a common etymology, but the projects aren't related.