John and I discussed this face to face. It turns out that the find() method has, perhaps, and unnecessarily complicated specification that pushes generic compile time sugar arguably past the point of usefulness --- and definitely past what OpenJDK allows. So our tentative resolution is to simplify the declaration of find() and make it slightly less powerful. It turns out none of our own code is making any use whatsoever of the extra flexibility it currently has.
On Mon, Mar 30, 2009 at 11:20 AM, John Tamplin <[email protected]> wrote: > On Sat, Mar 28, 2009 at 11:55 PM, Scott Blum <[email protected]> wrote: > >> Two things: >> 1) Do you have to use a temp, or can you do something >> like artifacts. <EmittedArtifact> find(EmittedArtifact.class)? Or whatever >> the syntax is. >> > > It could also be: > for (EmittedArtifact artifact : artifacts.<EmittedArtifact, > EmittedArtifact>find(EmittedArtifact.class)) { > etc if you prefer -- do you think that is cleaner? The problem here is > that OpenJDK can't seem to properly infer A=EmittedArtifact from the return > type SortedSet<A extends Artifact<?>> where EmittedArtifact extends > Artifact<EmittedArtifact> (defined as Artifact<C extends Artifact<C>>). > This is just one case of a general class of recursive definitions which > OpenJDK fails to infer, and the Sun guy working on it has determined that > the old javac accepted in violation of JLS. Since this seems very similar > to the definition of Enum, I can only guess Enum is special-cased. > > Still another option would be to pass an explicit type token for the return > type. We currently do not use the ability to return a different type, so > this would not require changing the call-sites if we did this: > public <T extends Artifact<? super T>> SortedSet<T> find(Class<T> > artifactType) { > return find(artifactType, artifactType); > } > > public <A extends Artifact<? super A>, T extends Artifact<? super T>> > SortedSet<A> find(Class<A> returnType, Class<T> artifactType) { > ... > } > > Would that be preferable? It would make it harder to introduce something > that wouldn't compile on OpenJDK, as you would get a compile error and would > have to add a second type token if you tried to return a different type, and > it avoids having to infer the return type in all current uses. > > 2) What's the plan for preventing regressuions or new occurrences of this >> in the future? >> > > I think when we upgrade our continuous build system, we should build with > OpenJDK. Until then, I can build with OpenJDK so whenever I build trunk it > would be noticed. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
