Java 5.0 BLITZKRIEG!

[Scott Blum]

Hi guys,

We're going to try something kind of crazy to kick off GWT 1.5.  (I know right, 1.4 RC2 just went out the door?)  We're going to have an intense 3 day effort where the entire team is focused on knocking down all of the things needed to support Java 5.0.  What does this mean for you?

1) The build is likely to be broken on a regular basis.  We'll try to keep the build in a state where it gets to packaging, but if we coordinate this correctly, we'll have failing unit tests until the moment we're done ('cause that's how we'll know we're done).

2) We're all going to be extremely heads-down and not very responsive to email for a few days.

3) If you'd like to join in the effort, check out the task list below and who is assigned to what.  If you want to help out with one of the items that's called out, just email the person who is responsible for that task to coordinate.  If no one is assigned to it, or you think of things that need to be done which we missed, please email me.  In either case, please include the word "BLITZKRIEG" in the subject line so we'll see immediately that it's related to the Java 5.0 effort.

--Scott

Goals:

1. No warnings in client code from GWT source related to generics or 5.0 features
2. 1.4 client code should compile without error, but warnings are okay
3. (nice to have) No warnings in non-client code from GWT source related to generics or 5.0 features

Non-Goals:

1. Support serialization between client code that takes advantage of 5.0 language features and those same classes retrowoven and running on a 1.4 server
2. Replace all for loops with for-each

Prioritized Development Items:

• Build system / eclipse projects -> 1.5 - scottb #1
• TypeOracle support - mmendez #1 (tobyr consult w/ annotations)
• TypeOracle unit tests - rdayal #1 (tobyr consult w/ annotations)
  
• JRE, required classed (Enum, Iterable, some methods on java.lang types) - scottb #2 (tobyr will show off retroweaver stuff)
• Compiler unit tests, possible can be lifted from existing sources - bobv #1 (tobyr as backup)
• Compiler support - scottb #2 (generics, for-each highest priority, enums)
• JRE, language (generic collections, etc) - jat #1
• JRE, function (new methods on existing classes, new classes as appropriate) - ajr, fabbott #1 (tobyr will show off retroweaver stuff)
• Support JSNI in hosted mode (whatever this means; probably needs some research) - jat #2
• RPC - mmendez #2
•  Allow generic syntax in lieu of @ gwt.typeArgs - mmendez #3
• Other generators (I18N, JUnit); should compile with 5.0 code, maybe produce annotations as nice to have - rdayal #2
• UI library, GWT - knorton #1
• Samples - jlabanca #1
• Update other unit tests to 5.0 stuff - just divide responsibility as needed for now
  
• Annotation czar - tobyr #1
• 1.4 compatible gwt-servlet? (consider whether RPC can work between 1.5 client / 1.4 server) - tobyr #2
•  Maybe it's okay if 1.4-compatible client code is used on the client
•  See Non-Goal 1
• Warning removal - everyone when you're blocked on something else

Java 5.0 feature reference:

• generics
• perhaps the bulk of work
  
• autoboxing
• mainly compiler work?
  
• annotations
  
• enums
  
• foreach
• static imports
• low impact
• variable arity methods
• syntactic suger to auto-construct an array as the last argument; mostly compiler
• probably possible to update existing apis that take an array as the last arg to be vararg instead without breaking source compatibility; must check this
  
• covariant return types
• low impact
  

[Andrés Testi]

I hope to see code generation raised by annotations in GWT 1.5. For
example:
@interface MyAnnotation{....}

@MyAnnotation
class MyClass{....}

// and here the magic
MyClass mc = (MyClass)GWT.create(MyAnnotation.class);

I don't like the actual way of using interfaces as markers. I want
domain model classes cleaner as possible. ;)

GWT Team is being done a great work every day.
Congratulations!

