Draft JEP for comment: Milling Project Coin: softening some rough edges

[Joe Darcy]

Hello,

For your consideration, I submit a draft JEP covering

     Milling Project Coin: softening some rough edges
     https://bugs.openjdk.java.net/browse/JDK-8042880

Full text of the JEP is below. To be clear, this is *not* a call to run 
"Coin 2.0," nor is it an effort to work on features that were dropped 
from Project Coin. This JEP is just to describe some maintenance-level 
changes, most of which were identified as possible future work in the 
JSR 334 drafts.

Thanks,

-Joe


Summary

The small language changes included in Project Coin / JSR 334 as part of 
JDK 7 / Java SE 7 have been easy to use and have worked well in 
practice. However, several amendments could address a few rough edges of 
those changes.


Non-goals

This JEP does *not* propose to run a "Coin 2.0" effort or to generally 
solicit new language proposals.


Description

Three amendments to the Project Coin features are proposed:

1)    Allow @SafeVargs on private instance methods. The @SafeVarargs 
annotation can only be applied to methods which cannot be overridden, 
including static methods and final instance methods. Private instance 
methods are another use case that @SafeVargs could accommodate.

2)    Allow effectively final variables to be used as resources in the 
try-with-resources statement. The final version of try-with-resources 
statement in Java SE 7 requires a fresh variable to be declared for each 
resource being managed by the statement. This was a change from earlier 
iterations of the feature. The public review draft of JSR 334 discusses 
the rationale for the change from the early draft review version of 
try-with-resource which allowed an expression managed by the statement. 
The JSR 334 expert group was in favor of an additional refinement of 
try-with-resources: if the resource is referenced by a final or 
effectively final variable, a try-with-resources statement can manage 
the resource without a new variable being declared. This restricted 
expression being managed by a try-with-resources statement avoids the 
semantic issues which motivated removing general expression support. At 
the time the expert group settled on this refinement, there was 
insufficient time in the release schedule to accommodate the change.

3)    Allow diamond with inner classes if the argument type of the 
inferred type is denotable. Because the inferred type using diamond with 
an inner class constructor could be outside of the set of types 
supported by the signature attribute, using diamond with inner classes 
was disallowed in Java SE 7. As noted in the JSR 334 proposed final 
draft, it would be possible to ease this restriction if the inferred 
type was denotable.

In the space of Java language changes, these refinements are very small 
changes. The @SafeVarags change might only involve changing a sentence 
or two of the specification with a similarly sized change in javac. 
However, as with any Java language change, care must be taken to handle 
all the pieces of the platform that need updating.


Testing

The language changes would require the usual unit and regression tests 
for javac. The JCK compiler suite would need to be updated, both 
positive tests and negative tests.