Re: GWT 2.2.0 broke binary compatibility for code generation

[David Chandler]

Hi Brian,

Unfortunately, no. In order to improve compiler extensibility, we replaced many compiler classes with interfaces in 2.2.0, but the consequences were not fully anticipated until the work had already been done. Unfortunately, using abstract classes instead of interfaces (which would solve the binary compatibility problem) is not practical as it would prevent implementation inheritance in compiler internals for somewhat complicated reasons. We've taken a hard look at the options, but don't have anything better to offer. Again, we're very sorry for the inconvenience to third-party contributors such as yourself.

If I'm not mistaken, maven has some facility for selecting a version on a conditional basis, so there might be a way to automatically detect the correct version of a third-party lib which is needed based on the GWT version specified in the POM, albeit it's not pretty.

/dmc

On Tue, Feb 22, 2011 at 3:40 PM, Brian Reilly <brian....@gmail.com> wrote:

Thank you for formally addressing this issue, David.

I notice that GIN 1.5 distributes 2 jars, one each for pre- and post-
GWT 2.2. I haven't looked into it yet but, from a library developer's
point of view, is there any hope of being able to distribute a single
jar that will work in either case? For a library that I work on, there
isn't any technical reason why the same code won't work with either
version of GWT and I'd rather not have to distribute two different
artifacts from the same source code.

Perhaps all library developers can rally behind some standard way of
supporting this (which seems particularly tough when using maven) so
that nobody has to be scared of upgrading to GWT 2.2. Otherwise, I
worry that this is going to be a painful transition.

-Brian

On Tue, Feb 22, 2011 at 3:10 PM, David Chandler <drfib...@google.com> wrote:
> Dear GWT community,
> The recent release of GWT 2.2.0 inadvertently broke binary (but not source)
> compatibility with any third party library that does code generation,
> including GIN. This was the result of an architectural change to the GWT
> compiler to support future improvements such as caching of generated
> artifacts.
> To resolve the issue, each jar that uses code generation must be recompiled
> with GWT 2.2.0. A new version of GIN (1.5) which works with 2.2.0 and
> earlier is now available
> at http://code.google.com/p/google-gin/downloads/list. If you're using other
> 3rd-party jars that use code generation, please update them also.
> If you are getting an error like the following, you are probably using a jar
> that needs to be recompiled with GWT 2.2.
> Caused by: java.lang.IncompatibleClassChangeError: Found interface
> com.google.gwt.core.ext.typeinfo.JClassType, but class was expected
> We apologize for the inconvenience, and for not informing you at the time of
> the release.
> /dmc
> --
> David Chandler
> Developer Programs Engineer, Google Web Toolkit
> w: http://code.google.com/
> b: http://googlewebtoolkit.blogspot.com/
> t: @googledevtools
>

> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-tool...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
David Chandler
Developer Programs Engineer, Google Web Toolkit
w: http://code.google.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

[Brian Reilly]

I'll have to look into maven to see if that can be done, but I'm not

too optimistic that it would work very well.

Is there a gwt.version property that we can check inside the

generate-with tag of the library's module XML? Theoretically, a

library could then provide two classes in a single jar... one compiled

against 2.1.1 and the other compiled against 2.2.

I'd even take a property that is new or that the default value changed

in 2.2... really anything to take the burden of worrying about this

off of the end developer.

-Brian

[Brian Reilly]

[David Chandler]

[Scott Blum]

I bet you could do something like this:

class FooGenerator extends Generator {

  private static final Generator impl;

  

  static {

    try {

      Class<?> jTypeClass = Class.forName("com.google.gwt.core.ext.typeinfo.JType");

      Class<?> generatorClass;

      if (jTypeClass.isInterface()) {

        generatorClass = Class.forName("com.example.foo.rebind.impl.FooGenerator");

      } else {

        generatorClass = Class.forName("com.example.foo.rebind.legacyimpl.FooGenerator");

      }

      impl = (Generator) generatorClass.newInstance();

    } catch (Exception e) {

      if (e instanceof RuntimeException) {

        throw (RuntimeException) e;

      }

      throw new RuntimeException(e);

    }

  }

  

  @Override

  public String generate(TreeLogger logger, GeneratorContext context,

      String typeName) throws UnableToCompleteException {

    return impl.generate(logger, context, typeName);

  }

}

--