Update on JSR 334 Expert Group activities

[Joe Darcy]

Hello.

Besides working to address issues identified in the EDR draft [1], such 
as refining the diamond specification, the JSR 334 expert group has been 
considering other matters as well. One change being contemplated is 
removing the ability to have multiple underscores between digits of a 
literal; under that possible change, no underscore or a single 
underscore would be allowed. The primary consideration here is to 
prevent abuses of the underscores in literal feature that would obscure 
program meaning; on the other hand, there may be reasonable uses of 
repeated underscores that are desirable to allow.

The expert group has agreed to one significant change from the EDR 
draft: as called out as a possibility in the draft, support has been 
dropped for the general expression form of the try-with-resources 
statement. That is, support has been removed for passing a resource as a 
general expression without an accompanying explicit variable declaration.

Several technical problems were identified with allowing a general 
expression:

     * Syntactic ambiguity: In the parser, it was not always possible to 
distinguish with one-token look-ahead between the start of an Expression 
and the start of a Type. Consider code like

             try(i < j // Ternary operator on variables i and j
                 ? new Resource1() :
                 new Resource2()) {...}

compared to code like

             try(Box < Resource // Simple generic wrapper around a resource
 > resourceBox = Box<>(new Resource1())) {...}

A natural grammatical fallback short of banning Expression would be to 
only allow a more restricted expression, such as Identifier. However, 
that restricted grammar would require compiler changes to alert 
programmers to some surprising legal code, as given in the following 
examples.

* Usability issues: Consider a try-with-resources statement being used 
to manage an existing variable where the variable is mutated inside the 
try block:

           public class TwrExamples implements AutoCloseable {
              public static void main(String... args) {
                  TwrExamples twrEg1 = new TwrExamples();
                  System.out.println(twrEg1.hashCode());

                  try(twrEg1) {
                      twrEg1 = new TwrExamples();  // Mutating the variable!
                      System.out.println(twrEg1.hashCode());
                  }
              }

              @Override
              public void close() {
                  System.out.println(hashCode());
              }
           }

As try-with-resources was previously specified, this would cause close 
to be called on the original value, not the value twrEg1 pointed to at 
the time the try block finishes. In this case, the printed output of the 
program may be something like:
       1607576787
       1051296202
       1607576787
which indicates that while close was called on the original value, close 
was not called on the new TwrExamples object created inside the 
try-with-resources block. Either policy of calling code on the original 
value or the value on exit of the block could be problematic. The 
compiler did not issue any warnings about this situation and warnings 
should be added if this feature were to be kept. (Mutating a resource 
variable declared as part of the try-with-resources statement is illegal 
since such variables are implicitly or explicitly final).

Other complications that stemmed from supporting a general expression as 
a resource were making sure the specification and implementation 
accepted both

        try(null) {...}

and

        try(myGenericMethodThatInfersTheTypeOfItsResult()) {}

as valid programs.

The main rationale for supporting general expressions was to allow 
non-Closeable objects, such as locks, to be easily wrapped in a suitable 
type to enjoy the call-method-on-block-exit guarantees of 
try-with-resources. When this is desirable, the same effect can still be 
achieved with an explicit resource declaration. As experience is gained 
with try-with-resources, extensions to support other usage patterns will 
be considered in future releases.

I'm working with the javac team to remove support for this feature in an 
upcoming JDK 7 build.

-Joe

[1] http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002956.html