Java SE 7 wish list

« JDK7 b05 compiler... | Main | Kitchen Sink Languag... »

Search

Referers

Dec 15 2006, 12:00:00 PM PST »Java»Language Comments [89]

With JDK 6 released, we are considering features for inclusion in JDK 7. Here is a list of things I would like to see (in no particular order):

Real closures

Neal has written a lot on this topic and I support his efforts. See Closures for Java (v0.3).

Type literals

Another (minor) proposal from Neal is type literals. See Super Type Tokens and Type Literals.

Super packages

This was originally suggested by Gilad Bracha, see Developing Modules for Development and JSR 294.

Improved type inference

Using generic methods can be hard if you do not understand how inference works. In particular, why does something like this not compile:

String s1 = Collections.max(Collections.emptySet());
String s2 = Collections.max((Set<String>)Collections.emptySet());

Most developers are not familiar with implicit type arguments but you have to use them when inference fails:

String s = Collections.max(Collections.<String>emptySet());

The original GJ compiler (which was the foundation for adding generics) did better. However, the specification was found to lead to an unsound type system and we did not find an alternative specification we had confidence in. I would like to investigate if we can do better now that we have more experience.

Shorthand syntax for declaring local variables

Most people familiar with either JavaScript or C# would like to have some feature that allows the compiler to guess the type of local variables. It has been proposed to add a new keyword (var) for this purpose. I would prefer not adding a new keyword as this can break a lot of existing programs. I discussed this with Christian Plesner Hansen on his last visit to Mountain View. He had a very simple solution that I really like:

final strings = new ArrayList<String>();

Christian's solution implies that you cannot assign the variable more than once. However, the more I think about this, the more I like it. We do not need to add a new keyword and if you don't want to specify the type of a variable, you should probably not assign to it later.
James Gosling suggested using := for declaring local variables without specifying the type. One way or the other, I think the language would benefit from having a shorthand.

Shorthand syntax for declaring properties

final property String name = "Name";
property String address;

becomes

final private String name = "Name";
public String getName() { return name; }
private String address;
public String getAddress() { return address; }
public void setAddress(String address) { this.address = address; }

Notice that property need not be a keyword.

Type aliasing

A while back, Gilad and I came up with this:

import java.util.List<String> as StringList;

Notice that as need not be a keyword.

Array syntax for collections

How sweet is this:

final map = new HashMap<String, Integer>();
map["one"] = 1;

More factory methods for collection classes

We have too few factory methods in the collection classes so you can write:

ArrayList<String> strings = ArrayList.of("a", "b", "c");

Self-types

I have mentioned self-types before.

Improved compiler diagnostics

Many diagnostics of javac are confusing, especially to new users:

String s = 1;

This gives this error message:

Test.java:3: incompatible types
found   : int
required: java.lang.String
        String s = 1;
                   ^
1 error

This would be better:

Test.java:3: attempt to assign an expression of type int
to a variable with an incompatible type (java.lang.String)
        String s = 1;
        ^^^^^^^^^^^^

Things I do not Wish for

Strings in switch statements: I would not mind seeing more types accepted in switch statements but I do not care that much for this.
XML literals: I would not like to see specialized XML-literals or multi-line strings but it would be interesting to examine if we can come up with a general syntax for many kinds of literals, including XML, SQL queries, RegExps, and XPath. But then again, I do not really care too much for this.
Shorthand syntax for accessing properties: You cannot overload '.' (dot) to mean property access because it would create strange rules (what happens if you have a field foo and a method getFoo()?) and be confusing. (is it field access or a method call with potential unknown side-effects?) On the other hand, it has to be '.' (dot). Anything else would look silly. I think this is unsolvable.

Post a Comment:

Comments are closed for this entry.

Comments:

What are your arguments against multiline String literals? For most code it makes sense to embed small (say 5 lines max) "foreign languages" (like SQL queries) as a final variable or class constants. The current approach really uglifies code by adding a plethora of quotes, + concatenations and character escapes. It makes support for nested language lexers in IDEs a bit harder too...

