After reaching approval of the feature extension process, Oracle has confirmed July 2017 as the new target for the Java 9 release. The date is very similar to that previously predicted by InfoQ, although for various reasons this might indicate risk: while our estimation was based on a feature extension period of three months, the actual period will last seven months, with cuts in testing effort to make up the difference. Early, informal testing might be in place to compensate.
At the time of InfoQ's last analysis, the latest available date for features whose extension had been approved was 1st September, suggesting a delay of roughly three months (this, of course, didn't take into account features without an estimate). Assuming this delay pushed things back evenly, that pointed to a GA of late June 2017. However, the currently proposed schedule doesn't push things back evenly, potentially creating a number of risks. Here is the schedule before the last change:
- 2016/05/26 Feature Complete
- 2016/08/11 All Tests Run
- 2016/09/01 Rampdown Start
- 2016/10/20 Zero Bug Bounce
- 2016/12/01 Rampdown Phase 2
- 2017/01/26 Final Release Candidate
- 2017/03/23 General Availability
And here is the newly proposed schedule:
- 2016/05/26 Feature Complete
- 2016/12/22 Feature Extension Complete
- 2017/01/05 Rampdown Start
- 2017/02/09 All Tests Run
- 2017/02/16 Zero Bug Bounce
- 2017/03/16 Rampdown Phase 2
- 2017/07/06 Final Release Candidate
- 2017/07/27 General Availability
The first thing to notice is that "Rampdown Start" now happens before "All Tests Run". As specified in the milestones definition, Rampdown Start is the moment from which only bugs with severity P1-P3 are fixed, while All Tests Run marks the moment where all tests have been run at least once in all the supported platforms. This means that fixing issues of lower severity is going to be automatically ruled out even before there has been a chance to fully test the new Java.
Rampdown Phase 2 is, on the contrary, planned to be about a month and a half longer than before, probably to make up for a shorter Phase 1. In Phase 2 only showstoppers are fixed, which in combination with the above, indicates a preference to have basic working functionality at the expense of allowing the presence of minor bugs.
Finally, the time between the first release candidate and the general availability has been shortened to less than half. The milestones definition indicates that if another Zero Bug Bounce Phase is needed after the release candidate, the general availability will be at risk. Taking into account the reduction of testing time in previous phases and the shorter time available to react, the likelihood of this happening is higher with the new schedule.
There is one possible mitigating factor that should be taken into account: since the feature complete phase finished in May 2016, it is possible that some testing is already under way while completion of the feature extension is achieved. This might not be reflected in the schedule because there isn't any phase that can be formally brought forward; on the one hand, Rampdown implies that only P1-P3 issues are addressed, while it's possible lower proprieties are being addressed right now; on the other hand, All Tests Run cannot happen until all the code is locked in. In any case, the late feature extension included key components for Modules System like JEP 282, which suggests that even with advanced testing Java 9 is up for a bumpy ride.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/how-to-manage-full-stack-java-development-with-hilla/en/smallimage/manage-full-stack-java-development-with-hilla-small-1686055303315.jpg)
/articles/open-source-java-profilers/en/smallimage/unleash-power-of-open-source-java-profilers-small-1681206807197.jpg)
/articles/rapid-startup-of-your-cloud-native-java/en/smallimage/logo-1680293937095.jpg){kind=logo}
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/rmi-to-websocket/en/smallimage/migrate-a-RMI-based-legacy-application-to-WebSocket-small-1680106723513.jpg)
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/articles/series-apache-kafka-streams/en/smallimage/apache-kafka-article-series-logo-small-1673455781546.jpg){kind=logo}
/articles/secure-kafka-cluster-strimzi/en/smallimage/securing-a-kafka-cluster-in-kubernetes-using-strimzi-small-1671647644310.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/presentations/doordash-event-system/en/smallimage/allen-wang-small-1685003811186.jpg)
/presentations/technology-change/en/smallimage/lisa-gelobter-small-1685003217738.jpg)
/articles/debugging-beneath-trusted-abstraction/en/smallimage/debugging-outside-comfort-zone-diving-beneath-trusted-abstraction-small-1685961994992.jpg)
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
Community comments
Who cares!
by Timothy Liu,
Re: Who cares!
by Venkateswara Rao Desu,
Re: Who cares!
by William Smith,
Re: Who cares!
by Ryan McDonough,
Re: Who cares!
by Clayton Wohl,
Re: Who cares!
by Abraham Marin-Perez,
Official Schedule is just ballpark estimate
by Clayton Wohl,
Who cares!
by Timothy Liu,
Your message is awaiting moderation. Thank you for participating in the discussion.
But, who cares.
Re: Who cares!
by Venkateswara Rao Desu,
Your message is awaiting moderation. Thank you for participating in the discussion.
:)
There will be some...
Re: Who cares!
by William Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
There’s some good stuff in Java 9. I’m honestly not interested in Jigsaw but Reactive Streams, HTTP 2.0, the REPL, and the updates to the process API will all be very much appreciated. I also think Private Interface Methods are going to be dead handy.
Re: Who cares!
by Ryan McDonough,
Your message is awaiting moderation. Thank you for participating in the discussion.
Those features will absolutely be appreciated, but they can also be certainly be had in Java 8 now with 3rd party libraries. Granted, HTTP/2 support in the JRE will simplify a lot of things like ALPN, etc., but, most can get their jobs done with Java 8. I'd rather Java 9 ship with quality than meet some arbitrary date.
Official Schedule is just ballpark estimate
by Clayton Wohl,
Your message is awaiting moderation. Thank you for participating in the discussion.
The JDK team is just guestimating a date, setting milestones to match their guestimate date, and then if it's not ready, they feel bad and delay another six months. The article is reading into the milestone descriptors, they are just date placeholders. Will JDK 9 ship on the current target of 2017/07/27? Given that it's feature complete, it's widely downloaded and used, it's reasonably stable, they are just handling tons of bugs and breakages, that time frame seems reasonable. I wouldn't bet my life on it, they may discover they need more major changes to the module system which will cause delays.
Re: Who cares!
by Clayton Wohl,
Your message is awaiting moderation. Thank you for participating in the discussion.
There are dozens of high quality, widely used reactive stream libraries/frameworks for Java/JVM. I am not convinced the JDK version will be as good as the options already available. Similarly for HTTP 2.0, that's something that can be easily done with add on libs.
I'm hoping JDK 9 will deliver significant memory gains and possibly runtime performance gains with existing code. I'm excited to try Jigsaw but I'm not convinced it will be genuinely beneficial.
The super BIG forthcoming feature is Project Valhalla and low-overhead, efficient immutable custom value types. That will be huge for the JVM. I'm hoping that is in JDK 10.
I'd also like a better functional language for the JVM that completely eliminates OOP classes except for JVM interop and replaces them with simple functions, modules, named tuples/records, and type classes. Maybe Frege does that now.
Re: Who cares!
by Abraham Marin-Perez,
Your message is awaiting moderation. Thank you for participating in the discussion.
To be fair, Jigsaw can be used to deliver significant performance and cost gains: the ability to split the JDK itself into modules might help application developers create a smaller runtime with only the modules in use by the running application. A smaller runtime, applied to the hundreds of JVM instances a typical microservice architecture might be running at any given time, can significantly improve memory usage in a cloud environment.