Oracle has been dragging their feet on adding new language features and their developer base is getting tired of the extremely long wait times. Having to wait until 2020, or longer, for values types, generic specialization and a proper FFI is ludicrous especially when you consider that these features could have arrived in Java 9 had it not been for the prioritization of Project Jigsaw.
As for Oracle trying to close Java - any attempt to do so would be a disaster. IBM, Red Hat and other major players in the Java space would organize and fork the language.
I am afraid this is the death knell for the Java community process. I simply don't see Oracle taking out Jigsaw from Java 9 after investing so much effort into it. Also, a lot of folks were looking forward towards Jigsaw as a lightweight module system compared to heavyweight OSGi.
The worst thing Oracle can do is deliver a bad feature. Java Gererics turn 15 this year. It's better to delay such a radical change than being stuck with it for the next few decades. Oracle is no hurry to do that. Maybe they get it together in time for the next LTS release (Java 14).
We can wait till 03/2014 for JDK 8. I don't want to jump on buggy code. Good idea by Oracle not to scope creep by delaying but fixing security bugs and making the code base more stable.
I feel like that’s being super rude to the devs at Oracle that have been constantly innovating and improving the language. Java has changed a lot in the last 9 years.
Oracle’s upcoming design of continuations I think is genuinely novel and will inspire a lot of other languages’ implementations.
Okay, replying to myself after a couple of quick Google searches.
The situation is quite complex. A big part of the industry seems to be stuck at Java 8 right now due to several reasons. One of them is the momentum Java 8 gained when it was released in 2017, 8 years after Java 7. It was a strong release, bringing much-awaited features to the aging Java ecosystem. Subsequent released didn't come anywhere close to that.
Another big reason is the uncertainty of the upgrade path. Java 9 was released comparatively short time afterwards, and it is set to expire... last month. [1] Unsurprisingly, many customers chose to stay with a stabilized, thoroughly tested version of Java 8, rather than switch to a bleeding edge (in Java terms, at least), untested Java 9 with a very short time fuse on it. Finally, Java 10, which has been released recently, is also due to expire very shortly - in fall 2018.
So overall this looks like a very aggressive monetization move on Oracle's part, intended to extract $$ from customers who value stability of their platform. It goes completely against the long-established tradition of stability in the Java ecosystem, which is one of the reasons many of the customers chose it, in the first place. I expect a massive migration towards OpenJDK and a backlash in the community, which will ultimately push Oracle aside.
Within limits. Valhalla seems to be still far from launching, and allowing features to back up behind it might just recreate the situation Java has previously found itself in during the 7/8 era where slippage in massive projects caused everything else to slip too. The new release cycle was meant to fix that, but if half the new stuff ends up waiting for value types then the problem has just reappeared in a new form.
The odd thing is that part of Valhalla is about how to migrate existing types to being value types, and they already have code that can simulate the same restrictions. So it's not really clear why these features have to wait. Migration is a part of the Valhalla plan anyway.
What's not clear to me from the outside is how coupled these decisions are to the Java 9 release. Supposedly Java 9 is going to ship in less than three months, but you can't change major functionality in that short of a time frame. Or is there some way that you can defer work on Jigsaw/the JPMS spec without upsetting everything else?
On the other hand, if porting our app to Java9+Jigsaw requires us to wait a year (because breakage with maven), costs like half a year to a year (I know our codebase), while upgrading our application servers (because classloading) and possibly re-doing a lot of the build process at the same time... I'll have to support Java8 for just about forever.
That upgrade wouldn't happen, or it would be really nasty. I'll rather tolerate a standard library with a lot of bollocks in there and provide security around it.
Actually, Oracle have proved a LOT more committed than Sun to improving the language. They put one of the smartest guys in charge of Java 8, charged him with turning the ship around and have given him a lot of resources to work on it. Even Java 7, while including few language features, did include a lot of JVM improvements.
The timezone-update tool, on the other hand, really is a minor issue. So some people will have to use IBM's tool instead. Yeah, it's lame, but I don't think it's going to change anyone's mind.
And it will still take time to come, the whole engineering problem is how to introduce value types, make classes that are clearly value types like Optional, turn into value types, while at the same time not breaking the endless amount of JAR files in production, when upgrading to a JVM with value types support enabled.
They would get it sooner by breaking the ecosystem, and as Python 3, Java 9, .NET Core have shown, not everyone would be racing to adopt the new shiny thingy.
Many of the productivity features we're talking about (e.g. lambda) were originally supposed to be in java 7, so have already been delayed multiple times.
Looks like a stop gap for Java 8 (the static portion that is). Please Oracle let me have my closures sooner so the .NET programmers will stop making fun of us :)
Java has an enormous foothold in the enterprise with lots and lots of code running and often dating back years, if not a decade or more. That's not going to be replaced easily. The other thing is that Java users seem to be very averse to upgrading. We got a lot of backlash for releasing our newest library version for Java 8 only (so our API could offer a few niceties from that version and be less awkward to use), even though it's the only currently supported Java version by Oracle. We still have customers that use Java 1.4 ...
As for Oracle trying to close Java - any attempt to do so would be a disaster. IBM, Red Hat and other major players in the Java space would organize and fork the language.
reply