Friday Apr 01, 2011

Project Coin: Disabling exception suppression

As part of the library support for the try-with-resources statement, several API changes were made to Throwable including an addSuppressed method to allow suppressed exceptions to be recorded. As discussed on coin-dev, to support VM needs for reusable exception objects, a protocol was devised to disable the suppression mechanism so that a zero-length array would be returned from getSuppressed even if addSuppressed was called with a valid argument. The mechanism was a bit of a kludge, relying on an initial call to addSuppressed with a null argument, and the design was called out as such. I'm happy to report the JSR 334 expert group has devised a more elegant protocol to disable exception suppression: a new constructor is added to Throwable which supports disabling suppression. The existing constructors of Throwable always enable suppression and addSuppressed(null) now always throws a NullPointerException. A few exception and error types in the platform are allowed by behave as if their objects were created with suppression disabled. The fix was recently pushed and will appear in a future JDK 7 build.

Thursday Mar 24, 2011

Project Coin: JSR 334 in Public Review

After successfully going through early draft review, JSR 334 has now entered another phase: public review. Compared to the earlier draft review specification (v0.75), the main changes in the public draft review specification (v0.875) are:

  • The specification for diamond was expanded and clarified. Using diamond on a non-generic class is explicitly forbidden.

  • The specification for multi-catch was expanded and made more precise.

  • Several changes related to the try-with-resources feature:

    • The try-with-resources statement has dropped support for a resource to be given as a general expression without an accompanying explicit variable declaration.

    • An optional trailing semicolon is allowed to terminate the sequence of resources in a resource specification rather than producing a syntax error.

    • The compiler-generated calls to the close method of a resource in a try-with-resources statement only occur if the resource is non-null.

    • Strong warnings were added to the javadoc of AutoCloseable about having the close method throw InterruptedException.

  • The @SafeVarargs annotation was applied to appropriate places in the platform libraries.

  • JLSv3 changes were provided for the simplified varargs method invocation feature.

The public review draft of JSR 334 is the last expected JCP milestone before proposed final draft, so get your comments about the public review in soon!

Tuesday Mar 22, 2011

Project Coin EclipseCon 2011

This afternoon at EclipseCon I gave a talk on Project Coin: Small Language Changes in JDK 7; the slides have been posted. An earlier talk at the conference gave a demo of the current Eclipse support for the Project Coin features; my talk included a demo of the "quick fix" hints to introduce Coin features in code provided by NetBeans 7.0 Beta 2.

Monday Mar 14, 2011

JSR 269 Maintenance Review

As a planned part of Java SE 7, JSR 269, which standardized an API for annotation processing, is now undergoing maintenance review. In the JCP, a maintenance review is a process to take comments on small changes so that those small changes can be formally incorporated into an existing specification without running a whole new JSR. The changes being proposed in the JSR 269 maintenance review are the changes already implemented in the JSR 269 APIs in JDK 7. In summary, those proposed changes are:

  • Clarified interaction between the Filer and rounds.

  • Constructors explicitly added to the kinds of elements that can be returned by RoundEnvironment.getElementsAnnotatedWith.

  • New enum constant javax.lang.model.SourceVersion.RELEASE_7.

  • In the package description of javax.lang.model.element, requirements on when a model must be provided are loosened to remove the requirement in case of an "irrecoverable error that could not be removed by the generation of new types," a condition which includes but is not limited to syntax errors.

  • New exception type javax.lang.model.UnknownEntityException added as a common superclass for existing exception types UnknownAnnotationValueException, UnknownElementException, and UnknownTypeException.

  • New enum constant javax.lang.model.element.ElementKind.RESOURCE_VARIABLE.

  • New mixin interfaces Parameterizable and QualifiedNameable added to package javax.lang.model.element. ExecutableElement and TypeElement are retrofitted to extend Parameterizable; PackageElementand TypeElement are retrofitted to extend QualifiedNameable.

  • Behavior of getEnclosingElement method defined to return the generic element of a type parameter instead of null.

  • New interface javax.lang.model.type.DisjunctiveType to model disjunctive types.

  • New enum constant javax.lang.model.type.TypeKind.DISJUNCTIVE to mark disjunctive types.

  • New method visitDisjunctive added to visitor interface javax.lang.model.type.TypeVisitor. Utility visitor implementations updated accordingly.

  • In the package javax.lang.model.type, MirroredTypesException retrofitted to be the superclass of MirroredTypeException.

  • New utility visitors for release 7 in package javax.lang.model.util:

    • AbstractAnnotationValueVisitor7

    • AbstractElementVisitor7

    • AbstractTypeVisitor7

    • ElementKindVisitor7

    • ElementScanner7

    • SimpleAnnotationValueVisitor7

    • SimpleElementVisitor7

    • SimpleTypeVisitor7

    • TypeKindVisitor7

  • The visitors ElementKindVisitor6, ElementScanner6, and SimpleElementVisitor6, are updated to account for new element kind RESOURCE_VARIABLE.

  • The visitor AbstractTypeVisitor6 is updated to account for the possibility of visiting a DisjunctiveType.

  • Definition of documentation comment added to javadoc of javax.lang.model.util.Elements.getDocComment.

Tuesday Mar 01, 2011

Project Coin: Developer Preview Documentation

I've posted documentation of the semantics of the Project Coin features as implemented in the JDK 7 developer preview, b130, at:
http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html

Before sending in comments or questions about a feature to coin-dev, please read the discussion section after a feature. Many design considerations are discussed in those sections. Additionally, some known bugs in the current implementation are noted in the text. In particular, javac in the JDK 7 developer preview erroneously accepts diamond combined with non-generic classes and accepts some uses of diamond with anonymous inner classes. These bugs will be corrected in future builds.

Monday Feb 28, 2011

OpenJDK 6: A changing of the guard

The first public source drop of OpenJDK 6 went out just over three years ago. I've been the release manager for the project for all that time and for the preceding six months while the effort was incubating inside of Sun. Somewhat later than anticipated at the start, all initial goals for the project have long been met, with a public master code repository worked on by both the internal and external community members and a code base that can be used to build a fully compatible implementation of Java SE 6. Combined with the IcedTea 6 set of patches and additions, the code from OpenJDK 6 is used to build the JDK packaged with many Linux distributions.

However, to have more time to spend on other projects, effective immediately I've turned over release management responsibilities for OpenJDK 6 to my colleague Kelly O'Hair. Kelly has considerable experience with JDK development in general and OpenJDK 6 in particular. Kelly has made major contributions to OpenJDK 6 throughout all phases of the project, starting from its inception, to the synthesis of its public Mercurial repositories with history information, to the recent purging of the despised binary plugs.

While I have some sadness in relinquishing leadership of the project, I'm happy to be leaving OpenJDK 6 release management in Kelly's capable hands.

OpenJDK 6: b22 regression test results

Running with the jtreg flags, "-a -ignore:quiet -ea -esa" in all repositories, using generally accessible hosts for the network configuration file, and adding "-s" for langtools, the basic regression test results on Linux for OpenJDK 6 build 22 are:

  • HotSpot, 97 tests passed and 1 failed.

  • Langtools, 1,391 tests passed.

  • JDK, 3,300 tests pass, 30 fail, and 3 have errors.

The preponderance of changes in b22 were for security fixes; the hotspot and langtools tests results are identical to b21:

0: b21-hotspot/summary.txt  pass: 97; fail: 1
1: b22-hotspot/summary.txt  pass: 97; fail: 1

No differences
0: b21-langtools/summary.txt  pass: 1,391
1: b22-langtools/summary.txt  pass: 1,391

No differences

And in jdk, the results were nearly identical:

0: b21-jdka/summary.txt  pass: 3,295; fail: 33; error: 4
1: b22-jdk/summary.txt   pass: 3,300; fail: 30; error: 3

0      1      Test
error  pass   com/sun/jdi/DoubleAgentTest.java
fail   pass   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java
fail   pass   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java
fail   pass   java/awt/Focus/TranserFocusToWindow/TranserFocusToWindow.java
---    pass   tools/launcher/LibraryPath.java

5 differences

(The b21 baseline for the jdk repository was the test run where assertions where enabled.

OpenJDK 6 b22 Source Bundle Published

On February 28, 2011 the source bundle for OpenJDK 6 b22 was published.

The main changes in b22 are the latest round of security updates; in addition, there are a few copyright and licensing fixes. A detailed list of all the changes in b22 is also available.

Tuesday Feb 22, 2011

Project Coin: Trying out try-with-resources in the JDK

As part of the "coinification" the JDK libraries, after first forging some diamonds, Stuart has been working on introducing systematic usage of try-with-resources into the JDK code base. Initially, this effort introduced try-with-resources in URLJarFile.java and in javax.sql; more changes are on the way.

Besides directly improving the code base, these efforts also help inform design decisions about how to make the feature more useful in practice.

The try-with-resources statement can also be helpful in new code. In a recent update to the file system API portion of JSR 203, try-with-resources is used throughout the utility methods in java.nio.file.Files and in other portions of the code and tests for JSR 203.

There is a limited amount of time remaining to make adjustments to try-with-resources in JDK 7. Additional reports on experiences using try-with-resources, and other Project Coin features, would be helpful, either to report issues or validate the current design and implementation. For widest discussion, feedback can be sent to the coin-dev alias.

Wednesday Feb 16, 2011

Project Coin:try-with-resources on a null resource

After due consideration the JSR 334 expert group has decided the semantics of the try-with-resources statement on a null resource should be changed as follows: the compiler-generated calls to close a resource will only occur if the resource is non-null.

Concretely, the semantics of the desugaring of the finally block are changed from

finally {
  if (#primaryException != null) {
    try {
      #resource.close();
    } catch(Throwable #suppressedException) {
      #primaryException.addSuppressed(#suppressedException);
    }
  } else {
    #resource.close();
  }
}

to

finally {
  if (#primaryException != null) {
    try {
      if(#resource != null)
        #resource.close();
    } catch(Throwable #suppressedException) {
      #primaryException.addSuppressed(#suppressedException);
    }
  } else {
      if(#resource != null)
        #resource.close();
  }
}

This decision was informed by discussions on coin-dev as well as experiments retrofitting try-with-resources onto the JDK libraries.

The change allows idioms like

try(Resource r = methodThatMightReturnNull()) {
    if (r == null)
       return; // nothing to do
}

to complete normally without generating a null pointer exception. Note that the programmer still has responsibility to check for a null resource if the resource is used inside the try block; the generated null check does not occur before the try block is entered.

Implementing the change is being tracked under Oracle bug 7020047 "Project Coin: generate null-check around try-with-resources close call."

Tuesday Feb 08, 2011

FOSDEM 2011: OpenJDK 6 and Project Coin

At FOSDEM last weekend, I gave two presentations, one on OpenJDK 6 and the other on Project Coin.

In "The State of OpenJDK 6," after providing some historical context, I discussed various upcoming changes. As relayed elsewhere, Kelly O'Hair will be assisting in OpenJDK 6 release management and security fixes to OpenJDK 6 from Oracle will continue through the end-of-life of the JDK 6 train, which per Oracle policy will occur no sooner than July 2012 (one year after JDK 7 ships GA). Also of note, after JDK 7 ships GA, Oracle will continue development of the 7 update releases in the open, similar to how it has been done pre-GA. In particular, there will not be the same dichotomy between the OpenJDK 7 code base and the 7 update code base as there is between OpenJDK 6 and the 6 update train.

I prepared some additional slides about OpenJDK 6, but did not present them due to time considerations. In the backup portion of slide deck, slide 13 graphs that since b11 the majority of fixes pushed into OpenJDK 6 have been HotSpot changes with the corba, jaxp, and jaxws areas clearly in maintenance. Slides 15 and 16 cover OpenJDK 6 regression test results since b11. There has been a growing number of tests and the overall pass rate is high and generally increasing; langtools and hotspot recently typically have a 100% pass rate and the pass rate for the jdk repository has risen from 98% to 99%.

For Project Coin, I presented the current state the language changes, discussed the development of changes, and spoke briefly on some aspects of developing the changes in the open.

All in all, another fun year at FOSDEM; next time, I hope I'm less afflicted with jet lag!

Monday Jan 31, 2011

Project Coin: How to Terminate try-with-resources

In addition to mulling over nulling in the try-with-resources statement, the JSR 334 expert group has decided to slightly amend the syntax of try-with-resources statement: an optional trailing semicolon will now be allowed to terminate the list of resources.

Previously, a semicolon could only be used as a separator between two resources as in

try(Resource r0 = new Resource(); Resource r1 = new Resource(); Resource r2 = new Resource()) {...}

or reformatted as

try(Resource r0 = new Resource();
    Resource r1 = new Resource();
    Resource r2 = new Resource()) {...}

However, including an extraneous semicolon at the end of the list would be rejected as a syntax error:

try(Resource r0 = new Resource();
    Resource r1 = new Resource();
    Resource r2 = new Resource();) {...}  // Illegal under JSR 334 EDR!

While requiring a semicolon at the end of a list of resources would be excessive, especially when there is only a single resource being managed, optionally allowing a terminating resource offers several advantages. First, when adding a resource to the list of resources being managed, there are fewer necessary edits when cutting and pasting. More importantly, programmatic generation of code is simplified since the code generation logic does not need to know ahead of time whether or not a particular resource will be the last one when the declaration for that resource is generated. The simple rule "terminate a resource declaration with a semicolon" will result in acceptable code, even if the code is not ideal style-wise. Finally, allowing an optional trailing semicolon is consistent with the handling of commas in array initializers,

int[] values = {1,
                2,
                3,  // Legal
               };

and the handling of commas in the declaration of enum constants.

enum PrimaryColor {
    RED,
    GREEN,
    BLUE,  // Legal
    ;
}

The full amended grammar for try-with-resources which allows the optional trailing semicolon is:

TryStatement:
try Block Catches
try Block Catchesopt Finally
try ResourceSpecification Block Catchesopt Finallyopt
ResourceSpecification:
( Resources ;opt )
Resources:
Resource
Resource ; Resources
Resource:
VariableModifiersopt Type VariableDeclaratorId = Expression

The necessary compiler changes to implement the revised grammar have been pushed into a JDK 7 integration repository and will appear in a promoted build in due course.

Monday Jan 24, 2011

Project Coin: Safe Varargs in JDK Libraries

Back for JDK 7 build 123, the language support for the Project Coin's safe varargs feature was pushed; the time has come to update the libraries to take advantage of this feature.

Following the same general methodology used to systematically flush out types that should be made Closeable or AutoCloseable, I wrote an annotation processor to identify candidate varargs methods and constructors where adding a @SafeVarargs annotation might be appropriate.

Several JDK library methods were known candidates for @SafeVarargs; running the annotation processor found another one. The complete list of methods to be annotated in a java.\* or javax.\* package is:

  • public static <T> List<T> java.util.Arrays.asList(T... a)
  • public static <T> boolean java.util.Collections.addAll(Collection<? super T> c, T... elements)
  • public static <E extends Enum<E>> java.util.EnumSet<E> EnumSet.of(E first, E... rest)
  • protected final void javax.swing.SwingWorker.publish(V... chunks)

After this update, many fewer spurious unchecked warnings will be reported when calling core library classes.

Friday Jan 21, 2011

OpenJDK 6: b21 regression test results

Running with the usual jtreg flags, "-a -ignore:quiet" in all repositories, using generally accessible hosts for the network configuration file, and adding "-s -ea -esa" for langtools, the basic regression test results on Linux for OpenJDK 6 build 21 are:

  • HotSpot, 97 tests passed and 1 failed.

  • Langtools, 1,391 tests passed.

  • JDK, 3,300 tests pass, 29 fail, and 3 have errors.

More HotSpot tests were added and all but one pass; the new failing test is improperly platform-specific:

0: b20-hotspot/summary.txt  pass: 85
1: b21-hotspot/summary.txt  pass: 97; fail: 1

0      1      Test
---    pass   compiler/6431242/Test.java
---    pass   compiler/6894807/IsInstanceTest.java
---    pass   compiler/6932496/Test6932496.java
---    pass   compiler/6946040/TestCharShortByteSwap.java
---    pass   compiler/6958485/Test.java
---    pass   compiler/6973329/Test.java
---    pass   compiler/6982370/Test6982370.java
---    pass   compiler/7002666/Test7002666.java
---    pass   gc/6581734/Test6581734.java
---    pass   runtime/6626217/Test6626217.sh
---    pass   runtime/6888954/vmerrors.sh
---    pass   runtime/6925573/SortMethodsTest.java
---    fail   runtime/6929067/Test6929067.sh

13 differences

In langtools some tests were added and all the tests continue to pass:

0: b20-langtools/summary.txt  pass: 1,365
1: b21-langtools/summary.txt  pass: 1,391

0      1      Test
---    pass   tools/javac/6508981/TestInferBinaryName.java
---    pass   tools/javac/6734819/T6734819a.java
---    pass   tools/javac/6734819/T6734819b.java
---    pass   tools/javac/6734819/T6734819c.java
---    pass   tools/javac/6889255/T6889255.java
---    pass   tools/javac/T6595666.java
---    pass   tools/javac/T6625520.java
---    pass   tools/javac/T6705935.java
---    pass   tools/javac/T6956638.java
---    pass   tools/javac/api/6411310/Test.java
---    pass   tools/javac/api/6440333/T6440333.java
---    pass   tools/javac/api/6733837/T6733837.java
---    pass   tools/javac/api/Sibling.java
---    pass   tools/javac/api/T6483788.java
---    pass   tools/javac/api/T6501502.java
---    pass   tools/javac/api/T6838467.java
---    pass   tools/javac/api/T6877206.java
pass   ---    tools/javac/policy/Test.java
pass   ---    tools/javac/policy/Test.java#id1
pass   ---    tools/javac/policy/Test.java#id2
pass   ---    tools/javac/policy/Test.java#id3
pass   ---    tools/javac/policy/Test.java#id4
pass   ---    tools/javac/policy/Test.java#id5
pass   ---    tools/javac/policy/Test.java#id6
pass   ---    tools/javac/policy/Test.java#id7
---    pass   tools/javac/policy/test1/Test1a.java
---    pass   tools/javac/policy/test1/Test1a.java#id1
---    pass   tools/javac/policy/test1/Test1a.java#id2
---    pass   tools/javac/policy/test1/Test1a.java#id3
---    pass   tools/javac/policy/test1/Test1a.java#id4
---    pass   tools/javac/policy/test1/Test1a.java#id5
---    pass   tools/javac/policy/test1/Test1a.java#id6
---    pass   tools/javac/policy/test1/Test1a.java#id7
---    pass   tools/javac/policy/test1/Test1b.java
---    pass   tools/javac/policy/test1/Test1b.java#id1
---    pass   tools/javac/policy/test1/Test1b.java#id2
---    pass   tools/javac/policy/test1/Test1b.java#id3
---    pass   tools/javac/policy/test2/Test.java
---    pass   tools/javac/policy/test2/Test.java#id1
---    pass   tools/javac/policy/test2/Test.java#id2
---    pass   tools/javac/policy/test2/Test.java#id3
---    pass   tools/javac/policy/test3/Test.java

42 differences

And in jdk, a small percentage of tests were added and the existing tests have generally consistent results:

0: b20-jdk/summary.txt  pass: 3,273; fail: 33; error: 2
1: b21-jdk/summary.txt  pass: 3,300; fail: 29; error: 3

0      1      Test
---    pass   com/sun/java/swing/plaf/gtk/Test6963870.java
fail   pass   java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java
---    pass   java/awt/Frame/FrameSize/TestFrameSize.java
fail   pass   java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
fail   pass   java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java
fail   pass   java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html
---    pass   java/awt/font/TextLayout/TestSinhalaChar.java
pass   error  java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
---    pass   java/math/BigDecimal/MultiplyTests.java
pass   fail   java/net/InetAddress/IPv4Formats.java
pass   fail   java/net/URL/OpenStream.java
pass   fail   java/net/URLClassLoader/ClassLoad.java
pass   fail   java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java
---    pass   java/util/logging/AnonLoggerWeakRefLeak.sh
---    pass   java/util/logging/LoggerWeakRefLeak.sh
---    pass   javax/imageio/plugins/png/ITXtTest.java
---    pass   javax/imageio/plugins/png/ItxtUtf8Test.java
---    pass   javax/swing/JPopupMenu/6675802/bug6675802.java
---    pass   javax/swing/JPopupMenu/6691503/bug6691503.java
---    pass   javax/swing/Security/6938813/bug6938813.java
---    pass   javax/swing/UIDefaults/6622002/bug6622002.java
---    pass   javax/swing/UIDefaults/6795356/SwingLazyValueTest.java
---    pass   javax/swing/UIDefaults/6795356/TableTest.java
---    pass   javax/swing/UIDefaults/6795356/bug6795356.java
fail   pass   javax/swing/plaf/synth/Test6933784.java
fail   pass   sun/nio/cs/Test4200310.sh
---    pass   sun/security/pkcs11/SecureRandom/TestDeserialization.java
---    pass   sun/security/pkcs11/Signature/TestRSAKeyLength.java
---    pass   sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
---    fail   sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java
---    pass   sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java
---    pass   sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java
---    pass   sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java
---    pass   sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java
fail   pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
fail   pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
fail   pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
fail   pass   sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
pass   fail   sun/security/validator/CertReplace.java
---    pass   sun/tools/common/CommonTests.sh

40 differences

In addition to the basic results, the hotspot and jdk regression test suites were rerun with assertions and system assertions enabled, -ea -esa. (The langtools tests are already run with assertions enabled.) The results for hotspot were identical to running without assertions; in jdk a few additional tests failed:


0: b21-jdk/summary.txt   pass: 3,300; fail: 29; error: 3
1: b21-jdka/summary.txt  pass: 3,295; fail: 33; error: 4

0      1      Test
pass   error  com/sun/jdi/DoubleAgentTest.java
pass   fail   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java
pass   fail   java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java
pass   fail   java/awt/Focus/TranserFocusToWindow/TranserFocusToWindow.java
fail   pass   java/awt/xembed/server/RunTestXEmbed.java
pass   fail   java/net/Authenticator/B4769350.java
pass   fail   java/net/CookieHandler/TestHttpCookie.java
fail   pass   java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java
pass   fail   java/util/ResourceBundle/Test4300693.java

9 differences

Going forward, the baseline regression test results for all OpenJDK 6 repositories will be reported with assertions and system assertions enabled.

OpenJDK 6 b21 Source Bundle Published

On January 21, 2011 the source bundle for OpenJDK 6 b21 was published.

Major changes include the latest round of security fixes and, courtesy Andrew John Hughes, syncing in HotSpot 19. In addition, jaxp was upgraded to 1.4.4, Kelly removed the binary plug logic, some stray rebranding issues were corrected, Jon Gibbons backported a set of JavaFileManager fixes from JDK 7, and the usual sorts of small backports of fixes from JDK 7 occurred too.

A detailed list of all the changes in b21 is also available.

Project Coin: JSR 334 Expert Group Update

Besides working to address issues identified in the EDR draft, 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.

Tuesday Jan 11, 2011

Project Coin: JSR 334 EDR now available

The JSR 334 expert group has been hard at work and now the early draft review (EDR) is now available for your reading pleasure, enjoy.

Wednesday Dec 22, 2010

Project Coin at Devoxx 2010

Catching up on blogging, back in November Maurizio and I gave a talk on Project Coin at Devoxx. The video is up on Parleys and I've posted the slides too. These links, along with analogous ones from last year, are available from my new Devoxx talk archive.

JavaPosse episode 330 recorded at Devoxx also covered Project Coin as one of the survey topics (around minute 16 in the podcast). Other than an audience non-reaction for improved integer literals, the other five Coin features received a noticeable amount of applause.

Last year was my first time speaking at Devoxx. This year as before, between sessions a live twitter feed of the conference is projected onto the presentation screens and in the main hallway so there is no waiting for the at times unfiltered feedback from attendees.

Visiting Antwerp again this fall, I has happy to find a few new favorite locations for beer and waffles to enjoy on future visits. Well-aged Trappist beer is a revelation!

Tuesday Dec 21, 2010

New javac warning for setting an older source without bootclasspath

To use javac from JDK N to cross-compiler to an older platform version, the correct practice is to:

  • Use the older -source setting.
  • Set the bootclasspath to compile against the rt.jar (or equivalent) for the older platform.

If the second step is not taken, javac will dutifully use the old language rules combined with new libraries, which can result in class files that do not work on the older platform since references to non-existent methods can get included.

Thanks to work by Jon Gibbons, in JDK 7 build 121 and later javac detects and warns about this suspicious situation; for example:

$ javac -source 6 HelloWorld.java
warning: [options] bootstrap class path not set in conjunction with -source 1.6

One way to address the warning is to set the bootclasspath. If that is inappropriate, the warning can be disabled with a new suboption within the -Xlint family, -Xlint:-options.

With this change, a likely problematic combination of options to javac that can lead to subtle build errors are diagnosed by the compiler and can easily by either directly addressed, or documented as part of the build process via the new -Xlint suboption.

Monday Dec 20, 2010

Project Coin: The Mint is Sprouting

As planned, earlier today Stuart pushed the first set of changes to the JDK libraries to use the new Project Coin features, adding a bit of sparkle with diamonds mounted in java.io, java.lang, java.util, and elsewhere. More diamonds and other shiny coins to follow!

About

darcy

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll