Project Coin: Week 1 Update

In its first week, Project Coin enjoyed a vigorous start with well over a dozen proposals submitted:

Traffic on the the list has been high, with lots of feedback and analysis leading to some revised proposals.

A few general comments on the proposals that have been sent in so far to help refine those proposals and improve future proposals before they are sent in.

The proposals submitted to Project Coin should already be well thought-through. The goal is to have in short order specifications approaching JLS quality, preferably with a prototype to help validate the design. The feedback on the list should be much closer to finding and illuminating any remaining dark corners of a proposal rather than fleshing out its basic structure. If a proposal does not cite chapter and verse of the JLS for parts of its specification, that is a good indication the proposal is too vague. All affected sections of the JLS should be listed, including binary compatibility and the flow analysis in definite assignment.

It is fine if someone posts to the list to solicit help writing a proposal for a given change.

Proposal writers should be aware of the size and scope parameters established for the project; for background see:

Also, proposal writers should search Sun's bug database for bugs related to the change. The URL for the database is; Java specification issues are in category Java SE and subcategory specification. Of course the database is also searchable with your favorite search engine restricted to that site. Besides the evaluation field from the bug database, the external comment can often also have valuable insight into and discussion of alternatives to solving the problem or reasons why the problem shouldn't be solved.

As has already been happening on the list, authors and advocates of a proposal are responsible for responding to feedback and incorporating changes into any subsequent iterations of the proposal. For now, I think it is adequate to just send the revised proposals to the list. Only if there turns out to be frequent change would a more formal tracking system be warranted. Keeping such discussions on the list is important both to allow easy, centralized tracking of the proposal drafts and also for future language archaeologists who are curious about why a particular decision was made.

After a few iterations of feedback and refinements, the specification and compilation strategy should be sufficiently detailed to provide high-confidence that the proposal is practical and can be reduced to practice. For example, I think the initial proposal for the admittedly simple strings in switch change provides adequate detail on these fronts.


Minor, string escape sequence. i.e., @"My string with a " and single '"

Best Regards,
Richard L. Burton III

Posted by Richard L. Burton III on March 06, 2009 at 04:19 AM PST #

I like Java very much (I even LOVE Java). But some
proposals here are trying to trash our nice clean Java
with script-kiddie-like "extensions".

People who like Java AND scripting languages can use Groovy
and JRuby. It is not a reason to trash pure Java.

Syntactic sugar must make sense, when introduced. It must
bring multiple advantages to a lot of use cases, don't
break compatibility, don't introduce something that is
already there, be beautiful, simple, readable,
understandable, intuitive.

If someone of you want to know how clean and rational
syntactic features look like, take C# as an example
(especially the excellent(!!!) property syntax).

Don't get me wrong! Most proposals are really nice.

Please allow me to comment on some of the proposals:

\* Strings in switch
Very nice! Intuitive.

\* Block expressions
Not bad. Why not use '{' '}' as brackets? People would
associate them with a scope.
double pi2 = { double pi = Math.PI ; pi\*pi };

\* Improved exception handling
Very useful and easy to understand.

\* Automatic Resource Management
"(See att.)" - Where is the attachment? ;)

\* Improved type inference for generics
Would improve the readability.

\* Improved wildcard syntax
Just an alternative syntax for something? What would
happen to the readability of Java code, when we had an
alternative syntax for everything?

\* Multiline strings
Inlining lot of text into program code is an indicator for
having a wrong concept. This should not be simplified,
because most people will misuse it. Again, scripting
languages are the right place for such 'features'.

\* Use "default" keyword
I have no opinion on this.

\* Elvis and other null-safe operators
Using null as a return value (to indicate a failure state)
is a bad habit. Simplifying the null-checks will motivate
most people to use null as return state even more often.
I think, such an extension belongs to scripting languages.
BTW, if I correctly understand JSR-305, it specifies nice
compiler hints for null-things.

