Friday Dec 09, 2011

State of the Lambda updated

A new edition of the State of the Lambda is available here.

Update: These documents have been updated for the release of Java SE 8: State of the Lambda and State of the Lambda, Libraries Edition.

Wednesday Nov 16, 2011

Slides from Devoxx talk on Language / Library / VM Co-Evolution

For those of you who missed the talk at Devoxx (or on Parleys), the slides for my Devoxx talk on Language / Library / VM Co-Evolution in Java SE 8 are here.

Monday Aug 22, 2011

JVM Language Summit videos posted

The videos from the 2011 JVM Language Summit have been posted on Oracle Media Network.  My talk on Virtual Extension Methods (Defender Methods) for Java is here:
Slides and collateral are here:

Wednesday May 11, 2011

Quantitative language design

Quantitative Language Design:

Monday Dec 06, 2010

Lambda JSR approved

The JSR for Lambda (as well as the JSRs for Project Coin, Java SE 7, and Java SE 8) have been approved by the JCP Executive Committee! 

(Slightly) more detail at:

Wednesday Nov 17, 2010

Lambda JSR filed

The Lambda JSR has been filed:

Monday Aug 16, 2010

New draft of Defender Methods

I've posted a new draft of the interface evolution document here

Wednesday Jul 14, 2010

State of the Lambda

A new draft of the "State of the Lambda" is up here.  (Update: this is an old version, newer version is here.)

Thursday Jul 01, 2010

Four weeks to the JVM Language Summit!

On July 26-28, we are again hosting the JVM Language Summit, a fantastically geeky gathering of language, VM, and tooling engineers at Oracle’s Sun Santa Clara Campus.  A provisional agenda is posted on the website; there is still room to register.

Monday Jun 07, 2010

Exception transparency in Java

One of the features being considered under Project Lambda is exception transparency. While this feature is not specifically required for adding lambda expressions to the Java language, it increases the expressive power of generic libraries that use closures.

Please direct any comments on this blog entry to the lambda-dev list, rather than to this blog.

Problem statement

One of the weaknesses of generics in Java is the treatment of checked exceptions. Generics provide reasonable power at abstracting over method return types and argument types, but they do not do a very good job when abstracting over the types of checked exceptions that can be thrown by a method. The result of this has been that few libraries use generic exceptions. Instead, libraries which take callback objects tend to move towards one of two extremes, illustrated by Runnable (which throws nothing) and Callable (which throws everything):

public interface Runnable {
    public void run();

public interface Callable<V> {
    V call() throws Exception;

Both of these extremes are undesirable. With Runnable, one must go through lengths to wrap the exception in an unchecked exception or invent an alternate means of exposing the exception to the initiator (see ExecutionException in java.util.concurrent). With Callable, one must catch Exception regardless of what the block throws, which is bad in two ways: unneeded boilerplate coding when the block does not throw, and encouraging users to catch Exception rather than a more targeted exception type.

Adding closures to the language exacerbates this problem, as more libraries will want to take block-like constructs and execute them.

The core of the problem is that generic type parameters are monadic [1]; a formal type parameter E of a generic type must represent exactly one type. But throws clauses are variadic; they can contain zero or more types. So while it is possible to generify over thrown exception types, one can only do so if one is willing to commit to the adicity of the throws clause, which is effectively useless for modeling arbitrary callbacks:

// This is pretty much useless!
public interface ExceptionalCallable<V, E extends Exception> {
    V call() throws E;

Variadic type parameters

One solution to this problem is to extend generics to allow a restricted form of variadic type parameters, which can represent zero or more types with a common upper bound. There are few places where variable-length lists of types are permitted in the Java language; one is the throws clause of a method, and another is (or will be, being added under Project Coin) is the catch clause of a try block.

A throws type parameter is a generic type parameter that is introduced with the keyword throws; throws type parameters implicitly have an upper bound of Exception (though any upper bound that is a subtype of Throwable may be explicitly specified) and can correspond to zero or more actual types that are subtypes of the upper bound.

Here is an example of how this might look:

 interface Block<T, throws E> {
     public void invoke(T element) throws E;

