Security vulnerabilities related to Java running inside web browsers have lately received a lot of public attention. Here at Oracle we’ve mounted an intense effort to address those issues in a series of critical-patch update releases, the most recent of which we posted earlier this week. We’ve also upgraded our development processes to increase the level of scrutiny applied to new code, so that new code doesn’t introduce new vulnerabilities.

Maintaining the security of the Java Platform always takes priority over developing new features, and so these efforts have inevitably taken engineers away from working on Java 8. It’s one of the reasons why some features slipped past Milestone 6 (M6), our original Feature-Complete target at the end of January.

Looking ahead, Oracle is committed to continue fixing security issues at an accelerated pace, to enhance the Java security model, and to introduce new security features. This work will require more engineer hours than we can free up by dropping features from Java 8 or otherwise reducing the scope of the release at this stage.

As a consequence of this renewed focus on security the Java 8 schedule, with a GA release in early September, is no longer achievable.

Status As I’ve previously written, the most important work that slipped past M6 is related to Project Lambda, the sole driving feature of the release. We integrated the language and VM changes for Lambda late last year, but between all the moving parts involved and the security work it’s taken a bit longer than expected to put the finishing touches on the stream API and the related core-libraries enhancements (JEPs 107 and 109). Our best estimate right now is that we can finish this work by early May, about three months later than planned.

The other features that slipped past M6 are not release drivers, so in theory we could just drop them from the release, but if Lambda needs more time then there’s no point in doing that.

Alternatives So, what to do? There are many options; let’s look at a few of them.

• Drop Lambda from the release in order to maintain the current schedule, with a GA release in early September.

If we drop Lambda then the remaining features are interesting but not, taken as a whole, very compelling. A Lambda-less release this year would hence be unlikely to gain wide adoption, so why bother? Lambda itself would not be available until 2016, assuming we maintain the two-year cadence that I’ve previously suggested. I don’t think anybody wants to wait that long.

• Retain Lambda but reduce the time available for feedback and testing in order to maintain the schedule.

If we sacrifice quality in order to maintain the schedule then we’ll almost certainly repeat the well-worn mistakes of the past, carving incomplete language changes and API designs into virtual stone where millions of developers will have to work around their flaws for years to come until those features — or the entire Platform — are replaced by something new.

• Slip the schedule by a year or more so that we can include Project Jigsaw, which was previously dropped.

With Lambda nearly complete, I don’t think it makes sense to delay its release. Beyond that, finishing Jigsaw would likely require more than a year’s delay, for reasons I’ve previously given and because key members of the Jigsaw team at Oracle have lately spent a lot of time working on security issues.

Hold the train I think the least-bad option is this:

• Slip the schedule just enough to finish Lambda, and ship the release after it’s thoroughly reviewed and tested.

If we can finish the remaining design and development work by early May then we should be able to test and stabilize the build over the summer and ship a solid Developer Preview release in early September.

To settle on a new GA date for Java 8 requires a bit more planning work, but my expectation is that we’d be able to ship the release in the first quarter of 2014.

That is, of course, more than a three-month slip from the current GA date in early September. At this point we’re not confident that we could be ready for a GA release in November, and experience has shown that it’s almost always a bad idea to try to ship a major software release in December, so that pushes the GA date well into the first quarter.

This option would not open the gates for a flood of new features in Java 8, nor would it permit the scope of existing features to grow without bound. We’d likely add a select few additional features, especially in areas related to security. In general, however, we’d use the additional time to stabilize, polish, and fine-tune the features that we already have rather than add a bunch of new ones. We’ve been down that latter road before, and it’s long and ugly.

Is this the best possible course of action? I think it’s better than the alternatives, but I’m open to suggestions. In the meantime I’m going to ask the same question of the Java SE 8 Expert Group and of the contributors to the Reference Implementation in the JDK 8 Project.

Features vs. schedule I’ve previously argued that it’s best to structure the Java development process as a continuous pipeline of innovation that’s only loosely coupled to a regular, rhythmic release process. If a major feature misses its intended release train then that’s unfortunate but it’s not the end of the world: It will be on the next train, which will also leave at a predictable time.

I still think that’s a good general policy. Adhering strictly to it in this case, however, would mean that we’d take the first option above — i.e., drop Lambda and stick to the schedule — which I strongly doubt anyone actually wants. An exception to the general policy is therefore well justified.

If we adopt my proposal above then we should be able to complete the browser-related security work to which we’ve committed and then resume a regular two-year release cadence, with Java 8 due in early 2014 and Java 9 in early 2016.