2.6.0-rc3

[Matthew Dempsky]

FYI, I've just pushed out 2.6.0-rc3, which also includes a workaround for the Eclipse plugin version warning.  (We decided not to wait for the GPE release, and to also be compatible with older GPE versions.)

I'm cautiously optimistic that this should be our last release candidate before 2.6.0 final.  Please test and let me know if you run into any issues.

On Tue, Dec 3, 2013 at 11:09 AM, Matthew Dempsky <mdem...@google.com> wrote:

On Tue, Dec 3, 2013 at 11:01 AM, Colin Alworth <nilo...@gmail.com> wrote:

What's the current thinking on removing ImageResource.isStandalone from 2.6.0 final, as in the https://gwt-review.googlesource.com/#/c/5504/ review?

Thomas added ImageResource.isStandalone several months ago (between 2.5.1 and 2.6.0), and it's been the longest outstanding patch for us [Google] to merge for internal customers.  We have a surprisingly large amount of internal code that implements ImageResource, and adding a new method to the interface broke all of those users.

As an interim solution, Goktug proposed we restructure things so the same change Thomas wanted is possible, but without making it into a breaking change for 2.6.0.

It isn't in GWT 2.5.x, and isn't in master, but is present in both 2.6.0-rc1 and 2. If it was an oversight to add this the first time around, shouldn't it be dropped from 2.6 before it goes final?

Yep, I plan to cut a new rc3 today.

Aside from that, seems to be passing all our smoke tests so far, will have more comprehensive results tomorrow.

Cool, thanks for testing!

[Thomas Broyer]

On Thursday, December 5, 2013 12:42:29 AM UTC+1, Matthew Dempsky wrote:

FYI, I've just pushed out 2.6.0-rc3, which also includes a workaround for the Eclipse plugin version warning.  (We decided not to wait for the GPE release, and to also be compatible with older GPE versions.)

I'm cautiously optimistic that this should be our last release candidate before 2.6.0 final.  Please test and let me know if you run into any issues.

I haven't investigated yet (really don't have time ATM, and I'm not sure I could find some before the final release) but it seems like when you pass "-sourceLevel 1.8" to the Compiler it doesn't fail with the "usage" help printed to the console, but instead happily sets the source level to 'null' (as it cannot find a matching enum value) and then fails later with an NPE.

See https://groups.google.com/d/msg/google-web-toolkit/p9ADHIfX2A8/-MfMuhoia9UJ

That was with RC1 and RC2 though, maybe it has changed in RC3 (BTW, does RC3 has "auto" already?).

The problem though is that looking at the code for ArgHandlerSource (now ArgHandlerSourceLevel), I couldn't see anything wrong; which would mean the issue is in the global handling of CLI arguments :-/

[Colin Alworth]

I'm still running into trouble with the major version of the compiled classes being 51, so I'm unable to gwt 2.6.0-rc3 to work under jdk 1.6. As before, I was able to confirm that the actual .class files are compiled correctly, but yet I get fatal errors in attempting to run dev mode. Testing so far is on a mac with 1.6.0_65:

$ java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

$ javap -v com.google.gwt.core.client.impl.Impl | head
Compiled from "Impl.java"
public final class com.google.gwt.core.client.impl.Impl extends java.lang.Object
  SourceFile: "Impl.java"
  InnerClass:
   public abstract #77= #76 of #170; //UncaughtExceptionHandler=class com/google/gwt/core/client/GWT$UncaughtExceptionHandler of class com/google/gwt/core/client/GWT
  minor version: 0
  major version: 50
  Constant pool:
const #1 = Method    #61.#163;    //  java/lang/Object."<init>":()V
const #2 = Field    #55.#164;    //  com/google/gwt/core/client/impl/Impl.unloadSupport:Lcom/google/gwt/core/client/impl/UnloadSupport;

When in dev mode, I've seen this error:
22:44:37.233 [ERROR] [com.example.SampleProject] Unable to load module entry point class null (see associated exception for details)
java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
    at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
    at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:249)
    at com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:670)
    at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:359)
    at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
    at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
    at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
    at java.lang.Thread.run(Thread.java:695)

When running unit tests in dev mode with HtmlUnit, I've seen this:
[ERROR] Unable to load module entry point class null (see associated exception for details)
    [junit] java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0
    [junit] Dec 5, 2013 10:51:41 PM com.gargoylesoftware.htmlunit.WebConsole info
    [junit]     at java.lang.ClassLoader.defineClass1(Native Method)
    [junit] INFO: /launch error: Failed to load module "com.example.SampleProject.JUnit".
    [junit]     at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
    [junit] Please see the log for details.
    [junit]     at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
    [junit]     at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
    [junit]     at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
    [junit]     at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
    [junit]     at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    [junit]     at java.lang.Class.forName0(Native Method)
    [junit]     at java.lang.Class.forName(Class.java:249)
    [junit]     at com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:670)
    [junit]     at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:359)
    [junit]     at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
    [junit]     at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
    [junit]     at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
    [junit]     at java.lang.Thread.run(Thread.java:695)