\* Simple Resource Clean-up - this time with attachment ;)
Using try{} without catch and|or finally IMPLIES closing
of all streams? Most people will misinterpret this.
Why? Because you don't always scroll to the end of each
long method. Syntax must be parseable by humans also ;)
You are writing about the using{} syntax in C#. Well that
syntax is excellent for what you propose!

\* Import aliases for classes and static methods
I think such macro-processing features don't belong to
Java. Look what is happening in C++ with hundreds of
typedefs. You have always to REMEMBER what they mean.

\* Lightweight properties
Again, "scripting language alert!"
This proposal is too special. And, for aesthetic reasons
anything like '#' should not be considered. It looks dirty.

\* This type
Great idea, but I think it's too complex for the coins
project. (BTW,c consider using 'thistype' rather than
'This', because there are NO Java keywords which start
with capital letter)

\* Fold keyword
Hmm, closures take two? But more special? Too special?
Will most people use it ever? And understand it?

\* Multiple switch expressions and case ranges
Case ranges for numbers are not bad. But enums?
You know, using enums with constant vaules is an
anti-pattern. Don't support people by using anti-patterns.

\* Simplified varargs method invocation
No opinion on this.

Posted by Ivan on March 07, 2009 at 10:25 PM PST #

Also, wouldn't it be great to use a wiki for all this?

Commenting blogs is great, but IMO blog comments are not 'persistent' enough for such things ;)

