JEP 213: Milling Project Coin

AuthorJoseph D. Darcy
OwnerJoe Darcy
StatusClosed / Delivered
Componenttools / javac
Discussioncompiler dash dev at openjdk dot java dot net
Reviewed byBrian Goetz
Endorsed byBrian Goetz
Created2014/05/09 23:05
Updated2023/06/14 18:04


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, a few amendments could address the rough edges of those changes. In addition, using underscore ("_") as an identifier, which generates a warning as of Java SE 8, should be turned into an error in Java SE 9. It is also proposed that interfaces be allowed to have private methods.


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


Five small amendments to the Java Programming Language 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 anonymous classes if the argument type of the inferred type is denotable. Because the inferred type using diamond with an anonymous class constructor could be outside of the set of types supported by the signature attribute, using diamond with anonymous 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.

  4. Complete the removal, begun in Java SE 8, of underscore from the set of legal identifier names.

  5. Support for private methods in interfaces was briefly in consideration for inclusion in Java SE 8 as part of the effort to add support for Lambda Expressions, but was withdrawn to enable better focus on higher priority tasks for Java SE 8. It is now proposed that support for private interface methods be undertaken thereby enabling non abstract methods of an interface to share code between them.

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.