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.

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

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.

Thursday Mar 24, 2011

Project Coin: JSR 334 in Public Review

After successfully going through early draft review, JSR 334 has now entered another phase: public review. Compared to the earlier draft review specification (v0.75), the main changes in the public draft review specification (v0.875) are:

  • The specification for diamond was expanded and clarified. Using diamond on a non-generic class is explicitly forbidden.

  • The specification for multi-catch was expanded and made more precise.

  • Several changes related to the try-with-resources feature:

    • The try-with-resources statement has dropped support for a resource to be given as a general expression without an accompanying explicit variable declaration.

    • An optional trailing semicolon is allowed to terminate the sequence of resources in a resource specification rather than producing a syntax error.

    • The compiler-generated calls to the close method of a resource in a try-with-resources statement only occur if the resource is non-null.

    • Strong warnings were added to the javadoc of AutoCloseable about having the close method throw InterruptedException.

  • The @SafeVarargs annotation was applied to appropriate places in the platform libraries.

  • JLSv3 changes were provided for the simplified varargs method invocation feature.

The public review draft of JSR 334 is the last expected JCP milestone before proposed final draft, so get your comments about the public review in soon!

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

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.

About

darcy

Search

Archives
« July 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
31
  
       
Today
News

No bookmarks in folder

Blogroll