On 20 ago, 19:15, "Scott Blum" <sco...@google.com> wrote:
> Hi guys,
>
> We're going to try something kind of crazy to kick off GWT 1.5. (I know
> right, 1.4 RC2 just went out the door?) We're going to have an intense 3
> day effort where the entire team is focused on knocking down all of the
> things needed to support Java 5.0. What does this mean for you?
>
> 1) The build is likely to be broken on a regular basis. We'll try to keep
> the build in a state where it gets to packaging, but if we coordinate this
> correctly, we'll have failing unit tests until the moment we're done ('cause
> that's how we'll know we're done).
>
> 2) We're all going to be extremely heads-down and not very responsive to
> email for a few days.
>
> 3) If you'd like to join in the effort, check out the task list below and
> who is assigned to what. If you want to help out with one of the items
> that's called out, just email the person who is responsible for that task to
> coordinate. If no one is assigned to it, or you think of things that need
> to be done which we missed, please email me. In either case, please include
> the word "BLITZKRIEG" in the subject line so we'll see immediately that it's
> related to the Java 5.0 effort.
>
> --Scott
>

> *Goals:*
>
> 1. No warnings in client code from GWT source related to generics or
> 5.0 features
> 2. 1.4 client code should compile without error, but warnings are okay
> 3. (nice to have) No warnings in non-client code from GWT source

> related to generics or 5.0 features
>

> *Non-Goals:*
>
> 1. Support serialization between client code that takes advantage of

> 5.0 language features and those same classes retrowoven and running on
> a 1.4 server

> 2. Replace all for loops with for-each
>
> *Prioritized Development Items:*
>
> - Build system / eclipse projects -> 1.5 - *scottb #1*
> - TypeOracle support - *mmendez #1 *(tobyr consult w/ annotations)
> - TypeOracle unit tests - *rdayal #1 *(tobyr consult w/ annotations)
> - JRE, required classed (Enum, Iterable, some methods on java.langtypes) -
> *scottb #2* (tobyr will show off retroweaver stuff)
> - Compiler unit tests, possible can be lifted from existing sources -
> *bobv #1* (tobyr as backup)
> - Compiler support - *scottb #2* (generics, for-each highest priority,
> enums)
> - JRE, language (generic collections, etc) - *jat #1*
> - JRE, function (new methods on existing classes, new classes as
> appropriate) - *ajr, fabbott #1* (tobyr will show off retroweaver
> stuff)
> - Support JSNI in hosted mode (whatever this means; probably needs
> some research) - *jat #2*
> - RPC - *mmendez #2*
> - Allow generic syntax in lieu of @gwt.typeArgs - *mmendez #3*
> - Other generators (I18N, JUnit); should compile with 5.0 code, maybe
> produce annotations as nice to have - *rdayal #2*
> - UI library, GWT - *knorton #1*
> - Samples - *jlabanca #1*
> - Update other unit tests to 5.0 stuff - just divide responsibility as
> needed for now
> - Annotation czar - *tobyr #1*
> - 1.4 compatible gwt-servlet? (consider whether RPC can work between
> 1.5 client / 1.4 server) - *tobyr #2*
> - Maybe it's okay if 1.4-compatible client code is used on the
> client
> - See Non-Goal 1
> - Warning removal - everyone when you're blocked on something else
>
> ***Java 5.0 feature reference:*
>
> - generics
> - perhaps the bulk of work
> - autoboxing
> - mainly compiler work?
> - annotations
> - enums
> - foreach
> - static imports
> - low impact
> - variable arity methods
> - syntactic suger to auto-construct an array as the last
> argument; mostly compiler
> - probably possible to update existing apis that take an array

> as the last arg to be vararg instead without breaking source
> compatibility;
> must check this

> - covariant return types
> - low impact

[Andrés Testi]

Sorry, the above code must be:

MyClass mc = (MyClass)GWT.create(MyClass.class);

And the module definition:
<generate-with class="helloworld.MyAnnotationGenerator">
<when-annotated-with class="helloworld.MyAnnotation"/>
</generate-with>

;)

[Scott Blum]

That seems perfectly sensible to me, whether it makes it into the initial blitz or not.  CC'ing the Annotations Czar. :)

> >       -  Allow generic syntax in lieu of @ gwt.typeArgs - *mmendez #3*

[Reinier Zwitserloot]

Wow. Quite the ambition. Kudos!

There are some GWT APIs that could be rewritten to work better with
java5 features (example: generics to replace typeargs) but releasing
1.5 compatibility first, then scouting through the GWT sources for
opportunities to use annotations and/or generics later sounds like a
good plan.

