Joseph D. Darcy's Sun Weblog

Thursday August 06, 2009

Build Advice: Set Source, Target, and Encoding

When using javac to compile nontrivial programs, it is almost always prudent to explicitly set the source, target, and encoding options (-source, -target, and -encoding, respectively). Leading by example, the JDK 7 build was recently changed to use explicit source and target settings ahead of upgrading those settings to 7 (6854244, 6827026).

The source option picks which version of the language to accept. Note that to perform a proper cross-compile to an older version of the platform the bootclasspath also needs to be set to an appropriate library. The target option selects which class file version to use for output. The same source construct, for example, a class literal, may be compiled differently and with slightly different semantics under various source and target settings. More directly, the target setting affects which JDK versions the resulting class files will run on. The default source and target change over time; specifying these options explicitly rather than relying on the defaults requests and documents the desired semantics the compiler should use for the input sources and output class files.

The encoding option controls the initial mapping of bytes from the physical file into a raw stream of Unicode characters comprising the source file. (Further translations can occur on the raw stream of Unicode characters before the logical stream of tokens is constructed.) If not set explicitly, the platform's default encoding is used to perform the initial mapping. The default encoding for a platform is stored in the file.encoding system property. Encoding errors can cause contents of a file to be interpreted as gibberish and may lead to a compiler error.

One kind of program where using the default source and target is reasonable is regression tests for the compiler and related tools. Unnecessary source and target options were removed from the JDK 7 langtools repository (6843761) as part of the overall effort to update the default source and target to 7 . Many of the now extraneous options in those regression tests were introduced in JDK 5 before the default source was switched to 1.5 in that release. Switching the default source setting early in a feature release avoids the need to have explicit options in tests of new language features.

Wednesday August 05, 2009

Source, target, class file version decoder ring

Correct usage of javac's -source and -target settings is important to generate class files with the required properties. As Alex has written recently, the compiler's source and target settings interact with various other versioned aspects of the platform. The primary effect of the -source option is to select which version of the Java Programming Language to accept and the primary effect of the -target option is to specify the class file version to output. The first table below summarizes the default source and target settings used by javac in different JDK releases when no explicit -source or -target options are specified. As explained Cross-Compilation Options section of the javc man page, the default target varies depending on the source setting.

In the beginning and through the JDK 1.1 series, javac only had single (implicit) source and single (implicit) target setting. One feature of how inner classes were added in 1.1 was that the class file format did not need to be changed. Therefore, 1.1 and 1.0 share the same target setting. Other subsequent language changes have required later class file versions to be used, sometimes only to force the availability of platform features rather than to intrinsically use new features of the class file format itself. In JDK 1.2, the strictfp modifier was added to the language and to the new class file format selected with target 1.2. The javac in JDK 1.2 always accepts the new keyword, but only generates the new class files supporting the feature if explicitly requested with the -target 1.2 option. Likewise, the JDK 1.3 releases only accept a single implicit source level, unchanged from 1.2, but accept targets ranging from 1.1 to 1.3, with a default of 1.1.

The 1.4 source version added an assert keyword so there was a practical need to be able to compile existing code that happened to use "assert" as an identifier in addition to the new uses of the assert language construct. Therefore, an explicit -source flag was added in JDK 1.4 and retained in subsequent JDK releases. In JDKs 5 and 6, new source and target settings were added. The 1.5 and 1.6 target settings correspond to distinct class file versions; the 1.5 and 1.6 source settings are nearly identical. As an operational difference, javac handles encoding problems differently under those two source levels; an encoding problem generates a warning with source 1.5 but is treated as an error with source 1.6. There is a small semantic difference between the handling of the @Override annotation in the two source levels, but fully elaborating the complications around @Override, source settings, and JDK versions is a story for another day.

The default source and target javac applies in JDK 7 were recently upgraded to source and target 7; previously the same defaults as in JDK 6 were used.

Given the same source code, compilers from different releases configured to use the same source and same target (and same bootclasspath!) can still generate different class files because of bug fixes or changes to compiler-internal contracts. An example of a bug fix, javac -target 1.2 in JDK 1.4.2 elides Miranda methods, extra methods synthesized by the compiler to work around early JVM bugs calling interface methods. Evidence of Miranda methods and other past sins are recorded in javac's sun.tools.java.jvm.Target class. One compiler-internal contract that has evolved over time is the idiom used to access private members of an enclosing class.

