Hacker News Reader

Comment by wocram | Hacker News Reader

Is anyone eagerly awaiting JDK9?

One thing I am looking forward to in JDK 9 is the new API, called JVMCI, that lets you replace HotSpot's JIT compiler with one written in Java. Oracle Labs is working on a compiler for this called Graal. We're using this to make languages other than Java running on the JVM, like JRuby, run faster by using the JIT compiler API directly.

(I work for Oracle)

I've been vaguely following JPython's story, and the limit is less the Python language, and more the Python runtime environment and its reliance on C APIs written with the GIL assumption in mind. http://jyni.org doesn't appear to be ready for prime time, though there is recent progress, https://github.com/Stewori/JyNI/issues/2.

Does JVMCI bring hope for JPython + JyNI ?

Yes JVMCI can help there in a couple of areas. Part of Graal (the new compiler) is a new FFI that bypasses JNI and can represent native calls directly in the JIT. That should improve native call performance.

There is also a C interpreter with JIT being built on top of Graal and JVMCI. In JRuby we're looking at interpreting C extensions rather than running them as native code. In some cases this is faster than the native code, because we can optimise the Ruby and the C code together.

Do you know the guy who did the talk about optimizing Ruby for the way Ruby devs use Ruby? They used an example if an image library clamp function which was a mess. Using sort to clamp a value.

Whoever that guy is, I'd like to be able to say he did an amazing job. Good work on your groups.

That talk was by Chris, who you are replying to.

Well shit I've got to say that he is amazing! Chris keep up the good work. I look forward in seeing where you take it from here.

I'd like to see it in my cloud deployments. Modularity means smaller size of server jdk and thus smaller size of images. Faster deployments and builds, less traffic and storage in build farms...

So are we! Currently at Boxfuse (https://boxfuse.com/) we create VMs around 40 MB in size for Java 8 and we very much look forward to Java 9 to reduce this even further!

We'll in theory. In practice pulling in Java Beans (which is below almost everything) pulls in all the desktop APIs (Swing, AWT, sound, …). But you'll be able to save two megs on CORBA.

Yes, the replacement of sun.misc.Unsafe with the new Varhandles API will be a very nice tidy up in a couple of key places in my language implementation. The new module system will provide compile time checking that OSGi currently only provides much later, and there's a few other nice changes round process management.

Jigsaw is the big thing really, and its effect is going to be a more long term thing than an immediate change.

My company is starting a few new bigger projects and we're building it on java8 right now keeping in mind that we will make architectural changes once java9 is released and rewrite some parts to use jigsaw. Classpath mechanism will be finally deprecated.

I'm looking forward to the REPL.

Not really, getting to deploy Java 8 projects is still a big issue.

Most enterprise deployments are limited by what the IT guys know and are willing to accept on their servers.

Uhm, Java 7 is EOL unless you have an Oracle support contract. Oracle support contract and virtualisation don't mix. EOL software and compliance don't mix.

Last year I was working at a customer still doing 1.4 deployments.

As you know from Windows XP, not everyone cares about EOL notices.

Yes, particularly for the HiDPI support for Windows. If Java 9 slips to summer 2017, I'm going to have to bite the bullet and manually scale our Windows GUI on HiDPI (shudder) unless Darcula (https://github.com/bulenkov/Darcula) comes through for us.

I can't wait for compact strings.

All the Jigsaw compatibility issues OTOH I'm not looking forward to.

Reply on news.ycombinator.com