Friday Jun 15, 2012

My integer overfloweth

While certain classes like java.lang.Integer and java.lang.Math have been in the platform since the beginning, that doesn't mean there aren't more enhancements to be made in such places! For example, earlier in JDK 8, library support was added for unsigned integer arithmetic. More recently, my colleague Roger Riggs pushed a changeset to support integer overflow, that is, to provide methods which throw an ArithmeticException on overflow instead of returning a wrapped result. Besides being helpful for various programming tasks in Java, methods like the those for integer overflow can be used to implement runtimes supporting other languages, as has been requested at a past JVM language summit.

This year's language summit is coming up in July and I hope to get some additional suggestions there for helpful library additions as part of the general discussions of the JVM and Java libraries as a platform.

Sunday Mar 11, 2012

Repeating annotations in the works

Work has commenced on the repeating annotations feature discussed in JEP 120: Repeating Annotations.

First, the meta-annotation type used to declare the containing annotation has been added to java.lang.annotation. Updates to the AnnotatedElement interface will be made later. Next, with feedback from other members of the compiler team, I've written a draft specification of the needed language changes:

Updates to JLS 9.6 Annotation Types:

If annotation type T is annotated with an annotation a of type ContainerAnnotation then:

  • The value of the @ContainerAnnotation annotation is called the containing annotation type TC.
  • TC must declare a value() method whose return type is T[], or a compile-time error occurs. (This implies that TC can be the containing annotation type for only a single annotation type.) [Note: Since an annotation type T cannot declare a method that returns T or T[] as a value, that implies that it is a compile time error for an annotation type to specify itself as a container annotation type.]
  • TC may declare methods other than value(). Any such methods must have a default clause, or a compile-time errors occurs. [Note: this is a bit weird "action at a distance" in terms of compiler errors. The error message here is given at the site of the T since the containing annotation might only be present as a class file.]
  • It is a compile time error if the retention of T is not a subset of the retention of TC. This comparison is made taking default retention into consideration.

    In more detail, if the retention of the TC is SOURCE, the retention of T must be SOURCE. If the retention of TC is CLASS, the retention of T may be either CLASS or SOURCE. if the retention of the TC is RUNTIME, the retention of T may be SOURCE, CLASS, or RUNTIME.

  • It is a compile time error if T is @Documented and TC is not @Documented.

    [Note that it is permissible TC to be @Documented and for T to not be @Documented.]

  • It is a compile time error if T is @Inherited and TC is not @Inherited.

    [Note that it is permissible TC to be @Inherited and for T to not be @Inherited.]

  • It is a compile time error if T has target values that are not included in the target set of TC, taking default target values into account.

Note that an annotation type TC may be a container type for annotation type T while also having its own container type TCC.