While often updated in small ways, the fundamental structure of class files has been very stable across many releases. The first new bytecode, invokedynamic, is being added in JDK 7; although the pair of jsr/ret bytecodes was effectively removed as of target 1.6. The most common way to add capabilities to the class file format has been the addition of new predefined class file attributes; see table 4.6 in the draft of the Java VM Specification, Third Edition for more information. The table below shows the mapping of javac target settings to class file major.minor version numbers.

Monday July 27, 2009

An apt replacement

Showing that no rule is so broad as to not admit an exception, the apt tool and its associated API, com.sun.mirror.*, are being deprecated in JDK 7. The plan is to remove the tool and its API to the next major JDK release after JDK 7.

As a com.sun.* API, the apt API is not governed by the JCP; however, we don't usually mass-deprecate com.sun.* APIs either. We introduced apt in JDK 5 to gain experience with annotation processing before standardizing this facility with JSR 269 in JDK 6, which added the javax.annotation.processing and javax.lang.model.* packages and added annotation processing options to javac.

As the lead engineer for both apt and JSR 269, the JSR 269 API and tool experience should be uniformly better than apt; the newer API is easier to use, more flexible, and should run faster as well. I unconditionally recommend transitioning to the JSR 269 API and javac (or its compiler API) for all your annotation processing needs.

The table below summarizes the apt deprecation information.

Tuesday July 21, 2009

Pick a path, any path

As heard at JavaOne this year, classpath is dead, being killed by the modularity features in JDK 7, JSR 294 and Project Jigsaw.

Today the full logical classpath available to an application or used in javac is actually a twisty little maze of concatenated sub-paths, starting with the bootclasspath, followed by the extension directories, and finally the classpath setting itself. The endorsed standards override mechanism is used to selectively update various components logically included on the bootclasspath as part of the JDK, either components for standards that evolve outside of the JCP, like Corba, or standalone JSRs also shipped with the JDK, like JAX-WS. The extension mechanism can be used to support technologies not shipped with the JDK, such as an independent JSR or even a site-wide library.

The table below shows the different command line options to java and javac that can be used to configure the sub-paths. These options have evolved over time. The bootclasspath and extension directories were added in JDK 1.2, the ability to prepend to the bootclasspath was added in JDK 1.3, endorsed standards were added in JDK 1.4, JDK 5 harmonized the path options on the java and javac command lines, and JDK 6 allowed classpath wildcards, but only for the strict classpath component and not for bootclasspath or the Class-Path Jar manifest attribute. Check the documentation for the JDK release in question for matching configuration information.

There is certainly plenty of opportunity for modularity in JDK 7 to simplify the configuration options needed to resolve dependencies!

Thursday July 16, 2009

Project Coin: Literal Grammar Hackery

Correction: External to this blog, it was been pointed out to me that the original grammar disallowed two-digit numbers, which is unintended. The fix is to make the DigitsAndUnderscores component in Digit DigitsAndUnderscores Digit optional, as done in the corrected grammar below

Circling back to look at some unresolved technical details of the underscores in numbers proposal, I wrote up a combined grammar to allow binary literals as well as underscores as separators between digits. That is, underscores cannot appear as the first or last character in a sequence of digits.

The basic grammar change is to convert the definition of Digits (in any base) from the simple left recursive list of digits found in JLSv3, like

Digits:

Digit

Digits Digit

to a list where underscores can appear between numbers but the list must start and end with a digit:

Digits:

Digit

Digit DigitsAndUnderscores_opt Digit

DigitsAndUnderscores:

DigitOrUnderscore

DigitsAndUnderscores DigitOrUnderscore

This grammar is unambiguous, but as written it requires a look ahead of more than 1 because the recursion is in the middle of the Digits production. I have not attempted any of the usual grammar refactorings to restore a look ahead of 1 since in practice purging the underscores will be implemented by a small amount of additional logic in the scanner as opposed to the actual parsing machinery.

The existing rules for distinguishing decimal and octal literals cause minor grammar complications to accommodate underscores immediately after the first digit. Octal numbers must start with a leading zero digit and nonzero decimal numbers must start with a nonzero digit, requirements reflected in rules like NonZeroDigit Digits_opt. To allow underscores after the first digit, a new rule requiring at least one underscore is added, such as NonZeroDigit Underscores Digits. The structure of binary literals is straightforward and entirely analogous to hexadecimal ones. Changing the digit-level productions automatically allows underscores in floating-point literals without the need to explicitly update the rules for those literals.

Productions in blue below are additional or changed productions to existing non-terminals; the other non-terminals below are newly introduced to support the enhanced literal syntax.

IntegerLiteral:

DecimalIntegerLiteral

HexIntegerLiteral

OctalIntegerLiteral

BinaryIntegerLiteral

BinaryIntegerLiteral:

BinaryNumeral IntegerTypeSuffix_opt

BinaryNumeral:

0 b BinaryDigits

0 B BinaryDigits

DecimalNumeral:

0

NonZeroDigit Digits_opt

NonZeroDigit Underscores Digits

Underscores:

_

Underscores _

Digits:

Digit

Digit DigitsAndUnderscores_opt Digit

DigitsAndUnderscores:

DigitOrUnderscore

DigitsAndUnderscores DigitOrUnderscore

DigitOrUnderscore:

Digit

_

HexDigits:

HexDigit

HexDigit HexDigitsAndUnderscores_opt HexDigit

HexDigitsAndUnderscores:

HexDigitOrUnderscore

HexDigitsAndUnderscores HexDigitOrUnderscore

HexDigitOrUnderscore:

HexDigit

_

OctalNumeral:

0 OctalDigits

0 Underscores OctalDigits

OctalDigits:

OctalDigit

OctalDigit OctalDigitsAndUnderscores_opt OctalDigit

OctalDigitsAndUnderscores:

OctalDigitOrUnderscore

OctalDigitsAndUnderscores OctalDigitOrUnderscore

OctalDigitOrUnderscore:

OctalDigit

_

BinaryDigits:

BinaryDigit

BinaryDigit BinaryDigitsAndUnderscores_opt BinaryDigit

BinaryDigitsAndUnderscores:

BinaryDigitOrUnderscore

BinaryDigitsAndUnderscores BinaryDigitOrUnderscore

BinaryDigitOrUnderscore:

BinaryDigit

_

BinaryDigit: one of

0 1

Tuesday July 14, 2009

Deprecation in the JDK

A quick note on the deprecation policy used in the JDK, a question which comes up from time to time. The general policy for several feature releases is that core JDK components are only marked as deprecated if they are actively harmful. If using a class or method is just ill-advised, that is usually not sufficient to earn the deprecated mark.

The platform javadoc falls short of deprecating, but does discourage the use of certain API elements, from particular methods, like the no-arg Boolean constructor, to entire classes, like Vector and Hashtable. At some point, this kind of advice might be formalized with a less-harmful-than-deprecated "denigration" facility based a combination of javadoc tags and annotations to allow programmatic checks be made for usage of these less harmful API elements too (4941777, 6583872).

When an API element is deprecated, the recommended practice is to both apply the @Deprecated annotation as well as use the "@deprecated" javadoc tag. Using the annotation places more of the semantics of the code in the source code proper as opposed to a comment while using the javadoc tag allows alternate functionality to be recommended along with the specification for the element.

Tuesday June 02, 2009

JavaOne 2009: Project Coin Slides Posted

I presented my technical session about Project Coin, titled more verbosely Small Language Changes in JDK™ Release 7, this afternoon at JavaOne. I've posted the slides. Besides discussing the proposals under further consideration, I also went over some of the experiences from JDK 5 and other considerations we take into account when evolving the language.

Wednesday May 27, 2009

Project Coin: For further consideration, round 2

The first group of proposals selected for further consideration were:

• Strings in switch, Joe Darcy

• Improved Exception Handling for Java, Neal Gafter

• Automatic Resource Management, Josh Bloch

• Improved Type Inference for Generic Instance Creation, Jeremy Manson

• Elvis and Other Null-Safe Operators, Written by Neal Gafter and submitted by Stephen Colebourne

• Simplified Varargs Method Invocation, Bob Lee

After due deliberation, and next set of proposals meeting the Project Coin criteria for further consideration are:

• Logically a combined proposal for better integral literals:

  • Byte and Short Integer Literal Suffixes, Bruce Chapman

  • Binary Literals, Derek Foster

  • Underscores in numbers, Derek Foster

• Language support for JSR 292 (wiki), John Rose

• Indexing access syntax for Lists and Maps, Shams Mahmood Imam

• Collection Literals, Joshua Bloch

• Large arrays (revised), James Lowden

All the selected proposals were reviewed and judged to have favorable effort to reward ratios and to preserve the essential character of the language.

Work should continue refining the selected proposals and producing prototypes. In particular, a unified proposal for integer literals should be produced.

Language change proposals not on the combined "for further consideration" list will not be included in JDK 7; there is no need for continued discussion about them on the Project Coin mailing list. Detailed rationales for why particular proposals were not selected will not be provided.

Final selection of the five or so proposals to be included in the platform will occur within the next few months.

Saturday May 02, 2009

OpenJDK 6: Regression test results for b16, take 2

The corrected source bundle for b16 has slightly different regression test results than the original one. The langtools and hotspot results are the same, but the jdk area has a different difference from b14/b15:

0: b14-jdk/summary.txt   pass: 3,077; fail: 26; error: 3
1: b16a-jdk/summary.txt  pass: 3,085; fail: 29; error: 4

0      1      Test
pass   error  com/sun/jdi/DoubleAgentTest.java
---    pass   java/awt/FontClass/CreateFont/BigFont.java
---    pass   java/awt/FontClass/CreateFont/DeleteFont.sh
---    pass   java/awt/FontClass/CreateFont/fileaccess/FontFile.java
error  pass   java/awt/FullScreen/UninitializedDisplayModeChangeTest/
              UninitializedDisplayModeChangeTest.java
pass   fail   java/awt/print/PrinterJob/ExceptionTest.java
---    pass   java/beans/PropertyEditor/TestEnumSubclass.java
---    pass   java/beans/PropertyEditor/TestEnumSubclassJava.java
---    pass   java/beans/PropertyEditor/TestEnumSubclassNull.java
---    pass   java/beans/PropertyEditor/TestEnumSubclassValue.java
---    pass   java/io/readBytes/MemoryLeak.java
pass   fail   java/rmi/transport/pinLastArguments/PinLastArguments.java
---    pass   java/util/concurrent/Semaphore/RacingReleases.java
---    pass   javax/print/attribute/MediaMappingsTest.java
---    pass   javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java
---    pass   javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java
---    pass   javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java
fail   pass   javax/swing/JColorChooser/Test6541987.java
pass   error  sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
pass   fail   sun/tools/jhat/HatHeapDump1Test.java
pass   fail   sun/tools/native2ascii/NativeErrors.java
pass   ---    tools/pack200/MemoryAllocatorTest.java

22 differences

Comparing the initial and corrected builds of b16:

0: b16-jdk/summary.txt   pass: 3,079; fail: 27; error: 4
1: b16a-jdk/summary.txt  pass: 3,085; fail: 29; error: 4

0      1      Test
pass   fail   java/awt/Focus/FrameMinimizeTest/FrameMinimizeTest.java
---    pass   java/beans/PropertyEditor/TestEnumSubclass.java
---    pass   java/beans/PropertyEditor/TestEnumSubclassJava.java
---    pass   java/beans/PropertyEditor/TestEnumSubclassNull.java
---    pass   java/beans/PropertyEditor/TestEnumSubclassValue.java
pass   fail   java/rmi/transport/pinLastArguments/PinLastArguments.java
---    pass   java/util/concurrent/Semaphore/RacingReleases.java
---    pass   javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java
---    pass   javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java
---    pass   javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java

10 differences

Thursday April 16, 2009

OpenJDK 6: Regression test results for b16

Update: Regression test results for the corrected b16 source bundle are now available.

Running with the usual jtreg flags, -a -ignore:quiet always and -s for the langtools area, the basic regression test results on Linux for OpenJDK 6 build 16 are:

• HotSpot, 3 tests passed.

• Langtools, 1,352 tests passed.

• JDK, 3,077 tests pass, 26 tests fail, 3 tests have errors.

In this build, many of the bugs fixed were for security issues or ports of fixes already in JDK 7. The HotSpot test results were stable:

0: b14-hotspot/summary.txt  pass: 3
1: b16-hotspot/summary.txt  pass: 3

No differences

In langtools all the tests continue to pass and a new test was added:

0: b14-langtools/summary.txt  pass: 1,351
1: b16-langtools/summary.txt  pass: 1,352

0      1      Test
---    pass   tools/javac/processing/6512707/T6512707.java

1 differences

And in jdk, a few new tests were added in b16 and the existing tests have generally consistent results:

0: b14-jdk/summary.txt  pass: 3,077; fail: 26; error: 3
1: b16-jdk/summary.txt  pass: 3,079; fail: 27; error: 4

0      1      Test
pass   error  com/sun/jdi/DoubleAgentTest.java
fail   pass   java/awt/Focus/FrameMinimizeTest/FrameMinimizeTest.java
---    pass   java/awt/FontClass/CreateFont/BigFont.java
---    pass   java/awt/FontClass/CreateFont/DeleteFont.sh
---    pass   java/awt/FontClass/CreateFont/fileaccess/FontFile.java
error  pass   java/awt/FullScreen/UninitializedDisplayModeChangeTest
              UninitializedDisplayModeChangeTest.java
pass   fail   java/awt/print/PrinterJob/ExceptionTest.java
---    pass   java/io/readBytes/MemoryLeak.java
---    pass   javax/print/attribute/MediaMappingsTest.java
fail   pass   javax/swing/JColorChooser/Test6541987.java
pass   error  sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
pass   fail   sun/tools/jhat/HatHeapDump1Test.java
pass   fail   sun/tools/native2ascii/NativeErrors.java
pass   ---    tools/pack200/MemoryAllocatorTest.java

14 differences

Wednesday April 15, 2009

OpenJDK 6: b16 Source Bundle Published

Update: Due to a misunderstanding, some of the expected fixes were missing from the original b16 source bundle. The corrected bundle has subsequently been posted.

On April 15, the source bundle for OpenJDK 6 b16 was published.

The previous source bundle was for b14. There was no distinct b15 per se; b15 was used to mark the transition from teamware to Mercurial. The b16 build is the first to be done purely in Mercurial.

There were 45 bug fixes in this build ranging from security fixes to sound updates; OpenJDK 6 b16 has all relevant security fixes from the recent JDK synchronized security release. A few fixes of note, during a build importing the binary plugs now defaults to false (6781572) and several fixes were applied that should render a few IcedTea patches unnecessary:

Tuesday March 31, 2009

Project Coin: The Call for Proposals Phase is Over!

Update: Added links to proposal for switch for all types and simple expressions and a link to a revised method chaining proposal.

Project Coin's call for proposals phase is now over! Thirty four days long, the proposal period included nearly 70 proposals being sent to the mailing list, 19 coming in over the last two days, and over 1100 messages on the list discussing those proposals and related topics. With the flurry of pre-deadline activity over, the more deliberative task of finishing reviewing and evaluating the proposals awaits. Including several sent in a few hours after deadline, the proposals received since week four are:

• Type inference for variable definition/initialization using the 'auto' keyword, Tim Lebedkov

• Simplified StringBuffer/StringBuilder syntax, Derek Foster

• language support for JSR 292, John Rose

• switch (...) instanceof feature, Jeroen van Maanen

• Simple Operator Overloading, Ruslan Shevchenko

• Conditional Statement, Matt Mastracci

• Enhanced while statement, Marek Kozieł

• Indexing access syntax for Lists and Maps, Shams Mahmood Imam

• Concise Collection Initialization Syntax, Shams Mahmood Imam

• open and close brace optional for single statement try, catch, finally, method declaration, Glenn Marshall

• abstract enums, Derek Foster

• Generic Specification by Method, Ron Thomas

• Allow the class literal of the surrounding class to be referenced with the 'class' keyword, Peter Runge

• Simply implicit method chaining (revised), Ulf Zibis

• Extend switch .. case statement for Object types and simple expressions (revised), Ulf Zibis

• Rethrows Clause, Mark Mahieu

• Collection Literals, Joshua Bloch

• Underscores in numbers, Derek Foster

• Templated Construction Expressions (i.e., Expressions Embedded in Strings), John Rose

• Glue classes based on Extension Methods, Marek Kozieł

• Improved declaration using final keyword of internal method variables and for-loop statement, Andrei Navodnik

• Sameness operators, Derek Foster

