BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Latest Java 9 Schedule Appears to Be at Risk from the Outset

| by Abraham Marín Pérez on Dec 09, 2016. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Who cares! by Timothy Liu

But, who cares.

Re: Who cares! by Venkateswara Rao Desu

:)

There will be some...

Re: Who cares! by William Smith

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

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

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

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

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT