Update on JSR 334 Expert Group activities

[Reinier Zwitserloot]

One good reason to disallow multiple underscores is to keep multiple
underscores available for future language expansion. Presumably JDK7 isn't
the last java release to have new language features. I admit I can't think
of anything that would be best served by multiple underscores, but who knows
what java needs 5 years from now?


 --Reinier Zwitserloot



On Sat, Jan 22, 2011 at 12:22 AM, Joe Darcy <joe.darcy at oracle.com> wrote:

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