• Addition to Comparable interface, Roy van Rijn

• Accepting a subclass as an element type in a for loop, Jean-Louis Ardoint

• @OverrideAll annotation, Gabriel Belingueres

The figure below graphs when proposals were received; nothing like an impending deadline to focus the mind!

Sometime after the next for further consideration cut is made, I'll post some thoughts on and reaction to the call for proposals phase as a whole. This will not include a detailed analysis of why each proposal was or was not chosen; however, there will be discussion of common aspects of proposals that led them to be selected or not.

Friday March 27, 2009

Project Coin: Week 4 Update

Update: Corrected to include Stephen Colebourne's enhanced enhanced for loop proposal.

Further update: Added links to updated large arrays and compile time access proposals.

Project Coin's fourth week saw continued lively traffic on the mailing list. As the submission deadline approaches, a flurry of new proposals were sent in:

• Named method parameters, Paul Martin

• Enhanced for each loop iteration control, Stephen Colebourne

• Loosen Constructor super()/this() call restrictions, Mike Duigou

• Simplified syntax for dealing with parameterized types, J. Lowden

• Compiletime information access (revised), Ruslan Shevchenko

• @Unloadable Class defination, Daniel Cheng

• Large arrays (revised), James Lowden

• Naked dot, Makarenko Alexandre

• Auto-assignment Parameters , Mark Mahieu

• Unchecked Exceptions as Subclasses of Checked Exceptions (revised), Alan Snyder

• Narrow Hexadecimal and Binary Integer Literals, Bruce Chapman

• Byte and Short Integer Literal Suffixes, Bruce Chapman

• Unsigned Integer Widening Operator, Bruce Chapman

• Binary Literals, Derek Foster

• Return 'this', Marek Kozieł

• Improved Support for Optional Object Behaviors at Runtime, Alan Snyder

• 'final' without explicit type, Marek Kozieł

• Language Escape Operator, Bruce Chapman

• Using Ordinary Syntax for Reflective Method Invocations, Alan Snyder

The field of over two dozen proposals previously sent in over the first three weeks of Project Coin was narrowed to six proposals still in consideration for inclusion in JDK 7. The proposals submitted this week and until the end of the call for proposals period will be similarly evaluated for their appropriateness to be added to the language. Finally, the combined list of candidate changes will be produced.

Tuesday March 24, 2009

A trail of coins

For those interested in specifically following Project Coin related posts, my Project Coin entries are tagged with "projectcoin":
http://blogs.sun.com/main/tags/projectcoin

Project Coin: For further consideration...

In the first three weeks of Project Coin over two dozen proposals have been sent to the mailing list for evaluation. The proposals have ranged the gamut from new kinds of expressions, to new statements forms, to improved generics support. Thanks to all Java community members who have sent in interesting, thoughtful proposals and contributed to informative discussions on the list!

While there is a bit less than a week left in the call for proposals period, there has been enough discussion on the list to winnow the slate of proposals sent in so far to those that merit further consideration for possible inclusion in the platform.

First, Bruce Chapman's proposal to extend the scope of imports to include package annotations will be implemented under JLS maintenance so further action is unnecessary on this matter as part of Project Coin. Second, since the JSR 294 expert group is discussing adding a module level of accessibility to the language, the decision of whether or not to include Adrian Kuhn's proposal of letting "package" explicitly name the default accessibility level will be deferred to that body. Working with Alex, I reviewed the remaining proposals. Sun believes that the following proposals are small enough, have favorable estimated reward to effort ratios, and advance the stated criteria of making things programmers do everyday easier or supporting platform changes in JDK 7:

• Strings in switch, Joe Darcy

• Improved Exception Handling for Java, Neal Gafter

• Automatic Resource Management, Josh Bloch

• Improved Type Inference for Generic Instance Creation, Jeremy Manson

• Elvis and Other Null-Safe Operators, Written by Neal Gafter and submitted by Stephen Colebourne

• Simplified Varargs Method Invocation, Bob Lee

As this is just an initial cut and the proposals are not yet in a form suitable for direct inclusion in the JLS, work should continue to refine these proposed specifications and preferably also to produce prototype implementations to allow a more thorough evaluation of the utility and scope of the changes. The email list should focus on improving the selected proposals and on getting any remaining new proposals submitted; continued discussion of the other proposals is discouraged.

