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


On Thu, Dec 5, 2013 at 10:43 PM, Colin Alworth <niloc...@gmail.com> wrote:

> 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
>
>
> On Friday, December 6, 2013 12:10:10 AM UTC-6, Roberto Lublinerman wrote:
>
>> 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?
>>
>>
>>
>>
>> On Thu, Dec 5, 2013 at 9:23 PM, Colin Alworth <nilo...@gmail.com> wrote:
>>
>>> 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/p9ADH
>>>> IfX2A8/-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.
>>>
>>
>>  --
> 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.
>

-- 
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.

Reply via email to