Posted by Taras Tielkes on December 15, 2006 at 12:44 PM PST #

I would rather see a general solution for embedding foreign languages than hacks like multi-line strings or narrowly scoped features such as XML literals.

Posted by Peter von der Ahé on December 15, 2006 at 12:57 PM PST #

I agree on almost all counts (both wish and do not wish). "final" is a more natural choice for type inference.

String switch statements would just encourage more use of strings which we do not need. XML literals are insane.

Consider this entry shared.

Posted by Bob Lee on December 15, 2006 at 01:57 PM PST #

I am concerned.

Maybe I'm an old stick in the mud or something but one of the things that has made me keep coming back to Java is that the code is nice and readable. Compare any Java program to Perl or C or almost any other language and I think most people would agree that the Java one is easier to follow. Why? A nice straightforward syntax. Not a lot of keywords. No pointers. In short, it's because of all the things that Java didn't do that made the language so readable. So it concerns me that we adding all these new shiny baubles to the language without considering what it will do to the long-term maintainability of the code, the readability that makes it so nice to work with etc.

I would far rather that you focused on the usability of the existing Java APIs, on adding new APIs like NIO2 that keeps getting delayed, improved memory usage and performance.

Please remember that every time you add a feature to the language that (unless you're very careful) you're reducing the readability of the code that will be eventually written.

I think the original designers of the language did a very good job of balancing features vs. readability etc... It concerns me that the people that are now in charge of the language aren't considering this so much. All the closure proposals I've seen seem to involve ugly syntax to the language. Shorthand syntax for local variable assignment? A new assignment operator (:=) ... Ugh. IMHO, it's not worth it. Please. Don't clutter up the language. Don't turn it into Perl where there are at least 49 ways to express the same thing.

Thanks,
Corey

Posted by Corey Puffalt on December 15, 2006 at 06:28 PM PST #

Corey, somehow your comment got flagged as spam. Sorry about that.

This is my personal wish list. I do not decide what actually happens. But since everybody else are public about what they want, I felt I had to make my preferences known as well.

I'm a compiler engineer and I implement language features and the purpose is to make existing API easier to use. But that has nothing to do with NIO2. But speaking of it, I'm convinced that the new NIO2 guy will get something done.

BTW: I find your comment about ':=' very funny given that it was suggested by James Gosling.

Posted by Peter von der Ahé on December 15, 2006 at 08:10 PM PST #

About shorhand syntax for accessing properties, I have had a look at http://www.weiqigao.com/blog/2006/12/07/you_wont_believe_this_but_the_arrow_operator_is_coming_to_java_7.html I love the idea to use new arrow operator instead of plain old dot one. However, I see the line a->Foo = b->Foo; I think that it will introduce a Sun's Java coding convention conflict.

Posted by pcdinh on December 15, 2006 at 11:28 PM PST #

Things like a->Foo is what makes me really dislike proposals for property access.

Posted by Peter von der Ahé on December 16, 2006 at 07:44 AM PST #

Just coming back to Groovy to see how it use dot operator to access properties in a Map aMap.(propertyName) I dont know why Java Team does not like this syntax. I guess that there is a technical obstacle to this approach.

Posted by pcdinh on December 17, 2006 at 01:32 AM PST #

My wishlist: Writing JavaBean in Java 5.0, 6.0 is a tedious and time-consuming task. It would be great if Java 7.0 support a official way to make it more productive and fun by using annotation: class User { @Property private int userId; @Property (getter=getUserName, setter=setUserName) private String userName; }

Posted by pcdinh on December 17, 2006 at 02:03 AM PST #

Multi-line strings would really simplify reading xml, sql, etc... It would be nice to have a shorthand syntax for map elements. Type aliasing could provoke a producing more literals that would make to read and understand java programs more difficult.

Posted by Igor Katrayev on December 17, 2006 at 03:25 PM PST #

Hi Peter Nice list. It is a bit ironic to see C++ typedefs proposed for Java 7!! I personally dont like the arrow operator for property access, I prefer the C#-style property keyword - I think its much cleaner and more consistent. Agreed on the array-style syntax for collections - another long standing C++ feature. And the Collections/Array classes could certainly do with a few more convenience factory methods! PS Its incredibly hard to post a comment on this blog :-(

Posted by Rory Winston on December 18, 2006 at 02:17 AM PST #

Hi everybody, i've patched javac to provide a prototype that allows the syntaxes decribed by James Gosling and Christian Plesner Hansen for declaring local variables.

The prototype is downlodable on my blog.

Let me know what you thinking.

Rémi

Posted by Rémi Forax on December 18, 2006 at 03:01 AM PST #

Rory, something has changed in regards to spam settings. Everything seems to get caught and I have manually remove the spam-bit from many comments all of a sudden.

Posted by Peter von der Ahé on December 18, 2006 at 03:12 AM PST #

I am in broad agreement with you about additions that would be beneficial to Java and a while back blogged about Clear, Consistent, and Concise Syntax . The blog suggests syntax like:

withLock lock, method{out.println "Hello"}; // Note no brackets and method{} for a closure

declare sum = 0; // Integer, for int use: int sum = 0 or declare int sum = 0

final strings = ArrayList< String >.new.add "A"; // Note Type.new instead of new Type for backward compatibility

method toString { "Hello" } // Overridden method declaration with return inferred

new( i ) { default } // Constructor uses new and infer argument type from field of same name and default means copy of argument into field - ML like but more flexible

method getName { default } // Read access to a variable of name Name - similarly setName

Plus some shortening and improved consistency for generic declarations

The point of this syntax is, as the name suggests, to be Clear, Consistent, and Concise (in that order). In particular the syntax uses

keyword( ... ) { ... }

to be consistent with other Java constructs like

if

, etc.

The C3S syntax presented in the blog referenced above comes from earlier attempts, notably RFE 6389769 and a previous blog. In both these cases I consistently got feedback that the essence of Java is clear and consistent syntax that uses keywords. Hence the C3S proposal.

What do people in this forum think?

PS Sorry about the blocks - it was the only way I could get a code like font on the blog!

Posted by Howard Lovatt on December 18, 2006 at 05:51 PM PST #

Closure - not really. Feels like too much overlapping with other features in the language, even though it could make other things possible. IMO a language should stay concise, i.e. minimising the number of ways to accomplish any given task.

Type Literal - quite cool from completeness point of view.

Super packages - will need to see how it gets on with existing visibility mechanism. One can't erase history in the Java Language ;-)

Improved Type Inference - yeah, why not? I like the challenge from an academic point of view as well.

Shorthand syntax for declaring local variables - "final" is definitely an elegant solution. Especially that means the keyword would get used more often, hence could save me a lot of trouble when debugging / fixing others' code!

Shorthand syntax for declaring properties - I think Tools is the answer to this, not the language itself.

Type aliasing - could potentially becomes as confusing as #define. And it's probably just me but I really quite like the verbosity - just get yourself a bigger / wider screen :-D

Array syntax for collections - nice, but not very Java-ish to me and would make the language less "concise".

More factory methods for collection classes - or constructors? Can be decided through a popularity vote I suppose.

Self-types - hmmm... I don't have any compelling use cases off the top of my head. So I shall kindly skip this one :-P

Improved compiler diagnostics - always a nice & ongoing work.

Strings in switch statements - ugh, go away! *takes deep breathe* I mean, what are the gains beside introducing another possibility to do the same thing?

XML literals - indeed embedding these stuff outside the Java source code, e.g. through property files with IDEs' aid seem to be the better way.

Shorthand syntax for accessing properties - can't really see what we can gain from this. Really.

Posted by Alex Lam on December 21, 2006 at 12:04 AM PST #

marked as spam?!

Posted by Alex Lam on December 21, 2006 at 12:05 AM PST #