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.

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

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!

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!

Tuesday Dec 14, 2010

Project Coin: Minty Fresh Libraries

The JDK 7 build has been using -source 7 for some time, but to date use of new language features has been informal and incidental. Supporting Project Coin and JSR 334, Stuart Marks will be leading a "minting" exercise over the JDK code base to systematically update the JDK libraries to take advantage of the Project Coin language features. Efforts will be focused on the src and test portions of the jdk repository of the JDK 7 forest. The first features to be rolled into the code will be diamond and strings in switch.

Review requests for different areas will be sent to the appropriate OpenJDK aliases for review. The proposed changes will consist solely of conversions of existing code to use a new language feature. While use of the new features is encouraged, in areas of the platform where code is kept synchronized with earlier release trains, such code cannot be updated to use the Project Coin features at this time.

For several years, we've been collaborating with the NetBeans team to provide IDE support for the Project Coin features. NetBeans 7 Beta is the latest release to support Project Coin, as detailed in its release notes. We will continue to coordinate with the NetBeans team to update the Project Coin support in NetBeans as refinements are made to the Project Coin features. Additionally, to allow use of NetBeans for JDK development, we will defer updating the JDK to use a Coin feature until there is matching support in a NetBeans build, as there is now for diamond and strings in switch. (The NetBeans 7 Beta supports a slightly older version of multi-catch and try-with-resources.)

Monday Dec 13, 2010

Project Coin: Safe Varargs

Following up on earlier work, the javac team has pushed a new implementation of Project Coin's simplified varargs method invocation feature (jdk, langtools). The changes are scheduled to appear in the promotion of JDK 7 b123.

As envisioned previously, a new @Documented annotation type, java.lang.SafeVararags, can be used to suppress warnings related to unchecked warnings, both the new mandatory warnings at the declaration site of a varargs method/constructor with a non-reifiable element type and the existing unchecked warnings at the call sites of such methods. A systematic application of this annotation to appropriate declarations in the JDK libraries will follow as future work.

Since new unchecked warnings are being introduced, those diligently compiling with options like "-Xlint:unchecked -Werror" will see a build error under JDK 7 if any of the suspicious varargs method declarations are found. To address this, the @SafeVarargs annotation can be applied to the declarations, if appropriate, or the @SuppressWarnings({"unchecked", "varargs"}) annotation can be applied. Unlike @SafeVarargs, the @SuppressWarnings annotation will not squelch unchecked warnings at the call site of the annotated method.

The specification of the new SafeVarargs annotation type is below.


Annotation Type SafeVarargs



@Documented
@Retention(value=RUNTIME)
@Target(value={CONSTRUCTOR,METHOD})
public @interface SafeVarargs
A programmer assertion that the body of the annotated method or constructor does not perform potentially unsafe operations on its varargs parameter. Applying this annotation to a method or constructor suppresses unchecked warnings about a non-reifiable variable-arity (vararg) type and suppresses unchecked warnings about parameterized array creation at call sites.

In addition to the usage restrictions imposed by its @Target meta-annotation, compilers are required to implement additional usage restrictions on this annotation type; it is a compile-time error if a method or constructor declaration is annotated with a @SafeVarargs annotation, and either:

  • the declaration is a fixed-arity method or constructor
  • the declaration is a variable-arity method that is neither static nor final.

Compilers are encouraged to issue warnings when this annotation type is applied to a method or constructor declaration where:

  • The variable-arity parameter has a reifiable element type, which includes primitive types, Object, and String. (The unchecked warnings this annotation type suppresses already do not occur for a reifiable element type.)
  • The body of the method or constructor declaration performs potentially unsafe operations, such as an assignment to an element of the variable-arity parameter's array that generates an unchecked warning.

    Future versions of the platform may mandate compiler errors for such unsafe operations.

Monday Dec 06, 2010

Project Coin: JSR 334 Approved

After due consideration by the JCP SE/EE Executive Committee, JSR 334, Small Enhancements to the Java™ Programming Language has been approved! The work of the expert group now officially gets underway. One of our first tasks will be working on producing a specification of the language changes for early draft review, the next milestone in the JSR process.

Tuesday Nov 16, 2010

Project Coin: JSR Filed!

Keeping with the plan of Plan B for JDK 7 and 8, a Java Specification Request (JSR) proposal has been submitted to the JCP covering the language features explored by Project Coin. The proposal for Small Language Changes to Enhance Productivity is now being considered by the relevant JCP Executive Committee under an approval ballot which runs for two weeks. This proposal is one of four proposals submitted to the JCP to cover the full Plan B roadmap.

