JavaOne 2009: Project Coin Slides Posted

I presented my technical session about Project Coin, titled more verbosely Small Language Changes in JDK™ Release 7, this afternoon at JavaOne. I've posted the slides. Besides discussing the proposals under further consideration, I also went over some of the experiences from JDK 5 and other considerations we take into account when evolving the language.


I hope that the type inference will not get implemented as proposed by Jeremy Manson. It is unintuitive - usually the LHS infers type from RHS. How would you infer a return type of a function?

Much better choice seems to be the way it is done in C++0x (auto keyword) and in C# (var keyword). I trust that there is some other reason for Jeremy's proposal other than trying to be different than C#...

Let's do Java right, so we can also handle inference of return types.

Just my $0.02

Posted by Filip on June 03, 2009 at 12:49 AM PDT #

Filip- Java already does this kind of type inference for generic methods. It just doesn't do it for constructors (yet).

Posted by Neal Gafter on June 03, 2009 at 03:16 AM PDT #

Neal, my point exactly. There should only be one type of type inference, for anything that can occur on right-hand side.

These should work:
auto x = new List<String>();
auto y = someObject.getSomething();

Posted by Filip on June 03, 2009 at 05:11 AM PDT #


We will not be adding "auto" in JDK 7. We feel it is preferable to keep the type of the variable explicit and have the type variables on the right hand side inferred by the compiler with the diamond operator.

We are aware of the auto/var feature in other language.

Posted by Joe Darcy on June 03, 2009 at 08:52 AM PDT #

Thanks for your answer. I guess I don't know much about the new features, and got nervous when I saw the diamond operator. It seemed really out of place given C++ auto and C# var.
IMHO the type on the rhs seems more flexible, since it could work not only for generics. That way there could be one syntax for handling all cases

auto w = new List<String>();
auto x = new SomeClassName();
auto y = obj.someMethod();
for (auto z: collection) {}

and it would match the other languages out there, which is always a plus (skill reuse for those of us who must work in multiple environments).
Once again, I apologize if my comments are not relevant or out of place. Just being an uninformed observer :)

Posted by Filip on June 03, 2009 at 12:59 PM PDT #

I agree with Filip about preferring an auto keyword – however, I'm also satisfied with the diamond version.

Posted by Celtic Minstrel on June 03, 2009 at 11:52 PM PDT #

Filip, Celtic,

The diamond operator is about reducing the pain of having to repeat TYPE PARAMETERS during initializing a field or variable whose type is generic. It is absolutely not about implicit typing of variables. Those are different issues entirely. the first fits project coin's criteria, the other doesn't.

Posted by Bruce Chapman on June 04, 2009 at 02:34 PM PDT #

I am with the others, Filip & Cedric, the diamond operator doesn't go far enough (and it's ugly). I would prefer auto or inference of type and generic parameters, e.g.:

Box<Integer> bi = new( 1 );

Posted by Howard Lovatt on June 07, 2009 at 08:55 PM PDT #

I agree with Howard, Filip, & Celtic as well. I would much prefer having the 'auto' or 'var' implicitly typed.

Posted by Kevin on June 08, 2009 at 08:59 AM PDT #

I think which is preferable depends on what the strategic direction for the language's evolution is in the future (if any). While having both forms of inference wouldn't be so terrible, this (diamond operator) form would be somewhat redundant with the "var" form if the latter is added in the future as part of some set of strategic changes (e.g. LINQ).

Posted by Neal Gafter on June 08, 2009 at 09:37 AM PDT #

@Howard, @Kevin, and others,

As I have previously stated, auto/var will not be added to the language in JDK 7. Simply repeating "I want auto/var!" will not change that, especially when there is no additional rationale, information, or perspective presented beyond "I want auto/var!"

Posted by Joe Darcy on June 08, 2009 at 10:28 AM PDT #

I guess I am against the diamond operator because it seems like a very specific solution to a very specific problem.
As Kevin writes, it all depends on what future direction Java is going to take. If there are plans to support proper type inference (auto/var), then why pollute the language with a half-baked solution? It's better to wait.
On the other hand, if diamond is all that we will ever get, then why not. Only that would mean that Java will lag behind C++ and C# in terms of usability.

Posted by Filip on June 10, 2009 at 01:23 AM PDT #

Why not do it without the diamond operator? It already works, just loose the 'should be parametrized' warning for constructors?
And it prevents the need for new operators.

Posted by Stef on June 22, 2009 at 07:01 PM PDT #

Well, the diamond operator looks like a dead end!

I have just ended a long post saying that closure and type inference do have relationships:
Facing the wall of closure Java (difficult) adoption

To make easier closure adoption, Java would need a dose of type inference (see my post for arguments), let's take "var" introduction here as an example.

The diamond operator looks like a dead end because:
(1) it is not type inference but a notation shortcut (RHS simplication),
(2) if type inference is later added to Java (through LHS simplication), the diamond operator would be somewhat redundant with type inference and then, ugly.

So, my point is: forget about this operator and please, make Java programming easier through type inference.

Posted by Dominique De Vito on July 05, 2009 at 03:18 AM PDT #

After thinking again about it, the diamond operator could be still useful even with type inference.

Let's imagine the following with type inference:
var list = new ArrayList<String>();

Let say I want to make explicit the type of 'list' like this, in order to restrict this type:
List<String> list = new ArrayList<String>();

Then, the diamond operator is useful for a shortcut:
List<String> list = new ArrayList<>();

PS : anyway, this being said, again, I do think Java needs a good dose of type inference; Java looks falling further and further behind C#.

Posted by Dominique De Vito on July 06, 2009 at 02:22 AM PDT #

If null-safe operators are going to be a part of JDK-7, is it possible to modify the new 'for loop' syntax so that a null pointer exception is not thrown if the list or array over which the loop iterates is null?

Currently the below code will throw a null pointer exception because integerList is null.

List<Integer> integerList = null;
for(Integer i: integerList) {


Posted by Vimil on July 15, 2009 at 08:24 AM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016

No bookmarks in folder