JEP 213: Milling Project Coin
Author | Joseph D. Darcy |
Owner | Joe Darcy |
Type | Feature |
Scope | SE |
Status | Closed / Delivered |
Release | 9 |
Component | tools / javac |
Discussion | compiler dash dev at openjdk dot java dot net |
Effort | S |
Duration | M |
Reviewed by | Brian Goetz |
Endorsed by | Brian Goetz |
Created | 2014/05/09 23:05 |
Updated | 2023/06/14 18:04 |
Issue | 8042880 |
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, 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.
Non-goals
This JEP does not propose to run a "Coin 2.0" effort or to generally solicit new language proposals.
Description
Five small amendments to the Java Programming Language are proposed:
-
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. -
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.
-
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.
-
Complete the removal, begun in Java SE 8, of underscore from the set of legal identifier names.
-
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.
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.