JDK 9 General-Availability Release | Hacker News Reader

JDK 9 General-Availability Release

jdk.java.net

274 pointsbatbomb47 comments

I'm really excited for Graal which will make high performance Ruby, Python and JS possible. https://youtu.be/5BMHIeMXTqA

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...

Does JDK 9 set things up for Graal or are you just making a statement on Graal independently of this news?

The new jaotc is built using Graal. I think (but not sure) that Graal can be used with difficulty on older java.

But java9 is general availability for this .

It start to set up things and the AOT feature uses Graal.

Is Graal derived from Grails?

"Grails" was derived from "Rails", just with a g prepended. Are you actually asking whether the "Holy Graal" refers to a railway station in heaven?

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.

Nope. Completely unrelated projects (well, both are on the JVM).

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.

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.

See also the mail from Mark Reinhold http://mail.openjdk.java.net/pipermail/announce/2017-Septemb...

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

Seems limited?

"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

Seems clear, it _can_ compile but if you have problems, they're not likely to fix it.

Yes, it is WIP.

The Java 10 dev branch already has quite a few improvements.

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.

Initially not, but, iOS is specifically mentioned here http://bugs.openjdk.java.net/browse/JDK-8167428

Thanks also for the link!

You still need a full JVM to execute the compiled code, it's mainly just an optimisation to improve startup time.

Here is a talk about it at JVMLS'17: https://youtu.be/n5DCg6M2MDM

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

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.

Also discussed here, which links to the full Oracle JDK distribution for windows, macOS, linux and solaris: https://news.ycombinator.com/item?id=15306295

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

The problem is that some Java 8 code relies on implementation-specific code in the JVM – for example, JetBrains’ IDEs do.

As a result, this doesn’t work with Java 9 the same anymore, as basically all that stuff has been moved around.

as usual they have been working on support in the EAPs, I'm guessing 2017.3 works relatively well with jdk9 by now, but i havent tried yet!

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)

NO language enhancements .... I guess they leave that for the Kotlin guys ...

modules are a massive enhancement that will benefit kotlin as well as any other jvm language

I wouldn't classify that as _massive_ , but it definitely pleases the maven/gradle dudes.

Still, no major language enhancements...

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!

Just yesterday I was giving support to a Java 1.4 project....

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.

[1] https://www.sitepoint.com/ultimate-guide-to-java-9

Don't worry, pattern matching and data classes should be coming in one of the Java 9 feature releases (6 month cycle).

They'll probaby cherry pick some other language features along the way to Java 10.

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.

Not a "language" enhancement per se, but I find Collection Factory Methods a nice improvement.

https://www.sitepoint.com/ultimate-guide-to-java-9/#collecti...

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.

From the article:

> 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.

Yes. Jigsaw was approved with some voters abstaining. https://www.jcp.org/en/jsr/results?id=6050

To be more clear, only Red Hat abstained (so not voters, but a single voter).

Intel didn't vote at all. (on previous vote Intel voted yes)

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.

Jigsaw was approved in the second ballot.

Cool, that's good to hear.

Reply on news.ycombinator.com