(I mean the information doesn't stay visible long enough)

Posted by Ivan on March 07, 2009 at 10:35 PM PST #

With so many proposals, I was surprised that there wasn't one for arrays with a long (i.e. 64-bit) index. A feature that other JVM languages could benefit from too.


Posted by Ismael Juma on March 08, 2009 at 05:41 AM PDT #

No operator overloading proposals? Because I've thought of two or three...

\* Strings in switch
Good idea.

\* Block expressions
Odd idea. It could be useful, but I'd put it on low priority.

\* Improved exception handling
Could be useful. Also, why can't a catch statement declare a generic type? That could be added fairly easily, I would think.

\* Improved type inference for generics
This is a good idea, and saves typing.

\* Multiline strings
Not necessary. If this behaviour is needed, then you could simply break the string into one string per line and concatenate them with +'s.

\* Use "default" keyword for default visibility
I'm not really sure whether it would be better to use "default" or "package", but it should be extended to encompass top-level classes with default visibility if it isn't already.

\* Elvis and other null-safe operators
Not necessary, but could be very useful. The Elvis operator doesn't really seem more useful than the conditional operator, though – why not simply extend the conditional operator to accept a reference instead of a boolean as the first argument? That would be MORE useful than the Elvis operator, I think.

\* Import aliases for classes and static methods
I think this is a good idea – either that, or a typedef mechanism (though I like the "alias" better as a keyword). Contrary to Ivan's claim, this is not a "macro-processing" feature.

\* Lightweight properties
Again, "scripting language alert!"
This proposal is too special. And, for aesthetic reasons
anything like '#' should not be considered. It looks dirty.

\* Multiple switch expressions and case ranges
Good idea, but how does an enum range make sense?

Posted by Celtic Minstrel on March 09, 2009 at 06:16 AM PDT #

It's a pity nobody made a proposal for improving "for each" loops to make them more usable in some instances.

It is not uncommon, while iterating through a collection, to need to know if the current item is the last one or not (or the first one). It is also sometime useful to find out the index of the current item in the iteration loop.

I had seen such kind of proposal last year (I think that was in devoxx, not sure though). But it seems nobody came out with a proposal for project Coins.

I wish I had enough time to try to provide my own proposal on that but that seems too much work (just take a look at the openjdk list and you'll see what it means to make a proposal...)

Just my 2 cents

Posted by Jean-Francois Poilpret on March 09, 2009 at 08:54 AM PDT #


The Project Coin mailing list is the centralized location for archived comments on this effort.

Posted by Joe Darcy on March 09, 2009 at 11:44 AM PDT #


The enhanced for loop was not meant to replace all uses of the old-style for loop; the original loop pattern can be used when access to the innards of the control state is needed.

Yes, changing the Java programming language can be a significant effort; on the Project Coin mailing list one can enjoy the fun :-)

Posted by Joe Darcy on March 09, 2009 at 11:49 AM PDT #

nice to see that Neal Gafter is still with us

Posted by FF on March 10, 2009 at 12:22 PM PDT #

Multiline strings can be useful in many cases. One example is when you are outputing usage information in cli programs.

But I don't like the current proposal about inventing a new syntax ("""). We should be able to just use standard quotes, and the parser should just continue when it sees a line break.

What would be more usefull is a way to input raw text without parsing escape characters or something. This could be useful for regular expressions.

String regExp = ''\\d+,\\d+'';

Posted by N on March 10, 2009 at 04:16 PM PDT #

I think if you are going to go crazy on the Java language some thought to the "Dimond" inheritance problem should be seriously considered.

Say I have...
public interface SomeTypeA {...}
public interface SomeTypeB {...}

...and implementations...
public abstract class A {...}
public abstract class B {...}

...and both interfaces may change allot, but only a few methods in class A & B need to be implemented.

This is a common situation, but here is the problem...

If I extend one of the classes and implement one of the interfaces, I have to delegate to the other, if the API has this problem in 500 classes (I have seen much more), and each class averages one change a month (I think very conservative)...

There is a lot of work required!


public class MyDimondClass implements SomeTypeA, SomeTypeB {
private SomeTypeA a = new A();
private SomeTypeB b = new B();
@SomeAnnotation( SomeTypeA )
private SomeTypeA getSomeTypeA() { return a; }
@SomeAnnotation( SomeTypeB )
private SomeTypeB getSomeTypeBA() { return b; }

... this is just one idea, but SOMETHING should be done!

there are a few more issues to ensure this works for all situations but you get the idea...

Let me know if you have questions or need/want/wouldent mind help.

PS: Yes obviously this solution would require a recompile every time the interfaces change, but it should not require additional codeing effort, unless the implementation classes do not provide implementations for new methods.

Posted by Todd Musheno on March 14, 2009 at 09:28 PM PDT #

I want to know about the compiler operations on static methods in java.. How it distinguishes from instance methods when invoked by object references

Posted by vicky on May 01, 2009 at 04:15 PM PDT #

I think you miss the idea here...
If you are running into the dimond problem (IN YOUR DESIGN), it is because you need a thing (Object) that is more then 1 type (interface).

If you do not agree with this read a book, or do some design until you do.

So what we are talking about IS inheritance of interfaces (inheritance of more then one static method are supposedly already handled)

If you have 2 interfaces, and 2 classes that implement those interfaces, and lets sat 10,000 classes that need to implement both classes...
We hand code delegation to at least one of those classes, as they know how to do the work, right??

Well lets say I as a designer want to do something crazy, like add a method to both interfaces?

Wow we now have to touch those 10,000 classes to add the delegation right? I sure hope I am missing something!

If there is not a way to ensure when I add a method to one of those interfaces, it does not require someone touching those 10,000 classes (by hand), there should be.

Now I realize that the delegation does need to be done, but having some person do it? OMG!

Shouldn't this just be a simple recompile???
If you think not, please state why you AND Sun thinks this is good for Java.

Posted by Todd Musheno on May 01, 2009 at 11:18 PM PDT #


The code for javac in JDK 7 is in the Mercurial repository:

Look under src/share/classes/com/sun/tools/javac

Posted by Joe Darcy on May 02, 2009 at 04:01 AM PDT #


The onus is on you and others wishing to change the language to put forward a convincing case that the specific change in question is worthwhile.

See the vigorous discussions that took place on the Project Coin list during the now closed call for proposals period:

Posted by Joe Darcy on May 02, 2009 at 05:39 AM PDT #

Post a Comment:
Comments are closed for this entry.



« December 2015

No bookmarks in folder