difficulties constructing reduced example of super-source
Jake B
I'm still having trouble getting super-source to work. Right now, I'm
trying to come up with the simplest, most reduced example that uses
super-source, because the more complicated examples I have been
working from have failed to work. To this end, I have started with an
empty workspace, and created a new example GWT project. I then created
a new GWT Java project, created a new source folder src/gwt, and
created a new package java.io. In the package, I created
OutputStreamReader.java. To keep things as simple as possible, I
actually copy-pasted the minimal source code from the GWT
implementation:
I created a minimal, top-level module in src/gwt called
TestSuper.gwt.xml, which contains only a single empty super-source
tag. Finally, I added the super-source project to the example
project's build path, and added a line to the example project module
to inherit the super-source project's module.
To recap, my projects have the following structure:
test/
src/
foo.bar.test/
Test.gwt.xml
foo.bar.test.client/
foo.bar.test.server/
testsuper/
src/gwt/
TestSuper.gwt.xml
java.io/
OutputStream.java
When I try to run the example project in hosted mode, I get about 300
lines of errors. Here are the first few:
[ERROR] Errors in
'jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-dev-linux.jar!/com/google/gwt/dev/jjs/impl/Pruner.java'
[ERROR] Line 1041: The method subList(int, int) is undefined
for the type List<JExpression>
[ERROR] Errors in
'jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-user.jar!/com/google/gwt/junit/JUnitShell.java'
[ERROR] Line 42: The import junit cannot be resolved
[ERROR] Line 42: The import junit cannot be resolved
[ERROR] Line 44: The import junit cannot be resolved
[ERROR] Line 49: The import java.util.regex cannot be resolved
[ERROR] Line 50: The import java.util.regex cannot be resolved
[ERROR] Line 92: TestCase cannot be resolved to a type
[ERROR] Line 288: The type JUnitShell.JUnitStrategy must
implement the inherited abstract method
JUnitShell.Strategy.processResult(TestCase, JUnitResult)
[ERROR] Line 297: TestCase cannot be resolved to a type
[ERROR] Line 344: TestCase cannot be resolved to a type
...
[ERROR] Errors in
'jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-dev-linux.jar!/com/google/gwt/dev/ApplicationCreator.java'
[ERROR] Line 27: The method exit(int) is undefined for the type System
And it continues like. All errors originate in the GWT SDK.
When I attempt to compile it, I get a lot of warnings, and finally a NPE.
[WARN]
jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-user.jar!/com/google/gwt/event/dom/client/DomEvent.java
[WARN] Compilation unit
'jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-user.jar!/com/google/gwt/event/dom/client/HasMouseOutHandlers.java'
is removed due to invalid reference(s):
[WARN]
jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-user.jar!/com/google/gwt/event/shared/HasHandlers.java
[WARN] Compilation unit
'jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-user.jar!/com/google/gwt/i18n/client/impl/plurals/DefaultRule_ln.java'
is removed due to invalid reference(s):
[WARN]
jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-user.jar!/com/google/gwt/i18n/client/PluralRule.java
[WARN] Compilation unit
'jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-user.jar!/com/google/gwt/i18n/client/impl/plurals/DefaultRule_en.java'
is removed due to invalid reference(s):
[WARN]
jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-user.jar!/com/google/gwt/i18n/client/PluralRule.java
...
Refreshing TypeOracle
Processing types in compilation unit:
jar:file:/home/jacob/apps/eclipse/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/gwt-dev-linux.jar!/com/google/gwt/dev/js/ast/JsSourceInfo.java
Found type 'JsSourceInfo'
[WARN] Unable to resolve type: java.lang.Object
binding: org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding
[ERROR] Unexpected
java.lang.NullPointerException
at com.google.gwt.core.ext.typeinfo.JRealClassType.setSuperclass(JRealClassType.java:402)
at com.google.gwt.dev.javac.TypeOracleMediator.resolveTypeDeclaration(TypeOracleMediator.java:1407)
at com.google.gwt.dev.javac.TypeOracleMediator.addNewUnits(TypeOracleMediator.java:389)
at com.google.gwt.dev.javac.TypeOracleMediator.refresh(TypeOracleMediator.java:417)
at com.google.gwt.dev.javac.CompilationState.refresh(CompilationState.java:179)
at com.google.gwt.dev.javac.CompilationState.<init>(CompilationState.java:93)
at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:264)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:283)
at com.google.gwt.dev.Compiler.run(Compiler.java:170)
at com.google.gwt.dev.Compiler$1.run(Compiler.java:124)
at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84)
at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78)
at com.google.gwt.dev.Compiler.main(Compiler.java:131)
It is clear that my understanding of super-source is still
insufficient to construct even a reduced sample. Could anyone tell me
what it is I am doing that is causing my reduced example to fail to
compile?
Please let me know. Thanks,
Jake
Alyxandor
should!
Also, you've got to make your java.io hack-pack-age another level
deeper... You don't need to make two different source folders, that's
just to minimize IDE confusions....
Try this...
test/
src/
foo.bar.test/
Test.gwt.xml
TestSuper.gwt.xml
foo.bar.test.client/
foo.bar.test.server/
foo.bar.test.hack.java.io/
OutputStream.java
Where TestSuper.gwt.xml = <module><super-source path="hack"/></module>
Jake
Thanks for the quick response! I started a new workspace and created a
new project per your parameters. Adding a new GWT module to the
package foo.bar.test (for example TestSuper.gwt.xml) causes the
following error when running from hosted mode:
java.lang.NullPointerException
at com.google.gwt.core.ext.linker.impl.StandardLinkerContext.<init>
(StandardLinkerContext.java:164)
at com.google.gwt.dev.HostedMode.link(HostedMode.java:452)
at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:353)
at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:585)
at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:397)
at com.google.gwt.dev.HostedMode.main(HostedMode.java:232)
However, it compiles fine.
I'm not sure to what extent it is a problem to have hosted mode
broken, but compilation successful. I messed around with this a lot,
and am absolutely certain that this is caused by adding a new module
to foo.bar.test. This is strange because I've looked at the GWT source
code, and there are many packages that have many modules in them.
Perhaps this is a bug in the GWT Eclipse tooling. What do you think?
Thanks,
Jake
On May 14, 9:06 pm, Alyxandor <a.revolution.ultra.b...@gmail.com>
wrote:
Jake
now say that I have the reduced example working. Thanks for the
advice! It really made the difference.
I'm still curious about what was breaking GWT before. I've tried a
number of different permutations, first moving the super-source
library out into a separate project, so the directory structure looked
like this:
testsuper/
src/
foo.bar.test/
TestSuper.gwt.xml
foo.bar.test.hack.java.io/
OutputStream.java
And that worked. Then I put the library into its own project and a non-
src source folder, so the project structure looked like this:
testanothersuper/
foo/bar/bat/
emul
Testanothersuper.gwt.xml
emul.hack.java.io/
OutputStream.java
And that worked. As did:
testanotheranothersuper/
foo/bar/bat/
Testanothersuper.gwt.xml
hack.java.io/
OutputStream.java
What did NOT work were either of the following:
testanothersuper/
foo/bar/bat/
emul
Testanothersuper.gwt.xml
emul.java.io/
OutputStream.java
testanotheranothersuper/
foo/bar/bat/
Testanothersuper.gwt.xml
java.io/
OutputStream.java
Basically, in order for this to work, two things needed to be true:
* java.io had too be enclosed inside of another package (hack.*)
* OutputStream.java had to have a package declaration of "java.io" not
"hack.java.io".
If the second condition was not true, GWT would throw this kind of
error:
[ERROR] Line 11: The declared package "hack.java.io" does not match
the expected package "java.io"
This second condition also meant that the IDE would always get
confused and throw an error that OutputStream.java is in the wrong
package. This, in turn, was causing me, a GWT newb, to get confused,
as I just spent the last week or two trying to make both GWT and the
IDE happy. As you can see from my first post, I was trying to make it
so that the "wrapper" package (e.g. hack) was a source folder. This
made the IDE happy, but caused GWT to freak out. If there is a way to
satisfy the constraints of both the IDE and GWT, I cannot see it, and
I would greatly appreciate it if someone could point it out to me.
Fortunately, though, making the IDE happy is not critical to the
success of my project, and I think I can move on from here :D
I have one other question, but I'll put that in a separate thread.
Thanks again,
Jake
Alyxandor
Sorry about the "hack.java.io" part, I don't sleep much, so I
sometimes slip up ;-)
Basically, there's nothing you can do about your IDE... I always have
a couple errors now that I use super-source, but I like to think of
them like, "Error: GWT is too powerful for Java to handle, OVERLOAD!
OVERLOAD!"
...Hahahaha.
Thomas Broyer
On 15 mai, 03:06, Alyxandor <a.revolution.ultra.b...@gmail.com> wrote:
> Are you getting a "wrong package error"? Because if you aren't, you
> should!
projects build path (no need to compile the classes to Java .class,
with the risk of having them used in place of the Java runtime's ones;
only the source is needed, and only for the GWT Compiler, so what's
needed is that the "super" is in the classpath, not the build path!)
(however, adding it to the build path in Eclipse brings you better
editing, with better code completion, etc.)
Finally, it's more a matter of taste than a "rule" or even "best
practice"; but you have to understand what it means when you add the
"super" to the build path or not.
Not necessarily. GWT's Emul package uses <super-source/>, and so do I
in GWT-in-the-AIR (cf. http://code.google.com/p/gwt-in-the-air/source/browse/trunk/super/net/ltgt/gwt/air/emul/
)
> You don't need to make two different source folders, that's
> just to minimize IDE confusions....
code)
Jake B
Thanks again for the responses. See my replies below:
On Fri, May 15, 2009 at 5:51 AM, Thomas Broyer <t.br...@gmail.com> wrote:
>
>
>
> On 15 mai, 03:06, Alyxandor <a.revolution.ultra.b...@gmail.com> wrote:
>> Are you getting a "wrong package error"? Because if you aren't, you
>> should!
>
> Actually, I'd rather say you shouldn't add your "super" to the
> projects build path (no need to compile the classes to Java .class,
> with the risk of having them used in place of the Java runtime's ones;
> only the source is needed, and only for the GWT Compiler, so what's
> needed is that the "super" is in the classpath, not the build path!)
OK, that's very interesting! The distinction between the classpath and
the build path was not something that was clear to me before. Now, I
believe it is, but I'm not sure, how do you add a path to the
classpath without adding it to the build path in Eclipse? The GWT
module still needs to be found on the classpath. I took a look at the
.classpath from gwt-in-the-air:
It doesn't appear to reference super. Is this because .classpath sets
the project build path in Eclipse? How do you then set the classpath
so that the Emulation.gwt.xml module is finable, but not on the build
path?
> (however, adding it to the build path in Eclipse brings you better
> editing, with better code completion, etc.)
>
> Finally, it's more a matter of taste than a "rule" or even "best
> practice"; but you have to understand what it means when you add the
> "super" to the build path or not.
I still don't have a clear sense of this. What would you say it means
to add "super" to the build path?
>
>> Also, you've got to make your java.io hack-pack-age another level
>> deeper...
>
> Not necessarily. GWT's Emul package uses <super-source/>, and so do I
> in GWT-in-the-AIR (cf. http://code.google.com/p/gwt-in-the-air/source/browse/trunk/super/net/ltgt/gwt/air/emul/
> )
I still can't seem to get that to work :(
Not sure why, but my use of the empty <super-source/> tag always
causes GWT to fail. This is unfortunate, as it seems like it would be
the best way to make both GWT and the IDE happy. So, for example, with
gwt-in-the-air, my approach would have been to add
/super/net/ltgt/gwt/air/emul/ as a source folder (so, on the build
path). Then the emulated packages would be of the form java.*, which
would correspond to the declared package names in the *.java files.
This makes the IDE happy, and in my mind, it seems like GWT shouldn't
have a problem with it either. But, so far, this approach has always
failed for me, and I cannot see the reason for this, or where the
problem is originating. If someone can see it, and could point it out
to me, I would be extremely grateful.
Also, maybe if, as Thomas suggested, super wasn't on the build path,
then GWT won't freak out. But then, as Thomas said, you don't get the
IDE's help with these classes. I'll have to try this and see if it
makes a difference, but I'd really like to understand why the above
approach is failing.
Thanks,
Jake
Thomas Broyer
On 15 mai, 16:06, Jake B <otakuj...@gmail.com> wrote:
> Hi all,
>
> Thanks again for the responses. See my replies below:
>
>
> > On 15 mai, 03:06, Alyxandor <a.revolution.ultra.b...@gmail.com> wrote:
> >> Are you getting a "wrong package error"? Because if you aren't, you
> >> should!
>
> > Actually, I'd rather say you shouldn't add your "super" to the
> > projects build path (no need to compile the classes to Java .class,
> > with the risk of having them used in place of the Java runtime's ones;
> > only the source is needed, and only for the GWT Compiler, so what's
> > needed is that the "super" is in the classpath, not the build path!)
>
> OK, that's very interesting! The distinction between the classpath and
> the build path was not something that was clear to me before.
javac, the GWT's Compile, HostedMode, etc.).
The buildpath is what you compile from *.java to *.class, and you MUST
NOT compile your "super-source" classes to *.class or the Java runtime
could use them instead of its own classes (and fail, quite obviously).
> Now, I
> believe it is, but I'm not sure, how do you add a path to the
> classpath without adding it to the build path in Eclipse?
(select "user entries" then click the "advanced" button).
> The GWT
> module still needs to be found on the classpath. I took a look at the
> .classpath from gwt-in-the-air:
>
> It doesn't appear to reference super. Is this because .classpath sets
> the project build path in Eclipse?
configurations (hence the name).
> How do you then set the classpath
> so that the Emulation.gwt.xml module is finable, but not on the build
> path?
configurations..."; or replace "Run" with "Debug", they're the same
actually, at least in our case).
> > (however, adding it to the build path in Eclipse brings you better
> > editing, with better code completion, etc.)
>
> > Finally, it's more a matter of taste than a "rule" or even "best
> > practice"; but you have to understand what it means when you add the
> > "super" to the build path or not.
>
> I still don't have a clear sense of this. What would you say it means
> to add "super" to the build path?
is "seen" un run by the Java runtime when you launch, say, the GWT's
Compiler (and the Compiler is then using your own OutputStream instead
of the "normal" one)
> >> Also, you've got to make your java.io hack-pack-age another level
> >> deeper...
>
> > Not necessarily. GWT's Emul package uses <super-source/>, and so do I
>
> I still can't seem to get that to work :(
> Not sure why, but my use of the empty <super-source/> tag always
> causes GWT to fail. This is unfortunate, as it seems like it would be
> the best way to make both GWT and the IDE happy. So, for example, with
> gwt-in-the-air, my approach would have been to add
> /super/net/ltgt/gwt/air/emul/ as a source folder (so, on the build
> path). Then the emulated packages would be of the form java.*, which
> would correspond to the declared package names in the *.java files.
error about the "package" declaration (which Alyxandor talked about
earlier).
> This makes the IDE happy, and in my mind, it seems like GWT shouldn't
> have a problem with it either.
explanation, GWT is then using your own java.io.OutputStream class)
> But, so far, this approach has always
> failed for me, and I cannot see the reason for this, or where the
> problem is originating. If someone can see it, and could point it out
> to me, I would be extremely grateful.
build path. And make sure your launch configurations have "super"
added in the classpath (therefore, GWT will be able to see the *.java
files, but there wouldn't be corresponding *.class files to distract
the Java runtime)