Monday, 7 November 2011

The future is in the JEPs

If you want to know the most likely contents of Java 8 and beyond, the JEP process is the best place to look.

JDK Enhancement Proposals

JDK Enhancement Proposals (JEPs) are the simple descriptions of the tasks that are being considered for Java 8. Here is Brian Goetz's take:

JEP stands for "JDK Enhancement Proposal", and is part of our process for building a technical roadmap for the Java platform. Filing a JEP (what we used to called a "one pager") is the first step towards inclusion of a proposed feature in the JDK.

The JEP process document linked below outlines the states a JEP can go through, from Draft (we're just talking) to Submitted (I think this is good enough to review) to Candidate (Group/Area leads think the idea has enough merit to not toss out) to Funded (someone has actually committed resources to making it happen.) The last transition -- to Funded -- is the one at which this goes from being an idea to being part of the plan for some JDK release.
...
What JEP is not: it is not a "suggestion box" for drive-by requests. The JEP process is open to JDK *committers*, and it is unlikely a JEP will gain funding if the author is not prepared to contribute significant effort to the project's implementation or stewardship.

And the formal process document says:

The primary goal of this process is to produce a regularly-updated list of proposals to serve as the long-term Roadmap for JDK Release Projects and related efforts. The Roadmap should extend at least three years into the future so as to allow sufficient time for the most complex proposals to be investigated, defined, and implemented.
...
This process is open to every OpenJDK Committer. Decisions about specific proposals will be made in a transparent manner but are ultimately up to the OpenJDK Lead.

This process does not in any way supplant the Java Community Process. The JCP remains the governing body for all standard Java SE APIs and related interfaces. If a proposal accepted into this process intends to revise existing standard interfaces, or to define new ones, then a parallel effort to design, review, and approve those changes must be undertaken in the JCP, either as part of a Maintenance Review of an existing JSR or in the context of a new JSR.
...
That a particular JEP appears in the Roadmap means only that it is the proposal of record from a technical perspective. There is no guarantee that anyone will work on it, much less that its end result will appear in any JDK Release Project.

At the time of writing, there are 26 JEPs, plus 2 "meta" JEPs.

JEPTitle and LinkMy comments
101Generalized Target-Type InferenceMore type inference
102Process API UpdatesManaging OS processes
103Parallel Array SortingFrom the concurrency group
104Annotations on Java TypesAnnotations everywhere (JSR-305/308)
105DocTree APICompile AST access to javadoc
106Add Javadoc to javax.toolsProgramatic access to javadoc tool
107Bulk Data Operations for CollectionsAdd lambda aware methods to collections
108Collections Enhancements from Third-Party LibrariesNew collection methods and collection classes
109Enhance Core Libraries with LambdaAdd lambda aware methods to everything apart from collections
110New HTTP ClientReplace HttpURLConnection
111Additional Unicode Constructs for Regular ExpressionsEnhance RegEx
112Charset Implementation ImprovementsEnhance CharSet
113MS-SFU Kerberos 5 ExtensionsSecurity
114TLS Server Name Indication (SNI) ExtensionSecurity
115AEAD CipherSuitesSecurity
116Extended Validation CertificatesSecurity
117Remove the Annotation-Processing Tool (apt)Replaced by JSR-269
118Access to Parameter Names at RuntimeReflective access to parameter names
119javax.lang.model Implementation Backed by Core ReflectionEnhance low level compiler model
120Repeating AnnotationsAllow multiple annotations of the same type
121Stronger Algorithms for Password-Based EncryptionSecurity
122Remove the Permanent GenerationMajor change to JVM memory usage
123Configurable Secure Random-Number GenerationBetter random numbers (Security)
124Enhance the Certificate Revocation-Checking APISecurity
125Network Interface Aliases, Events, and DefaultsSuch as listening to wifi and mobile networks
126Lambda Expressions and Virtual Extension MethodsMain language change of Project lambda

Overall a good set of items so far, with access to parameter names and collection enhacements being of particular interest to me.

Since Oracle isn't accepting "drive by" enhancement requests, feel free to post your thoughts in the comments!

4 comments:

  1. I would like to see something like the .NET Reactive/Interactive Extensions (I made a Java port for myself). Unfortunately, the java.util.Observable name is already taken and the class not compatible with the Rx semantics. Of course, Rx relies heavily on lambda expressions and better type inference.

    ReplyDelete
  2. A surprising amount of security stuff! Nice to see PermGen is going to be removed. Still not sure why such low-hanging [frontend sugar] fruit as a decimal type isn't on the table, there must not be a lot of people at Oracle implementing base-10 algorithms.

    ReplyDelete
  3. I agree with your two favorites:
    1) The absence of Multiset and Multimap from the collections framework is quite painful. I sharply miss Guava and/or sf.net Commons Collections whenever I don't have access to them. (sidebar: still no generics, Apache Commons Collections?)

    2) Access to parameter names via reflection. Could have used this in a previous project. Although ultimately, the annotations I cooked up in its place may have been a better choice (as I could prettily name parameters in the annotations).
    --
    I also would be excited about extending type inference. Coworkers sometimes give me funny looks when they see: List.nil() or the like.

    I'm still not certain why the constructor name is necessary to append to a "new" if the type being instantiated is concrete.

    ArrayList list = new();

    That change would save more typing than the diamond notation (which targets the same use case), it would preserve manifest typing, and it would be backwards compatible. I realize declaring the concrete class isn't always a best practice (in the above, List would likely be the preferred target), but I'm not certain why this wasn't given more consideration.

    ReplyDelete
  4. To clarify, this is what sometimes raises eyebrows among my coworkers: List.<Integer>nil()...

    ReplyDelete