Tuesday Jan 10, 2012

Project Coin Fixes in 7u2

Last month, JDK 7u2 was released. The release has a few correctness fixes for the Project Coin features, two diamond fixes courtesy Maurizio and one fix to strings in switch:

  • Diamond inference with nested classes had an improper interaction. For example, in code like

    class X {
      class Y {
        Y(T a, Z b) {...}
      public static void main(String... args) {
        X<String>.Y<String> x1 = new X<String>().new Y<String>("",""); //ok
        X<String>.Y<String> x2 = new X<String>().new Y<>("",""); // Failed!
    diamond was not allowed at the second constructor call, but such code is accepted as of 7u2. (7046778)

  • The compiler erroneously allowed constructs like

    Foo<String>[] fooArr = new Foo<>[]{...};
    Such code is now properly rejected. (7057297)

  • If extra parenthesis were used around the case label of a string switch statement, as in

    switch (s) {
      case ("a"):
    javac would throw a NullPointerException when compiling the code. (7071246) Previously, the workaround was to remove the unneeded "(" and ")", but javac has been corrected to accept this valid syntax. (We received multiple reports of this bug, so parenthesis around case labels is much more common style than I would have expected!)

If you're using the Project Coin language features, I recommend upgrading to 7u2 to get these fixes and to minimize source compatibility concerns going forward.

Friday Dec 02, 2011

An apt ending draws nigh

I brought you into this world, and I'll take you out!
—Cliff Huxtable

The end of an era draws nigh! After being deprecated in JDK 7, the apt command line tool and the entirely of its associated API is on track to be removed from JDK 8 within the next few months. While apt was fine back in JDK 5, the time has come to transition annotation processing to the superior standardized annotation processing provided by javax.annotation.processing and javax.lang.model.*. These packages were added to Java SE 6 under JSR 269.

This removal effort was discussed in JEP 117: Remove the Annotation-Processing Tool (apt).

Portions of jax-ws in the JDK use apt, but those portions are being rewritten to use the JSR 269 APIs. Once that revised version of jax-ws is being used by the JDK builds, apt will be excised in short order.

As a com.sun.* API, apt is not part of Java SE; it is just a component of the JDK and is thus easier to remove from the platform. While I was the lead in creating apt, lo these many years ago, I'm looking forward to deleting the code from the JDK to encourage use of a better replacement API and to ease maintenance of javac.

Wednesday Nov 16, 2011

Project Coin at Devoxx 2011

Returning to Antwerp, earlier today Maurizio and I presented a talk on Project Coin at Devoxx and the slides are now available.

The talk was streamed live on Parleys and will be available for download and viewing on the Devoxx 2011 channel in due course.

Now that my major Devoxx speaking obligations are over, more attention can be paid to Belgium waffles and beer!

Tuesday Oct 04, 2011

Project Coin at JavaOne 2011

Update: A video of this talk is now available on Parley's.

Earlier today, I presented my JavaOne session on The Heads and Tails of Project Coin (slides). The talk included some retrospectives from developing the Coin features which I hope to write up in more detail in the near future.

Turning toward the future, the talk also spent a little time discussing possible language changes coming in JDK 8. First, planning for JDK 8 is on-going and the feature list is subject to change; the JEP process will be used to help define the roadmap going forward. With those caveats, small language changes we're considering proposing for JDK 8 include:

  • Refinements to JDK 7 Coin features
    • try-with-resources on an effective final variable
    • removing restrictions on usage of diamond
    • @SafeVarargs on private methods
  • Collection literals(?)
  • Repeating Annotations(?)
  • Method and constructor parameter names at runtime(?)

Personally, I would welcome programming with collection literals. Repeating annotations and the ability to retrieve the names of method/constructors at runtime are both long-standing requests from our colleagues in EE.

However, with the broad scope of language and platform changes coming into JDK 8 courtesy Lambda and Jigsaw, all these smaller language changes have to be made somewhat opportunistically. For that reason, for JDK 8 we are not planning on having another open call for proposals as was done for Project Coin in JDK 7.

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.

Tuesday Aug 30, 2011

Coming soon: JavaOne 2011

While enjoying some post-JDK 7 GA rest and relaxation, a hotel I stayed at offered this different image of JavaOne, one cup at a time:

JavaOne coffee maker

In the meantime, the usual JavaOne 2011 conference is fast approaching!

JavaOne 2011 Flair

My talk on The Heads and Tails Project Coin is just over a month away on Tuesday, October 4. Later that day, I'll be available for questions at the Meet the Java Language Team bof. If you already have a question you want answered about Project Coin at or before JavaOne, please leave it as a comment on this blog.

For more on Project Coin, based in part on his "coinificaiton work, Stuart will be giving a talk on Using New Java SE 7 Language Features in Real Code.

See you in San Francisco.

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.

Tuesday Aug 16, 2011

A Pictorial View of a JSR Progressing through the JCP

While JSR 348 is working on making changes to the JCP process JSRs pass through, for those working on or following JSRs understanding the state transitions of the current process, JCP 2.7, is helpful. As shown below, after an approval ballot to initiate the JSR, the expert group convenes and produces a series of draft specifications, currently an early draft, followed by a public review draft, a proposed final draft, and the final specification. If needed, an expert group can actually produce multiple early drafts or proposed final drafts.

States in italics involve votes from the executive committee (EC). Given a successful vote, the JSR advances; otherwise, there can be a reconsideration ballot to address issues raised by the EC, after which a JSR can get back on track of close down.

As reported on this blog, JSR 334 duly went through all the mainline phases from initiation to completion (approval ballot, early draft review, public review, proposed final draft, final approval ballot, final release).

Not shown is the separate, and simpler, set of state transitions for maintenance reviews, as done for JSR 269, Pluggable Annotation Processing API, this spring.

Monday Jul 25, 2011

OSCON: The State of JDK OpenJDK

After a short keynote on JDK 7, later in the day on Monday I presented a talk about The State of JDK and OpenJDK; the slides for the talk are now available.

OSCON: JDK 7 in a Nutshell

Update: The slides.

If all goes according to plan, at 10 am PST on Monday, July 25 I'll be giving a keynote talk about JDK 7 in a Nutshell at OSCON Java in Portland and the talk is slated to be streamed live. After the keynote, I'll post the slides.

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 13, 2011

Knuth: "Be an edge, not a node."

At a recent talk, engineering hero and consummate computer scientist Donald Knuth gave the following graph-theoretic advice for future professors: be edges, not nodes. That is, plan to have two sub-specialties in different fields and be able to act as a bridge between disciplines. Perhaps the source of this advice is related to the proof of his Knuth is fondest of: as edges are randomly to a set of nodes, after initially forming a quite disconnected graph, at a certain point there are two quick phase transitions and afterward a large fraction of the nodes then share membership in a single connected component.

I think Knuth's advice is sound for non-academics too (and a step beyond just being T-shaped). Some of the blog entries I've most enjoyed writing are those that bring together tools from different areas of computer science, such as numerical linear algebra and programming languages.

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.

Thursday Apr 28, 2011

See you on the flip side

As has been noted by many other bloggers on blogs.sun.com, the blogs on that site are soon going to be migrated to blogs.oracle.com. As of next week, the previous content of blogs.sun.com/darcy should redirect to and be hosted under blogs.oracle.com/darcy. I will not be making any blog posts here until the migration is complete and I've made a separate backup of this blog's contents in case there is a problem with the move.

See you on the flip side.

Monday Apr 25, 2011

JSR 269 Maintenance Review Concludes

The previously discussed maintenance review of JSR 269, after a slight extension, has concluded. Compared to the start of the cycle, the only change made during the review period was to rename the "disjunction"/"disjunctive" API elements to "union."




« July 2016

No bookmarks in folder