In theory, there are a few more java5 changes but I'm not sure if the
GWT compiler is even affected by them:

1. Types across the java landscape are covariant from java 1.5 and
up. In generics, this looks like: List<Serializable && Comparable>,
but that's not the only place where they can occur. For example, the
type of the expression:

(?) something = (1 == 1 ? new C() : new D()); is (A && B), so
inserting either A or B for (?) is legal, where A, B, C, and D are
defined as:

public interface A {}, public interface B {}, public class C
implements A, B {}, public class D implements A, B {}

As a side-effect, the third parameter to the ternary operator is
allowed to be a supertype of the second parameter, which wasn't legal
in java 1.4. e.g currently illegal in GWT:

Widget x = someBoolean ? new Label() : new TextBox();

but that would be perfectly legal in java 1.5.

There's no way to write explicit covariant types in java outside of
generics parameters, but this feature lies at the root of the changes
to return type covariance, generics covariant parameters, and the
updates to the ternary operator.

I'm not sure how much of the javac classes are being used by GWT -
possibly you get all this for free.

2. A couple extra classes in java.util and java.lang, such as
java.lang.StringBuilder, and java.util.Formatter (the engine behind
printf and String.format).

[Scott Blum]

On 8/21/07, Reinier Zwitserloot <rein...@gmail.com> wrote:

1. Types across the java landscape are covariant from java 1.5 and
up. In generics, this looks like: List<Serializable && Comparable>,
but that's not the only place where they can occur. For example, the
type of the expression:

    (?) something = (1 == 1 ? new C() : new D());     is (A && B), so
inserting either A or B for (?) is legal, where A, B, C, and D are
defined as:

public interface A {}, public interface B {}, public class C
implements A, B {}, public class D implements A, B {}

As a side-effect, the third parameter to the ternary operator is
allowed to be a supertype of the second parameter, which wasn't legal

in java 1.4 . e.g currently illegal in GWT:

Widget x = someBoolean ? new Label() : new TextBox();

but that would be perfectly legal in java 1.5.

There's no way to write explicit covariant types in java outside of
generics parameters, but this feature lies at the root of the changes
to return type covariance, generics covariant parameters, and the
updates to the ternary operator.

Thanks for the heads up on this, I've made a note.  Bob, can you be sure to hit this case in the test coverage?

2. A couple extra classes in java.util and java.lang, such as

java.lang.StringBuilder , and java.util.Formatter (the engine behind
printf and String.format).

Yeah, we're looking at all the things that were added to the JRE between 1.4 and 1.5 and putting together a proposed list of things we're really like to hit.

Scott

[Reinier Zwitserloot]

Matthew Mastracci asked for some specs on the intersection types so
here we go:

There's a little bit here:

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.9

about how types in all places in java1.5 are really sets of
intersecting types, and here is how you can write your own in generics
type parameters:

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.4

