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

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.




« July 2016

No bookmarks in folder