Draft JEP for comment: Milling Project Coin: softening some rough edges
joe.darcy at oracle.com
Wed May 28 02:14:23 UTC 2014
For your consideration, I submit a draft JEP covering
Milling Project Coin: softening some rough edges
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.
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
This JEP does *not* propose to run a "Coin 2.0" effort or to generally
solicit new language proposals.
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.
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.
More information about the compiler-dev