It has been driving me nuts trying to track down what mistake I could possibly be making - I've tried explicitly adding -sourceLevel 1.6 to the arguments (which parses correctly, I set breakpoints to avoid the possible null issue reported for java 8), but this hasn't seemed to have any effect. I'm willing to admit user error, but the really odd thing about this is that if I debug com.google.gwt.dev.shell.rewrite.WriteJsoImpl.ForJsoDollar's ctor or com.google.gwt.dev.asm.ClassWriter.toByteArray() I can pick out that some objects have version 49, some have 50, and at least one has 51 (which under java 6 is fatal).  Here's the stack at this point, paused on a case where version is 51:

ClassWriter.visit(int, int, String, String, String, String[]) line: 657   
UseMirroredClasses(ClassVisitor).visit(int, int, String, String, String, String[]) line: 112   
RewriteSingleJsoImplDispatches(ClassVisitor).visit(int, int, String, String, String, String[]) line: 112   
RewriteSingleJsoImplDispatches.visit(int, int, String, String, String, String[]) line: 144   
RewriteRefsToJsoClasses(ClassVisitor).visit(int, int, String, String, String, String[]) line: 112   
RewriteJsniMethods(ClassVisitor).visit(int, int, String, String, String, String[]) line: 112   
RewriteJsniMethods.visit(int, int, String, String, String, String[]) line: 339   
ClassReader.accept(ClassVisitor, Attribute[], int) line: 614   
ClassReader.accept(ClassVisitor, int) line: 506   
HostedModeClassRewriter.rewrite(TypeOracle, String, byte[], Map<String,String>) line: 251   
CompilingClassLoader.findClassBytes(String) line: 1313   
CompilingClassLoader.findClass(String) line: 1086   
CompilingClassLoader.loadClass(String, boolean) line: 1194   
CompilingClassLoader(ClassLoader).loadClass(String) line: 247   
Class<T>.forName0(String, boolean, ClassLoader) line: not available [native method]   

Sure enough, if I back up a few frames to ClassReader.accept:614 and inspect this.b, I see that indeed, something has read out 51 as the version (8th entry in the byte array):
[-54, -2, -70, -66, 0, 0, 0, 51, ...

A few more steps up to CompilingClassLoader.findClassBytes:1313 shows that this byte array (or an earlier version? I'm not quite clear) comes from line 1278:
classBytes = compiledClass.getBytes();

This compiledClass object is an instance of com.google.gwt.dev.javac.CompiledClass, and is where I start to suspect that my workspace is either *really* messed up, or that there is a bug that only hit some users.

Inspecting this object shows not a lot directly, but the CompiledClass.unit field has details that make it look like it is from the .gwtar file, a serialized set of Java objects from the precompile process. Inspecting compiledClass.unit.resourceLocation shows it is a string with this value:

file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/impl/Impl.java

I'm not seeing anything specific in the debugger that points to what is going on - I do see that there is some specific code in com.google.gwt.dev.util.DiskCache.readByteArray(long) that should be reading out the class byte[], but I haven't taken that further apart to see *why* it is reading 51 instead of the expected 50.

Modifying the gwt-user jar to not contain any gwtar files, and clearing out the local gwt-unitCache/ dir seems to resolve this, but I only attempted this after beginning this message, so I haven't fully vetted this. Both dev mode and unit tests appear to work correctly however. This does further point to a bug in GWT, at least from my perspective.

Can someone else verify that GWT 2.6.0-rc3 behaves correctly with Java 6?

I'm using the download from https://code.google.com/p/google-web-toolkit/downloads/detail?name=gwt-2.6.0-rc3.zip&can=2&q= for this testing.

[Roberto Lublinerman]

Hi Colin,

Did you do ant clean? I find it strange that the resource points to Matthew's hard drive, as if Impl was precompiled by him (and in that case probably is consistent that the version is 51.0).

I build from scratch in my laptop (only has java 1.6) and builds and tests run fine. Is there a specific application that you are trying to build?

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Colin Alworth]

Sorry for being unclear - I'm building/testing an application that makes use of GWT while still on Java6, not building/testing GWT itself. I'm trying to sanity test rc3 as a candidate for a final release of 2.6.0, and as far as my testing goes, this is the only point it is failing.

To clarify the point about the references to Matthew's machine, unzip the gwt 2.6.0-rc3 download on code.google.com, unpack the gwt-user.jar file, and try this:

$ strings com/google/gwt/core/Core.gwtar  | grep file | head
fileNameq
bfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/AsyncProvider.javat
fileNameq
]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Callback.javat
fileNameq
jfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/CodeDownloadException.javat
fileNameq
]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Duration.javat
fileNameq
fileNameq

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Roberto Lublinerman]

It seems that we need to build the release with -sourceLevel 6 for it to work with Java 6.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

[Colin Alworth]