[However, two annotation types cannot be containers for each other because that would create an illegal cyclic annotation type situation. For example, the following program is rejected by javac:

public @interface Mutual {
    Omaha[] value() default {};

@interface Omaha {
    Mutual[] value() default {};

@Mutual({@Omaha, @Omaha})
@Omaha({@Mutual, @Mutual})
class Foo {}

with the message error: cyclic annotation element type
    Omaha[] value() default {};
1 error]

Updates to JLS 9.7 Annotations:

"It is a compile-time error if a declaration is annotated with more than one annotation for a given annotation type."

Change to "unless the annotation type is annotated with an @ContainerAnnotation."

Annotation types with an @ContainerAnnotation are known as repeatable annotation types. The presence of an @ContainerAnnotation indicates multiple annotations of that annotation type will be logically replaced with a single annotation synthesized by the compiler. The type of the synthesized annotation, TC, is the type given by the value of the ContainerAnnotation annotation on T. The order of the elements of the value() method of the synthesized TC annotation matches the left to right order of the base repeatable annotations.

If an element only has a single repeatable annotation, the annotation is not replaced.

It is conventional to place the repeatable annotations of a given type contiguously on an element, but this is not required.

It is a compile time error if an element is annotated with both multiple base annotations of a repeatable annotation type T and with one or more annotations of the containing type TC.
[In other words, the collapsing of repeatable annotations to their containers is not recursive.]

Wednesday Aug 31, 2011

JDK 7 Changesets Over Time

Calling out some statistics I put together for OSCON, I think it is interesting to examine the cumulative number of monthly changesets in the JDK 7 forest from the time of the transition to Mercurial to JDK 7 GA:

This graph covers roughly three and a half years of the project's history, with the purple lines being time under Sun and the red lines being time under Oracle. The blue line is a scaling of the number of changesets per month, roughly the first derivative of the total. The solid purple and red lines show the trend in the rate of change in the last year of Sun's stewardship of the JDK and the first year of Oracle's stewardship. Under Sun, the rate of change was decreasing. After a lull for some "Welcome to Oracle" events, activity on JDK picked up and was on average 15% higher in the first year under Oracle than the last year under Sun (≈244 changesets/month under Oracle vs ≈211 changesets/month under Sun). The first year under Oracle included JDK 7 being feature complete in early 2011; however, JDK 7 wasn't done at that point! Several JSRs were still in flight and subsequently there was a large push in March and April this year to wrap up activity in JDK 7 ahead of the rampdown stabilization period immediately before GA.

Thursday Aug 18, 2011

JDK 7: Small Library Treats

With JDK 7 out the door, many writeups of the release have naturally focused on its larger features like Project Coin, NIO.2, the fork/join framework, and invokedynamic. However, there are a number of small but useful library conveniences in JDK 7 that shouldn't be overlooked. Library changes I think are handy include:

  • To allow more informative assertion errors to be constructed, AssertionError now includes a constructor taking a string message and a Throwable cause, which is one of the four conventional constructors for exception types.

  • The methods which convert strings to numeric values differed in whether or not a leading plus, "+", was regarded as valid input. Float, Double, and BigDecimal accepted a leading plus while Byte, Short, Integer, Long, and BigInteger did not. As of JDK 7, all those types consistently accept a leading plus in their parseFoo, valueOf, and decode methods.

  • To help write more efficient comparators, Boolean, Byte, Character, Short, Integer, and Long each have a two-argument static compare method that performs the desired comparison operation without boxing overhead.

  • This six checked exception types that can be thrown by core reflection now have a common supertype, ReflectiveOperationException. This additional type complements the improved exception handling available with multi-catch and more precise re-throw from Project Coin.

  • The java.util.Objects class contains a number of small, but commonly used methods, many of them for coping with null inputs. For example, Objects contains a two-argument static equals method which does the right thing on null inputs. I've replaced a half-dozen copies of that method's logic in the JDK; I'm sure many more instances can be removed in other code bases as JDK 7 is adopted.

  • Part of NIO.2, I expect over time the utility methods in java.nio.file.Files to copy, read, and write the contents of file will see heavy usage.

Monday Jul 18, 2011

Project Coin: JSR 334 Finale!

Slightly more than eight months after its JSR review ballot was first filed, JSR 334 has just successfully passed its final approval ballot. Along with the other portions of the Java SE 7 umbrella JSR, the language changes done under JSR 334 are now officially part of the Java SE platform, the first Java programming language changes since JDK 5 shipped way back in 2004.

Thanks go to the members of the JSR 334 expert group for their service, to the langtools team at Sun and Oracle for their integral participation in Project Coin and JSR 334, and to the interesting proposals and thoughtful comments on the coin-dev alias.

I'm happy with how the suite of six features turned out and I'm especially pleased with the degree of IDE support available even before JDK 7 has officially shipped.

I'm looking forward to Java programmers being able to use the new language features and to the additional changes that may come with "coin, the flip side" in JDK 8.

Thursday Jul 07, 2011

Project Coin at the Java 7 Launch

Update: Video now available from the Project Coin link on this page.

Somewhat before the scheduled GA at the end of the month, today at Oracle headquarters and elsewhere we celebrated the launch of JDK 7. The webcasts of my half-hour breakout session on Project Coin and three other technical breakouts will be available for replay later. In the meantime, I've posted the slides.

One comment I made during the session made an impression on twitter: after a glitch going back from the NetBeans demo to PowerPoint slides I noted "its always impressive how computers know when you are running a demo." This chronic technological reaction to demos may even last longer than Moore's law!

Tuesday Jul 05, 2011

Project Coin: JSR 334 reaches Final Approval Ballot

With the proposed final draft available, JSR 334 has progressed to the next stage: final approval ballot. The members of the executive committee have two weeks to evaluate the specification, testing status, and reference implementation before rendering their votes. Assuming a positive vote, the mainline of JSR 334 will then be complete!

Tuesday Jun 28, 2011

See you at OSCON!

In just under a month, I'll be speaking at the OSCON Java conference about various OpenJDK and JDK 7 matters:

More detailed talks on those topics include Stuart's session on Coin in Action: Using New Java SE 7 Language Features in Real Code and Dalibor's OpenJDK – When And How To Contribute To The Java SE Reference Implementation.

See you in Portland!

OSCON 2011

Friday Jun 24, 2011

Project Coin: JSR 334 has a Proposed Final Draft

Reaching nearly the last phase of the JCP process, JSR 334 now has a proposed final draft. There have been only a few refinements to the specification since public review:

  • Incorporated language changes into JLS proper.

  • Forbid combining diamond and explicit type arguments to a generic constructor.

  • Removed unusual protocol around Throwable.addSuppressed(null) and added a new constructor to Throwable to allow suppression to be disabled. Added disclaimers that OutOfMemoryError, NullPointerException, and ArithmeticException objects created by the JVM may have suppression disabled.

  • Added thread safely requirements to Throwable.addSuppressed and Throwable.getSuppressed.

Next up is the final approval ballot; almost there!

Tuesday May 24, 2011

Project Coin: Documenation at Rampdown

As a follow-up to the Project Coin documentation posted for the JDK 7 developer preview and with work on JDK 7 officially ramping down, I've posted documentation on the semantics of the Project Coin features as implemented in JDK 7 b143 at:

If you have comments or questions about a feature, after reviewing the relevant discussion sections, feedback can be sent to the coin-dev mailing list.

Friday May 06, 2011

Project Coin: Diamond and Generic Constructors

To address an issue in the specification, the JSR 334 expert group has decided to ban the combination of diamond together with explicit constructor type arguments. For background, a constructor can have two sets of type arguments. In a parameterized class, constructors can have type arguments corresponding to the class's type parameters. This is the common case and the type arguments appear to the right of the class name and "new" as in "new ArrayList<String>()". In addition, if a constructor declares its very own type parameters (which can be done whether or not the enclosing class is parameterized), then those type arguments appear between the "new" token and the class name as in "new <Integer> ConstructorWithTypeParameter(Integer.valueOf(42))".

As with generic methods, the type arguments of generic constructors are usually inferred and not explicitly passed. However, generic constructors are much less common than generic methods.

After the specification change, using diamond to infer the class type parameters but explicitly passing the constructor type parameters is forbidden. However, the other three combinations of explicitly passing type arguments versus inferring them are supported, as shown in the table below.

class Foo<T extends Number> {
      <S extends T> Foo(S s) {super();}
Class Constructor Supported Example
Explicit Explicit Yes new <Integer> Foo<Number>(null);
Explicit Inferred Yes new Foo<Integer>(null);
Inferred Explicit No new <Integer> Foo<>(null); // compile error
Inferred Inferred Yes new Foo<>(null);

The substitution that was used to formally describe the semantics of diamond did not fully propagate constraints if there was a typing relationship between the type parameters of the constructor and the type parameters of the class. Lifting the imposed restriction on the banned combination of explicit and inferred type arguments can be revisited in future work in the context of broader type inference getting added to the Java language.

Since generic constructors are so uncommon, adding this restriction about combining them with diamond should have little effect to most programs. For example, none of the uses of diamond in the JDK had to be updated as a result of this change. A changeset implementing this specification change has been pushed and will appear in subsequent promoted builds of JDK 7.

Monday Apr 25, 2011

Project Coin: JSR 334 Public Review Approved

After due consideration by the JCP SE/EE Executive Committee, the public review of JSR 334 has been approved.

Onward to the proposed final draft!

Thursday Apr 21, 2011

Project Coin: IDE support

All three of the NetBeans, IntelliJ, and Eclipse IDEs have some level of support in progress for Project Coin's language features.

The recently released NetBeans 7.0 has support for all the Coin features. As explained in its release notes, beyond just recognizing the features in the editor NetBeans 7.0 provides auto-completion to diamond and gives hints to apply the new features to existing code.

As previously announced for IntelliJ IDEA, the builds of IDEA 10.5 EAP (early access program) provide similar quickfix support.

Finally, an Eclipse branch is hosting their efforts to support Project Coin.

As JSR 334 is not quite done yet, I'd expect the IDEs to be updated after JSR 334 is completed to account for any specification changes made in the interim.

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.

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.

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:

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: 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/
fail   pass   java/awt/Focus/ActualFocusedWindowTest/
fail   pass   java/awt/Focus/ActualFocusedWindowTest/
fail   pass   java/awt/Focus/TranserFocusToWindow/
---    pass   tools/launcher/

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 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 {
    } catch(Throwable #suppressedException) {
  } else {


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

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




« April 2014

No bookmarks in folder