BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Java 9 Enters First Bug Fixing Round

Java 9 Enters First Bug Fixing Round

Bookmarks

Java 9 is now officially feature complete, meaning the first bug-fixing phase has started. HTTP/2 Client didn't make it on time for the deadline and has been downgraded to an incubating feature. Since the objective now is to prepare Java 9 for general availability in July, it is very unlikely that any new JEP will be added at this point.

As previously mentioned on InfoQ, the first bug-fixing round, or Rampdown Start, will be aimed at P1-P3 bugs. Among these, and as specified in the process proposed by Mark Reinhold, Chief Architect of the Java Platform, priority should be given to bugs that are new in Java 9, over bugs that affect Java 9 but are already present on Java 8 or earlier, probably under the rationale that the public can more easily tolerate bugs that are already out in the wild than new ones. This idea of focusing on whatever is going to provide a better user experience seems to also manifest in the fact that bugs that refer exclusively to documentation, demos, or tests, are explicitly filtered out from the list of bugs provided by Reinhold; at the moment of writing this article, there were 194 bugs in that list.

This phase also includes a provision for knowingly leaving some P1-P2 bugs unfixed if there is justification for it. Bug owners who wish to defer their resolution must indicate so in the bug report itself indicating the reason for their request (complexity, risk, lack of time, etc.); Area Leads, Group Leads, and the JDK 9 Project Lead will then analyse these data and grant or reject the deferral. At the moment of writing this article, there were no deferral requests yet, although this list may change later on.

This Rampdown Phase comes after an ad-hoc Extended Feature Complete Phase, added to give time to some JEPs to be finished. HTTP/2 Client, together with Enhanced Deprecation, jlink, and the New HotSpot Build System, were features that appeared at risk back in July 2016. Among these, HTTP/2 Client is the only one that hasn't finally made it, turning into an incubator feature. This means that, although HTTP/2 Client will be included in Java 9, it won't be accessible by default: the feature will be packaged under a module with the prefix jdk.incubator., and for that to be accessible developers will have to explicitly use the --add-mod flag. However, if developers choose to do this, they'll need to take into account that incubating features are not part of the standard API, and therefore can be modified at any moment.

Rate this Article

Adoption
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.

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

Community comments

  • Contradiction: "better user experience" and "no fixes to doc's, demo's or tests"

    by David Babuder,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There seems to be a contradiction in this article. Quoting:
    "This idea of focusing on whatever is going to provide a better user experience seems to also manifest in the fact that bugs that refer exclusively to documentation, demos, or tests, are explicitly filtered out"

    It seems to me that documentation, demos and tests exist explicitly to enhance the user experience (otherwise why have them?). So ignoring bugs in those areas does NOT enhance the user experience, it detracts from it.

    Just say it like it is "in order to target the ship date, they are ignoring certain user experience issues such as docs, demos, and tests".

  • Re: Contradiction: "better user experience" and "no fixes to doc's, demo's

    by Abraham Marin-Perez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi David,

    Thanks for your comment. There is a hidden, albeit common, assumption in the article: not all bugs will be fixed, and a release will happen with a number of unfixed issues. This is rather common for projects of this size, and is based on the fact that, with such a large and diverse codebase, achieving a complete zero-bug situation is impractical (if not impossible).

    Given the assumption that not all bugs are going to be fixed, the debate turns into which ones are selected for resolution. It is commonly understood that a developer would prefer working code over good documentation, reason for which documentation bugs are, at least initially, filtered out. The same applies to demos and tests.

    In summary, I don't think it would be fair to say that they are ignoring any issues, but rather that they are focusing on the highest-value ones first, as a way to provide the best user experience.

  • Re: Contradiction: "better user experience" and "no fixes to doc's, demo's

    by David Babuder,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with all of your statements, including the pragmatic approach of focusing on select issues. I only take exception to the last phrase in your comment. The purpose of the prioritization is not to enhance user experience, but to hit a target date.

  • Re: Contradiction: "better user experience" and "no fixes to doc's, demo's

    by Abraham Marin-Perez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Focusing on the most important issues does indicate a desire to provide the best user experience (within the existing time constraints). The public is already rather disappointed that Java 9 is roughly one year late, which means we shouldn't dismiss "hitting the deadline" as something unimportant: once the product becomes good enough for a release, people value "sooner" over "more polished".

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

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

BT