Proposed schedule change for JDK 9 | Hacker News Reader

Proposed schedule change for JDK 9

mail.openjdk.java.net

112 pointsjcytong45 comments

So, one of the complexer part of Java isn't completely finished, and they want to postpone the release instead of releasing something buggy. I'm fine with that. Everybody survived with Java6 for half a decade as well. And three years with Java7.

Me too, specially on Android where we still need to survive with Java 6 and cherry picked pieces from Java 7 and Java 8.

Most likely it will never see 100% support for Java 8, or anything else that comes afterwards.

If you can get away with using it Kotlin fixes almost everything I dislike about Java and works for Android development today.

Actually I spend most of my time on C++ side, which also has its own share of issues regarding Android tooling.

Still checking in how Kotlin support evolves, my experience using languages like Turbo Pascal, Delphi and Oberon made me weary of using using languages that aren't directly supported by platform owners for production code.

Kotlin is amazing. It takes the best parts of Scala while keeping the simplicity of Java.

It may not be supported by Google but it was created by Jetbrains, the developer of Ideaide which is what Android Studio is based on, so it's support is top notch.

The best part of Kotlin is there is near zero cost to using it. You can learn it in a day and is fully interoperable with Java. :)

That's kind of nonsense. Kotlin adds some syntax sugar to Java, but it's not related to Scala in any reasonable way.

What bothers me is that there are tons of improvements in the VM area that we'll have to wait for longer. All of this only because Oracle stubbornly merged Jigsaw into trunk before it was even close the ready. All the issues surfacing now people have been telling Oracle for the past five years. Or Oracle simply could have looked at the experience gained with OSGi over the past decade, especially the OSGi enterprise specification.

In short, Mark proposes a four-month extension of the JDK 9 schedule, moving the General Availability (GA) milestone to July 2017, and the reason is because number of open bugs that are new in JDK 9 is quite a bit larger than it was at this point in JDK 8.

..and they still need to iron out some details of project jigsaw (the new module system, which was originally planned for Java 7)

The work currently being done on Jigsaw is not details at all.

Is anyone eagerly awaiting JDK9?

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.

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.

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.

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'm looking forward to the REPL.

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.

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.

OFF-TOPIC:

I am the only one who is not that happy that Java is so popular?

I don't even know where that feeling come from.

I am happy that Java is popular.

I know it since Sun introduced it and it was a saner experience than C++ back in the day, when each compiler implemented their own vision of the ongoing working standard.

There are only three things I don't like about Java, proper AOT compilation is only available in commercial JDKs and lack of value types, and use of @Overrides annotation instead of adding a proper keyword.

The first two will hopefully get addressed in Java 10, assuming Oracle doesn't change their minds about the language.

I agree with your points, but would like to add another one: runtime generic type erasure needs to go. Whether it is through reification or some other means, I don't care, but it feels like every single time I sit down to write some solid core-of-the-program basic code, I run up against erasure.

It's probably not every time, but you get the point.

That said, I think that Java 8 is in a good state, and I really liked its improvements. For Java 9, the new modularization system seems interesting, and I'll be happy to ditch classpaths!

> runtime generic type erasure needs to go.

Is is part of the value type related changes.

http://www.oracle.com/technetwork/java/javase/community/jlss...

How it will actually look like is still WIP.

I think you should be very careful with statements like that. The Valhalla work adds a mechanism by which generic types can be reified, but reference types in Java are not proposed to be reified as that would cause big interoperability problems with existing code. However the mechanism introduced for reifying value generics could be used by other JVM languages to provide reified reference generic types.

So HashMap<MyRefClass> will always remain the same class as HashMap<Object> when created in Java code, but might not be the same in another JVM language, and HashMap<MyValueType> will never be the same class as HashMap<Object>.

True, but nothing prevents them to have an ImprovedHashMap<any MyRefClass>.

I couldn't agree more with you. Erasure was one of the top boneheaded decisions made in the history of Java development. The irony was that it was done in the name of backwards compatibility that, in practice, was unnecessary. The runtime and API changes introduced Java5 we so large that byte-compatibility was no useful during the transition.

So true about value types. However this will flip flop the whole memory experience in JDK9. I mean even if a LocalDateTime could be represented as a Value Type would be a significant amount of memory saving on our backend. And there is other stuff which adds a unnecessary amount, too. I mean we still get a lot of Long / Int boxes. Hopefully Java 10 will reduce that.

We are on Scala and I guess Valhalla will also make Scala even more awesome with Value Types. I could consider that half of the case classes could be real Value Types.

Another one would be having Optional finally being a value type and do away with the whole issue of Optional being null when APIs play dirty.

it's humbling. With a small community, if you have an idea, you can create a pull request and change the shape of the ecosystem. It's not that hard to create the definitive library, with a few weeks or months of effort.

In a medium community, you can shape discussion. It's still possible to have a lot of influence without tons of effort.

In a large community, you're up against really smart people who are paid to solve problems that can take weeks to simply understand.

You could hack up golang library for web handling that's somewhat novel and get traction. Java? Tomcat has tens of thousands (perhaps hundreds of thousands) of professional hours thrown at it.

I'm happy, because Java already solved a lot of problems on which many emerging platforms are still working on. It's mature, it's working, there's great community and mostly a consensus on architectural approaches. It could be better, but the features I personally desire (better reflection and metamodels to support generative programming), are not present nowhere in other popular languages and platforms.

Java is a reliable tool.

Might not be hip or shiny, but it works.

Always good to have in your toolbox in my opinion.

Java 8 is fine. It fixed a lot of Java's issues, and introduced some functional programming concepts which might help reduce the usual boilerplate.

It probably comes from an earlier experience with a crappier Java. But Java 2, Java 5, and most of all Java 8 (and IMHO, a gradual attitude change from J2EE-style architecture astronautism to Guava-style DRYism) have transformed it into a very pleasant language to use, on a very mature, reliable platform, that also connects to other interesting languages like Scala. I don't know any other popular (popularity matters! a large ecosystem is very useful) language that is as well suited for making very maintainable, low defect codebases. (Although, I'm working on learning golang.)

Java's now-undeserved reputation is just a historical legacy now, but it serves a useful purpose: keeping people like you, who might compete, from using the best tools available. Strangely, I think Java can, at least for a while, count as a "secret weapon" the way Paul Graham described lisp once. (Or is the cat too far out of the bag already? Given how much software is still being unnecessarily written in languages like Python, Ruby, JavaScript that lack type verification, I think Java is still a secret weapon for now)

I would describe Java as verbose, inflexible, and outdated. While it's possible to write maintainable code, it's a real uphill battle. Core libraries such as Java2D are also pretty buggy... after all these years.

Give me C# any day, or better yet, F#.

And how much time have you actually spent writing Java code?

It's true (so I hear) that C# has been ahead of Java on this for a while, but I think the JVM is ahead of the CLR in terms of ecosystem. If you like F#, maybe try Scala on the JVM.

Did you use Java 8 last time you worked with Java? And ideally, maybe something like lombok or scala case classes or protobufs to make value object classes easy to declare?

Also, don't use Java2D then. There's better libraries for that. Maybe it's technically considered a core library, but I wouldn't consider it important

Reply on news.ycombinator.com