Workaround: add -Dgwt.usearchives=false  to your jvm args when invoking the tests or dev mode. From maven this uses the extraJvmArgs param: http://mojo.codehaus.org/gwt-maven-plugin/compile-mojo.html#extraJvmArgs.

[Juan Pablo Gardella]

Thanks Colin, it seems this parameter disable some performance improvements:

GWT attempts to load pre-compiled GWT module archives (.gwtar files) to increase performance. Consequently, building GWT examples shipped with this release fails with the IBM implementations of the Java Developement Kit (both 1.6 and 1.7). To work around the issue, use the -Dgwt.usearchives=false parameter with gwt-maven-plugin to disable loading of the pre-compiled archives.

Source: https://bugzilla.redhat.com/show_bug.cgi?id=919447

And this argument is not listed in java -cp gwt-dev.jar com.google.gwt.dev.HostedMode

Thanks

2013/12/6 Colin Alworth <nilo...@gmail.com>

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

[Thomas Broyer]

On Saturday, December 7, 2013 12:52:12 AM UTC+1, juan_pablo_gardella wrote:

Thanks Colin, it seems this parameter disable some performance improvements:

GWT attempts to load pre-compiled GWT module archives (.gwtar files) to increase performance. Consequently, building GWT examples shipped with this release fails with the IBM implementations of the Java Developement Kit (both 1.6 and 1.7). To work around the issue, use the -Dgwt.usearchives=false parameter with gwt-maven-plugin to disable loading of the pre-compiled archives.

Source: https://bugzilla.redhat.com/show_bug.cgi?id=919447

And this argument is not listed in java -cp gwt-dev.jar com.google.gwt.dev.HostedMode

This only lists arguments, and gwt.userarchives is a system property (BTW, "HostedMode" ?!?!?)

I think someone really should update https://code.google.com/p/google-web-toolkit/wiki/JavaSystemPropertiesAndGwt

I'll try to do it if I find time (and remember about it)

[Juan Pablo Gardella]

Thanks for the link Thomas, but as you said was updated in 2010. HostedMode appears in http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html at the section "Development Mode Options".

2013/12/7 Thomas Broyer <t.br...@gmail.com>

--

[Thomas Broyer]

On Friday, December 6, 2013 8:03:57 AM UTC+1, Roberto Lublinerman wrote:

It seems that we need to build the release with -sourceLevel 6 for it to work with Java 6.

I haven't tested it (I'm releasing gwt-maven-plugin at the same time) so I'll wait for Leeroy Jenkins, but I gave it a try at https://gwt-review.googlesource.com/5650 (would have to be cherry-picked to release/2.6)

[Thomas Broyer]

On Saturday, December 7, 2013 7:42:42 PM UTC+1, juan_pablo_gardella wrote:

Thanks for the link Thomas, but as you said was updated in 2010.

Updated to latest master. I omitted 2 system properties that are deprecated; maybe a missed others.

 

HostedMode appears in http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html at the section "Development Mode Options".

Will fix. 

[Thomas Broyer]

See https://gwt-review.googlesource.com/5651 

[Juan Pablo Gardella]

Thanks Thomas!

2013/12/8 Thomas Broyer <t.br...@gmail.com>

--

[Colin Alworth]

This system property isn't listed when either dev mode or the compiler runs because it is a system property, not a program arg. It should be provided with the other VM args when you start Java. These aren't listed as part of the normal properties, but are documented here: http://code.google.com/p/google-web-toolkit/wiki/JavaSystemPropertiesAndGwt

We probably should migrate that table (and expand it?), but for the most part these are used to tweak internals that shouldn't normally be needed. In the case of the issue I'm pointing out with java6, it appears that this issue is only due to a build problem when the RC was originally compiled. The only other flag I use in the list with any regularity is gwt.jjs.traceMethods, which lets you see what the compiler is doing with each method as it works.

--
218.248.6165
nilo...@gmail.com

[Juan Pablo Gardella]

Thanks Colin

2013/12/9 Colin Alworth <nilo...@gmail.com>

[Matthew Dempsky]

Hm, so is building with Java 6 a new requirement due to how we implemented Java 7 support in GWT?  I thought I used Java 7 to build the GWT 2.5.1 release too, but I can make sure to use Java 6 instead going forward to build releases/release candidates/snapshots.

[Roberto Lublinerman]

It seems that the build script needs to pass -sourceLevel 6 when compiling .gwtars (which we seem to ship incompiled form). I think I saw a patch or email regarding that issue.

[Thomas Broyer]

On Monday, December 9, 2013 7:17:11 PM UTC+1, Roberto Lublinerman wrote:

It seems that the build script needs to pass -sourceLevel 6 when compiling .gwtars (which we seem to ship incompiled form). I think I saw a patch or email regarding that issue.

Yup, 2 days ago on that same thread ;-)

https://groups.google.com/d/msg/google-web-toolkit-contributors/fsZQR7c5HK8/rvinAzjFe2cJ

Direct link to review: https://gwt-review.googlesource.com/5650