Summary
-------

The small language changes included in Project Coin / [JSR 334][0] 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.

[0]: https://jcp.org/en/jsr/detail?id=334


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:

  1. [Allow @SafeVargs on private instance methods][1]. 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][2].
     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][3] discusses
     the rationale for the change from the [early draft review][4]
     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][6].
     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][5], 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.][8]

  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][7]
      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.


[1]: https://bugs.openjdk.java.net/browse/JDK-7196160
[2]: https://bugs.openjdk.java.net/browse/JDK-7196163
[3]: http://download.oracle.com/otndocs/jcp/enhancements-0.875-pr-oth-JSpec/
[4]: https://jcp.org/aboutJava/communityprocess/edr/jsr334/index.html
[5]: http://download.oracle.com/otndocs/jcp/enhancements-1_0-pfd-spec/index.html
[6]: https://bugs.openjdk.java.net/browse/JDK-8062373
[7]: https://bugs.openjdk.java.net/browse/JDK-8071453
[8]: https://bugs.openjdk.java.net/browse/JDK-8061549