The final list of small language changes will be determined after the call for proposals is over so proposals sent in this week are certainly still in the running! The final list will only have around five items so it is possible not all the changes above will be on the eventual final list.

Friday March 20, 2009

Project Coin: Week 3 Update

Project Coin's third week was another week of lively traffic on the mailing list. New proposals were sent in:

• Extended arrays declaration and access syntax with use of enumerated types, Alexey Kuznetsov

• Embedded Expressions for String Statements, Stefan Schulz

• Access to Generic Type Parameters at Compile-Time, David Walend

• Small property support, Ruslan Lazukov

existing proposals were revised:

• Static Methods in Interfaces (v1.1) , Reinier Zwitserloot and Roel Spilker

• Enhanced String literal for Java: version 1.3 with implementation, Alexey Kuznetsov

and discussion continued on ARM and other proposals. The scoping and utility of a few pre-proposals was discussed on the list too.

Ten days remain to get language change proposals in! (Purely libraries changes will be handled by other JDK 7 processes.)

Friday March 13, 2009

Project Coin: Week 2 Update

After the vigorous start of week 1, the pace of new proposals being sent to the list slowed:

• (pre-proposal) Source and Encoding keyword, Reinier Zwitserloot and Roel Spilker

• Extend Scope of Imports to Include Package Annotations, Bruce Chapman

• Enhanced String constructs for Java, Felix Frost

• Allow the use of relational operators on Comparable classes (withdrawn), Vilya Harvey

• Method and Field Literals , Jesse Wilson

However, brisk discussion continued on refining and exploring ARM blocks and their variations.

Thursday March 12, 2009

Language Model Changes as of JDK 7 Build 50

To date, there have been a few API changes to javax.lang.model.* in JDK 7. Early in the release, SourceVersion.RELEASE_7 was added to correspond to any new source-level changes coming in JDK 7 (6458819). Eventually, there will be changes to support the modulue construct being added by JSR 294; changes may or may not be needed for language changes coming from Project Coin and JSR 308. Once modulues are added, the JSR 269 API elements meant to cope with the expression problem will be tested. In the mean time, some minor API cleanups have occurred, one to make handling exceptions easier (6794071), another to group common functionality in mixin interfaces (6460529), and some minor API clarifications (6501749). Along the way, there has been a little general bug fixing too (6478017, 6583626, 6498938).

Small tweaks and bug fixing will continue to occur in the javax.lang.model.* and javax.annotation.processing packages throughout JDK 7 in addition to changes needed to support new language features.

Design tips: Exception types

Expanding on a few slides from my JavaOne talk last year, here are a few tips to keep in mind when designing exception types.

First, all exceptions are serializable since Throwable implements Serializable; therefore, like all other serializable classes, exception types should declare a serialVersionUID field to ease evolving the type in the future. Using's javac's -Xlint:serial option will warn about missing serialVersionUID fields on serializable classes, amongst other possible issues.

Second, when adding a new exception class, consider providing more information beyond just a distinct name, such as methods to return information about what specific situation triggered the exception and possibly how to recover from it. Providing this additional information can interact with being serializable; when the additional information is not logically serializable, the specification may need to allow the information to be unavailable after deserialization.

Third, when multiple related exceptions types are added, a common direct superclass allows a single catch block to handle the related exceptions uniformly. (Having a common super-exception would still be useful even if multi-catch is added to the language in JDK 7.)

Looking at the exceptions in the JSR 269 API, various methods note the possible impact of serialization-deserialization on the returned values. JSR 269 provided a trio of similar exceptions for the situation of encountering a kind of object unknown in an earlier version of the language, such as a JDK 6 era annotation processor coming across a module from JDK 7:

• javax.lang.model.element.UnknownAnnotationValueException

• javax.lang.model.element.UnknownElementException

• javax.lang.model.type.UnknownTypeException

However, the original JSR 269 API does not have a common direct superclass to group these related conditions. That deficiency was addressed in JDK 7 build 48 with the addition of javax.lang.model.UnknownEntityException as the direct superclass of these three exceptions (6794071). Retrofitting this change is binary compatible because UnknownEntityException directly extends RuntimeException as did the old exceptions and serialization compatibility is preserved by the existing serialVersionUID fields in the old exceptions.