(the official term for this is apparently 'additional bounds', and I
screwed up a little, the syntax is to use only 1 & symbol, not 2, so
it would be:

List<Comparable & Serializable> list = new
ArrayList<SomeClassThatImplementsBoth>(); //legal but rarely seen
java code.

[Toby Reyelts]

I think that, in general, it makes sense to have a more flexible policy on generators. I'd go as far as saying that we might want to allow generators to run without involving calls to GWT.create. That would be closer to Java's APT model, which already shares heavy similarities to GWT generators.

I would like to see more thoughts from folks outside of the GWT team about how they might improve generators in the face of annotations.

[Reinier Zwitserloot]

Here's a little code sample to show off some of the intersection type
stuff from java 1.5. This compiles without error or warning and runs
fine on javas since 1.5. Perhaps it can be useful as a test case of
sorts, though the real test is not so much the one assert in here, but
the fact that it even compiles on the gwt compiler.

Apparently apple needs to be taught a thing or two about testing
because Apple's javac will choke on this code. I'll be reporting a bug
there next :-P. Eclipse's java compiler does work fine, and I gave
this a whirl on solaris java and there it works too.

interface A { void methodA(); }
interface B { void methodB(); }
class C implements A, B { public void methodA() {} public void
methodB() {} }
class D implements A, B { public void methodA() {} public void
methodB() {} }

final class Complex implements Comparable<Complex>,
java.io.Serializable {
private final double real, imaginary;

public Complex(double real, double imaginary) {
this.real = real;
this.imaginary = imaginary;
}

public double getMagnitude() {
return Math.sqrt(real*real + imaginary*imaginary);
}

public int compareTo(Complex other) {
double d1 = getMagnitude();
double d2 = other.getMagnitude();
return (d1 < d2) ? -1 : ((d1 == d2) ? 0 : 1);
}
}

public class Test<T extends Comparable<T> & java.io.Serializable> {
// This method does lots of weird things that would toss
// syntax errors on virtually every line in java 1.4.
public Test(T item1, T item2) {
java.io.Serializable x = item1;
Comparable<T> y = item1;
T z = item2;
//Note that 'T's are assignable as:
//T, Comparable<T>, or Serializable.
assert y.compareTo(z) > 0;
//expression has intersection type A&B.
A a = (x == null) ? new C() : new D();
B b = (x != null) ? new C() : new D();
b.methodB();
((1 == 1) ? new C() : new D()).methodA();
//This next line actually blows up apple's java, both 1.5 and
1.6beta1.
//the bug is: a NoSuchMethodError occurs here during
run.
((1 == 1) ? new C() : new D()).methodB();
}

public static void main(String[] args) {
Test.make(new Complex(2, 5), new Complex(3, 4));
}

public static <V extends Comparable<V> & java.io.Serializable>
Test<V> make(V t1, V t2) {
return new Test<V>(t1, t2);
}
}

[Andrés Testi]

I agree with you, Toby. I propose your idea later, in another thread
in this forum. APT is a powerfull standard feature. It's more natural
to Java Programmers. With APT, GWT becomes more similar to JDK. I hope
to see the APT as an alternative (or replacement) to Generators in GWT
1.5 :)

On 21 ago, 13:41, "Toby Reyelts" <to...@google.com> wrote:
> I think that, in general, it makes sense to have a more flexible policy on
> generators. I'd go as far as saying that we might want to allow generators
> to run without involving calls to GWT.create. That would be closer to Java's
> APT model, which already shares heavy similarities to GWT generators.
>
> I would like to see more thoughts from folks outside of the GWT team about
> how they might improve generators in the face of annotations.
>
> On 8/20/07, Scott Blum <sco...@google.com> wrote:
>
>
>
> > That seems perfectly sensible to me, whether it makes it into the initial
> > blitz or not. CC'ing the Annotations Czar. :)
>

[Andrés Testi]

As code generation is done in Hosted Mode, you can use the JDK-APT
implementation. You don't need to do any implementation to support
APT. It sounds good!

[Alex Tkachman]

I would love to be able to provide more parameters to generator. For
example, I want toi give filename to load and use during generation
process.

[Scott Blum]

We should move this discussion to another thread, I think.

On 8/21/07, Toby Reyelts <to...@google.com> wrote:

[Alex Tkachman]

Hi Scott!

How can I help with compiler?

Best regards
Alex

[Scott Blum]

Here's my initial plan of attack:

1) Figure out how JDT represents the various 5.0 constructs.  I expect generics to be the most complicated.

2) Decide what can be done in GenerateJavaAST over existing AST nodes vs. what new AST nodes will be needed.

My thinking is that an initial pass could be done without introducing generics into the AST proper.  We could essentially emulate type erasure at compile time and throw away generic type information for now.  I thought I'd go down this path until/unless we hit a signficant roadblock.

JDT is such a complicated beast, it'd actually be very useful if you wanted to probe its murky depths (item 1) independently, so we can compare notes.  Then we can discuss step 2.

On 8/21/07, Alex Tkachman <alex.t...@gmail.com> wrote:

Hi Scott!

How can I help with compiler?

Best regards
Alex

On 8/21/07, Scott Blum <sco...@google.com> wrote:
> Hi guys,
>
> We're going to try something kind of crazy to kick off GWT 1.5.  (I know
> right, 1.4 RC2 just went out the door?)  We're going to have an intense 3
> day effort where the entire team is focused on knocking down all of the

> things needed to support Java 5.0 .  What does this mean for you?