I'm looking forward to working with veterans of Project Coin and other expert group members to finish specifying, implementing, and testing the language changes to complete getting them into the platform.

Thursday Oct 28, 2010

Project Coin Improving Multi-catch and More Precise Rethrow

We've been working on some improvements to the multi-catch and more precise rethrow feature and are planning to push the changes soon. First, as long as a catch parameter is effectively final (in other words not reassigned inside the catch block), the more precise analysis will be enabled if the exception is rethrown. An explicit final modifier will no longer be needed to enable the more precise analysis.

As pointed out in the original proposal form for Improved Exception Handling for Java, the more precise exception analysis can cause programs that currently compile to stop compiling since more unreachable code is identified. While the general evolution policy of the JDK does not promise source compatibility across releases, gratuitously breaking compatibility should be avoided. Fortunately, after examining millions of lines of code in a diverse set of code bases, include the JDK, no instances where the more precise analysis would cause an actual source incompatibility were found. (Details of the analysis will be written up later.)

Second, the catch parameter of a multi-catch clause (catch(Exception1 | Exception2 e) {...}) will be regarded as implicitly final; the compiler will reject code that writes to such a catch parameter. Consequently, an explicit final modifier will no longer be needed in this case, although it will remain legal. This provides a more concise syntax for multi-catch in JDK 7 while preserving flexibility to more fully support disjunctive types in later JDK releases.

Monday Sep 20, 2010

Project Coin at JavaOne 2010

This morning and early afternoon Maurizio and I gave our JavaOne talk about Project Coin to a packed room; the slides for the talk are now available. The NetBeans demo of Coin support also went smoothly.

As announced earlier at JavaOne, we'll be following the "plan B" option for JDK 7 so the accepted Coin features that are not currently implemented will be reconsidered for JDK 8. In the meantime, we're interested to have more feedback on the Project Coin features

  • Improved numeric literals

  • Strings in switch

  • Reduced varargs warnings

  • Diamond operator

  • Multi-catch with more precise rethrow

  • try-with-resources statement

that are available to test out now in JDK 7 builds.

Friday Sep 10, 2010

Project Coin: JDBC 4.1 and try-with-resources

I'm happy to report that Lance Andersen and the JDBC expert group have decided to support the new try-with-resources statement in JDBC 4.1. Lance just pushed a change set for JDBC 4.1 that retrofits the AutoCloseable interface to the types:

  • java.sql.Connection

  • java.sql.ResultSet

  • java.sql.Statement

The change will be available in JDK 7 promoted builds in due course.

Wednesday Sep 08, 2010

Project Coin possibilities under JDK 7 plan A and plan B

Mark Reinhold has announced in various venues that Oracle is rethinking the plan for JDK 7.

In summary, the two plans under consideration with their ship dates are:

   Plan A:  JDK 7 (as currently defined)                      Mid 2012

   Plan B:  JDK 7 (minus Lambda, Jigsaw, and part of Coin)    Mid 2011
            JDK 8 (Lambda, Jigsaw, the rest of Coin, ++)     Late 2012

Oracle is leaning heavily toward plan B, but is also soliciting feedback on the plans, as indicated in Mark's announcement.

For Project Coin, the maximum likelihood outcome under plan B is that the currently implemented Coin features:

will be included in JDK 7, subject to future refinements and revisions (and even possible removals) as experience is gained with the features. The remaining accepted Coin features would then be reconsidered in the context of other language changes being planned for JDK 8.

Friday Aug 20, 2010

Project Coin: Try out try-with-resources

As of build 105 of JDK 7, the compiler and libraries have support for Project Coin's try-with-resources statement (ARM blocks).

We're curious to get feedback on how try-with-resources works in practice, so please download the build, use the feature to on your favorite Closeable type, and report back on how it goes.

Thursday Aug 05, 2010

Project Coin: Uniform Suppression in try-with-resources

As previously considered, the specification of the try-with-resources statement has been updated to require uniform suppression of all throwables. That is, the semantics of the code around the implicitly generated calls to close was previously

    try {
      #resource.close();
    } catch(Exception #suppressedException) {
      #primaryException.addSuppressedException(#suppressedException);
    }

and has been replaced with

    try {
      #resource.close();
    } catch(Throwable #suppressedException) {
      #primaryException.addSuppressedException(#suppressedException);
    }

(The initial implementation actually implemented the latter semantics; a test has been added to verify the behavior.)

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