Language proposals at SDN

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

Comments:

BTW, JSR 308 is currently discussing allowing annotations for the statements and code blocks inside of the methods. http://pag.csail.mit.edu/jsr308/

Posted by Eugene Kuleshov on February 06, 2007 at 04:19 AM PST #

This is a difficult quest. And, of course, many people have good arguments for their proposal to be the most important one.
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 06:40 AM 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 12:15 PM PST #

One more request: Type arguments for a class shall be inferred on constructor invocation

Posted by Roman Elizarov on February 06, 2007 at 11:54 PM 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:

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 07:02 AM 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 07, 2007 at 11:30 PM 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:

  1. Immutables are thread safe
  2. It is easier to program with immutables, e.g. see Effective Java
  3. Immutables can be allocated in-line in arrays and classes (the JVM won't be able to do this one).

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 07:35 AM PST #

Post a Comment:
Comments are closed for this entry.
About

Alex Buckley is the Specification Lead for the Java language and JVM at Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds