Tuesday Feb 06, 2007
Tuesday Feb 06, 2007
With all the blogging about Java 7 language features, I thought I'd point out that many ideas are already represented by proposals in the Sun Developer Network database. The comments about each proposal go back years - to a time before blogging when people left their thoughts on a sun.com site.
Why have these proposals been hanging around for so long? Mostly because the process of evolving the language can only handle a relatively small number of features per release. There are hundreds and hundreds of possible features in the database. The tough part isn't designing any single one of them (and I would encourage you not to read too much into the exact designs contained at the links below) but choosing which ones to design. We have to Do The Right Thing as well as Do The Thing Right.
Suppose there are 200 proposals and we can implement 10 per major JDK release. Now calculate C(200,10) and you'll see that every Java developer on the planet can have their own favourite combination. Which combination should make it into the JLS? (Note I say the JLS rather than javac; people can play with javac to their hearts' content, but the JavaTM Programming Language can only take so much.)
So, while the proposals below may be excellent in and of themselves - and it does seem like some will be getting a new lease of life - please realize that in the past, there were more-excellent features which you don't see below because they made it into Java 1.3, 1.4 and 1.5! Now, without further ado:
- Closures (and the like)
- RFE: Object Oriented Callbacks
- `final' variables and inner classes
- Closures support instead of annonymous inner classes
- Add language support for functors (function objects)
- A simplified syntax for using Runnable
- Add Lambda, Thunk, Predicate, etc., to complement Runnable
- Add language support for converting methods to interfaces
- Shorter declarations
- class name aliasing
- RFE: Special syntax for core interfaces
- Typedef (alias)
- Addition of Map initialising syntax
- Shorter Syntax for Common Operations
- Runtime generics
- Add reification of generic type parameters
- Properties
- Explicit (language) support for properties
- Enhanced 'switch'
- Allow multiple constants and ranges in case labels
- Using Strings and Objects in Switch case statements
- Operator overloading
- RFE: Operator overloading
- BigInteger should support Autoboxing
- 64-bit references
- RFE: 64 bit pointers needed
- Lightweight reflection
- Access to Field, Method without the use of Strings
Posted by Eugene Kuleshov on February 06, 2007 at 12:19 PM PST #
If I had a hat on, I'd first look for proposals that enable features in Java solving general problems being unspecific wrt. application domains and types. Not for the reason of saving key strokes, though, as this can be solved by good IDEs.
Including libraries in the JDK would be a nice to have, but usually not necessary, as these are mostly available as free or commercial solutions anyway, and product companies will ship them included in their products if needed.
Another rationale, which might have kicked a feature like for-each loops, would be the completeness of a proposal, e.g., for-each loops target a very small part of Java, namely collections, where a more general solution for any kind of numerable objects would be possible. Similar holds for autoboxing and operator overloading, which should be (or should have been) actually targeted with an object-oriented approach.
Posted by Stefan Schulz on February 06, 2007 at 02:40 PM PST #
I can add some more to your list :)
Shorter Syntax for Common Operations also includes a closure like proposal (essentially short syntax for inner classes) - so you could list that one twice (i.e. also under closures).
Add Keyword Management allows the Java source version to be specified in a file so that new keywords can be added or an API from another language that use Java keywords can be used, since name clashes are eliminated by mangling (hence this one might enable some of the others)
Add Immutable types to Java
Posted by Howard Lovatt on February 06, 2007 at 08:15 PM PST #
Posted by Roman Elizarov on February 07, 2007 at 07:54 AM PST #
Here are some more RFEs for language extensions this time from the top 25 RFE list and one other not in the top 25:
Support For 'Design by Contract', beyond "a simple assertion facility" 574 votes
Provide "struct" syntax in the Java language 337 votes
Consider adding traits to Java (not in top 25 - 0 votes)
I am curious as to why you didn't include all the ones out of the top 25 list - any particular reason?
A second curiosity question: the bug database and the voting system seem to be playing a lesser role, e.g. all the closures debate yet few votes, any particular reason?
Posted by Howard Lovatt on February 07, 2007 at 03:02 PM PST #
The list in the post is essentially the tier-1 feature set being considered for Java 7. I personally have no problem by DbC and would put it on my tier-2 list, along with binary literals and maybe some form of traits (perhaps just static method bodies in interfaces).
Immutability and lightweight/struct objects are possible language features, but in the overall scheme of things they are just hints to the VM to treat some instances specially. The likelihood is that the VM can work that out on its own. It won't be perfect, but a few vendors changing VM internals is unbelievably more cost-effective for the world than every programmer learning and deploying new language features.
As to why the bug comment + voting system has tailed off in popularity...the inability to get any kind of RSS out of it means you have to be pretty keen to stay up to date, by visiting RFEs periodically. And people can so easily make proposals on their own blogs now.
Posted by Alex Buckley on February 08, 2007 at 07:30 AM PST #
As the originator of the Immutable proposal I would like to defend it a bit. The proposal isn't just about stack allocation, which as you correctly point out might in the future be possible in the JVM (lets hope so). My motivation was also:
Since all the hardware seems to be going multiprocessor and immutables are ideal for concurrent libraries I am surprised that adding immutables isn't on the agenda. Note other newer languages, like Scala, have them.
Changing subject, there is another language feature in the top 25 RFEs that I missed: Extension of 'Interface' definition to include class (static) methods (188 votes).
Posted by Howard Lovatt on February 09, 2007 at 03:35 PM PST #