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.
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!
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.
ReplyDeleteA 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.
ReplyDeleteI agree with your two favorites:
ReplyDelete1) 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.
To clarify, this is what sometimes raises eyebrows among my coworkers: List.<Integer>nil()...
ReplyDelete