 interface NewCollection<T> { 
     public<throws E> forEach(Block<T, throws E> block) throws E;

Here, Block is a generic interface whose type signature includes a throws type parameter E. The forEach method in NewCollection is a generic method, where the type parameter E of block is inferred from its argument, and forEach is declared to rethrow exactly the exceptions thrown by the block argument.

Note that it is perfectly possible that a generic method or class might have more than one throws type parameter:

<T, throws X, throws Y> 
T executeOne(Block<T, throws X> first, 
             Block<T, throws Y> second) 
        throws X, Y {
    if (randomEvent())

Exception transparency

With the throws type parameter on the Block interface, we can now accurately generify over the set of exceptions thrown by the Block; with the generic forEach method, we can mirror the exception behavior of the block in forEach(). This is called exception transparency because now the exception behavior of forEach can match the exception behavior of its block argument. Exception transparency simplifies the construction of library classes that implement idioms like internal iteration of data structures, because it is common that methods that accept function-valued arguments will invoke those functions, meaning that the library method will throw a superset of the exceptions thrown by its function-valued arguments.

Details and open issues

A throws type parameter is declared in the formal parameter list of a generic class or interface or of a generic method, is introduced by the keyword throws, and optionally may have an explicit upper bound (which must be a subtype of Throwable). If the upper bound is omitted, it is assumed to be Exception.

A throws type parameter may appear in the actual parameter list for a generic variable declaration (only in a position corresponding to a throws parameter), in a throws clause of a method, or in the formal argument of a catch block. Where it appears in the catch block, it is treated by the compiler as a catch of its erasure.

It is expected that most of the time, throws parameters will be inferred by the compiler rather than explicitly stated, such as when SAM-converting a lambda expression to a SAM interface type such as Block in our example.

A syntax is required to indicate that an actual type parameter for a throws type variable is niladic. In BGGA this was "throws Nothing"; we will likely use "throws void" or "throws Void".

We may wish to not require the throws keyword at the use site; Block<E> instead of Block<throws E>.

[1] Monadic in the sense of fixed adicity (arity), not in the sense of category theory or functional programming.

Wednesday Feb 18, 2009

How to get your JavaOne talk accepted

Putting on a conference like JavaOne is no small task.  The centerpiece of the conference is, of course, the technical sessions, and numerous reviewers spend a great deal of time combing through the proposals.  This year, we had over 1300 proposals -- more than five times as many proposals as we had slots! That's some tough competition.

Submitters are often frustrated by the binary answer they receive about their talk (accepted or rejected), but the reality is that it is impractical to compose an explanation for why each talk was rejected.

So, just what does make a great JavaOne submission?

•  Be aware of the tracks, and make sure your talk really fits one.  The message is partially shaped by the choice of tracks, and they differ somewhat from year to year.  Make sure your talk fits into one of the specified focus areas, and submit it to the \*right\* track, otherwise your talk will garner reviews like "Nice talk, but doesn't seem a good fit for this track." (Also be aware that each track has a separate review committee.)

Talks that submit to too many tracks are really at a disadvantage, not just because you will annoy the review team by "spamming" the tracks, but because of how the review process works -- review scores are aggregated across all reviewers for that talk, not just within a track.  So if your talk was bang-on for track A, and off-topic for track B, those bad marks for "not a good fit for this track" from B will get averaged in with the great marks from A, and your otherwise excellent talk will float to the middle of the pack. And the middle talks don't get taken.

So pick the right track, and submit to that track only.  If the talk doesn't fit any track, you should probably propose a different topic.

•  Be current!  Technology moves fast.  A topic that was a big hit two years ago may be old hat this year. 

•  Easy on the marketing.  Sure, there's plenty of marketing at JavaOne, but talks that read like marketing pitches will not make the cut.  The reviewers are all engineers, and they hate that sort of stuff.

•  Carve a niche.  Bear in mind that you are facing some tough competition. Searching through the submissions database, a search for Scala hits over 100 talks, a search for "concurrency" over 35, and a search for performance over 200.  Whatever you are talking about, you're likely to be up against some stiff competition -- especially in the core topic areas -- so make your talk stand out by offering a unique perspective, topic, or presentation approach.

Oh, and the #1 thing you can do to improve your chances:

•  Tell us what you're actually going to talk about!  You would be amazed at how many talks are absurdly light on details.  Believe it or not, we see lots of submissions like "I would like to present on <general topic>.  <General topic> is great!  I'm going to discuss the pros and cons of <general topic> in great detail.  It will be great!"  More talks get rejected because of not enough detail than anything else; talks that are light on details are just too risky to accept when there are plenty of more detailed submissions.   Don't leave any room for guessing about what you'll be talking about.

Brian Goetz is Java Language Architect at Oracle Corporation.


« April 2014