Tag Archives: JCK

JEP 213: Milling Project Coin

Issue 8042880
Depends 8062373: Project Coin: diamond and inner classes
Relates to 8061549: Complete the removal of underscore from the set of legal identifier names
7196163: Project Coin: Allow effectively final variables to be used as resources in try-with-resources
7196160: Project Coin: allow @SafeVarargs on private methods


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


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


Four small amendments to the Java Programming Language are proposed:

  1. Allow @SafeVargs on private instance methods. The @SafeVarargsannotation 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.
  4. Complete the removal, begun in Java SE 8, of underscore from the set of legal identifier names.

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.

JEP 212: Resolve Lint and Doclint Warnings


Relates to

8039501: Fix fallthrough lint warnings in jdk libraries

8032976: Fix serial lint warnings in jdk libraries

8044613: Fix finally lint warnings in jdk libraries

8046270: Fix overrides lint warnings jdk libraries

8039096: Fix raw and unchecked lint warnings in jdk libraries


The JDK code base contains numerous lint and doclint errors as reported by javac. These warnings should be resolved, at least for the fundamental parts of the platform.


Operationally, the goal is to have at least the packages for the fundamental packages in the platform (those discussed on core-libs, awt-dev, swing-dev, 2d-dev, etc.) compile cleanly under javac‘s lint and doclint warnings. It is desirable for other packages, such as those comprising JAXP, JAX-WS, and CORBA to also compile cleanly with all warning enabled.

Success Metrics

A successful build of the sources in question when the -Xlint:all option is used for the javac command. A slightly weaker goal that may be acceptable is for all the source-related lint options to be enabled, but not the lint options for non-source properties. For example, some lint options concern properties of the javac command line rather than the sources being compiled.


This JEP proposes to complete efforts to fix warnings that have been underway in JDK 8 and JDK 9 as well as to formalize a subset of source-code improvements previously proposed to jdk9-dev. Most of the warnings are resolved by modifying the interior of method bodies. Resolving some of rawtypes warnings involves changing method signatures, such as changing a parameter type from a raw java.lang.Class to ajava.lang.Class<?> or some more specific type. Any API changes will stay within the general evolution policy of the JDK.


A successful compile / build is the primary test for most changes, but the existing regression tests should continue to pass. Where a Java SE API has a signature change, the corresponding JCK signature test will need to be updated accordingly.


Resolving the deprecation warnings in the JDK would be eased if importing a deprecated type does not trigger a deprecation warning.