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.
On Thursday, December 5, 2013 9:16:29 AM UTC-6, Thomas Broyer wrote:
>
>
>
> 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 :-/
>
>
--
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-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
