Problem compiling GWT code with Java9

[Dave Bradlee]

At Labkey.com we're trying to compile all of our code, which includes GWT code, with Java9 (due for release in the summer)....getting a head start. We have not been able to compile GWT code, which doesn't use any new Java features. We're getting the error

     [java] Compiling module org.labkey.experiment.property.Designer

     [java]    [ERROR] Unable to find type 'java.lang.Object'

     [java]       [ERROR] Hint: Check that your module inherits 'com.google.gwt.core.Core' either directly or indirectly (most often by inheriting module 'com.google.gwt.user.User')

We've had an older version of GWT but have tried with the latest 2.8 as well and get the same thing. I've added -logLevel=DEBUG to get more info and the log says we're inheriting all of the appropriate packages, including com.google.gwt.core.Core and com.google.gwt.emul.Emulation, which of course is where java.lang.Object lives. It seems like something is going wrong with gwt-unitCache because the log looks like this:

..........lots of inherits before this..........

     [java]       Module location: file:/Users/davebradlee/trunk/server/internal/gwtsrc/org/labkey/api/gwt/Internal.gwt.xml

     [java]       Loading inherited module 'com.extjs.gxt.ui.GXT'

     [java]          Module location: jar:file:/Users/davebradlee/trunk/external/lib/build/gxt.jar!/com/extjs/gxt/ui/GXT.gwt.xml

     [java]          Loading inherited module 'com.google.gwt.json.JSON'

     [java]             Module location: jar:file:/Users/davebradlee/trunk/external/lib/build/gwt-user.jar!/com/google/gwt/json/JSON.gwt.xml

     [java]       Loading inherited module 'com.allen_sauer.gwt.dnd.gwt-dnd'

     [java]          Module location: jar:file:/Users/davebradlee/trunk/external/lib/server/gwt-dnd-3.2.0.jar!/com/allen_sauer/gwt/dnd/gwt-dnd.gwt.xml

     [java] Public resources found in...

     [java] Translatable source found in...

     [java] Persistent unit cache dir set to: /Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache

     [java] Opening cache file: /Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache/gwt-unitCache-6a094daf5d20bb65adf2d207cc48308bde849f64-0000015A3E41072B

     [java] Looking for previously cached Compilation Units in /Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache

     [java] Compiling module org.labkey.experiment.property.Designer

     [java]    Found 0 cached/archived units.  Used 0 / 0 units from cache.

     [java]    Compiling...

     [java]       Compilation completed in 0.00 seconds

     [java]    PersistentUnitCache cleanup requested

     [java]    Added 0 units to PersistentUnitCache since last cleanup

     [java]    Skipped PersistentUnitCache because no units were added

     [java]    Removing invalidated units

     [java]    Resolving enclosing classes

     [java]    Tracing compile failure path for type 'java.lang.Object'

     [java]       Checked 0 dependencies for errors.

     [java]    [ERROR] Hint: Check that your module inherits 'com.google.gwt.core.Core' either directly or indirectly (most often by inheriting module 'com.google.gwt.user.User')

     [java] Closing cache file: /Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache/gwt-unitCache-6a094daf5d20bb65adf2d207cc48308bde849f64-0000015A3E41072B (0 units written)

     [java] Deleting empty file: /Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache/gwt-unitCache-6a094daf5d20bb65adf2d207cc48308bde849f64-0000015A3E41072B

     [java] Shutting down PersistentUnitCache thread

Using Java8 the log looks like this

.......

     [java] Persistent unit cache dir set to: /Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache

     [java] Opening cache file: /Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache/gwt-unitCache-6a094daf5d20bb65adf2d207cc48308bde849f64-0000015A3E53CB49

     [java] Looking for previously cached Compilation Units in /Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache

     [java] Compiling module org.labkey.experiment.property.Designer

     [java]    Found 0 cached/archived units.  Used 0 / 3794 units from cache.

     [java]    Compiling...

     [java]       60% complete (ETR: 3 seconds)

     [java]       60% complete (ETR: 3 seconds)

     [java]       60% complete (ETR: 3 seconds)

     [java]       60% complete (ETR: 3 seconds)

     [java]       60% complete (ETR: 3 seconds)

     [java]       60% complete (ETR: 3 seconds)

     [java]       60% complete (ETR: 3 seconds)

     [java]       70% complete (ETR: 2 seconds)

     [java]       80% complete (ETR: 2 seconds)

     [java]       90% complete (ETR: 1 seconds)

     [java]       100% complete (ETR: 0 seconds)

     [java]       Compilation completed in 10.80 seconds

     [java]    PersistentUnitCache cleanup requested

     [java]    Added 3794 units to PersistentUnitCache since last cleanup

Anyway, has anyone else tried to compile GWT code with Java9? Or any ideas how we might make the compiler happy?

Thanks!

-- Dave

[Jens]

I think it is more a class path / module path issue than a unitCache issue (you can always delete the unit cache or don't use it at all by disabling it on the command line). I guess GWT Compiler simply does not see Core.gwt.xml even though you have inherited it.

-- J.

[Thomas Broyer]

On Wednesday, February 15, 2017 at 10:17:30 AM UTC+1, Dave Bradlee wrote:

Anyway, has anyone else tried to compile GWT code with Java9? Or any ideas how we might make the compiler happy?

I hadn't tried until now, but have the exact same error with 9-ea+152 (using package oracle-java9-installer from webupd8 on Ubuntu 16.10) on a simple hello-world project (that compiles OK with Java 8).

Trying to run GWT's own test suite with Java 9 might possibly help understand where the problem comes from.

[shital patil]

Did you find any solution to this. I am facing same issue

I tried to pass vm arg --add-modules=java.se.ee but still it doesnot work.

[James Nelson]

Hi.

Per this thread:

https://plus.google.com/+JamesNelsonX/posts/gBfpBDnwV9V

I have actually dove into Java 9 support, and cleared all the roadblocks once (before the JCP pushback force the module system to get more last minute changes).

The main issue was not language support (easy upgrade from eclipse jdt), or a tiny change for try-with-resources (allows effectively final variable references, instead of only local variable declarations)...
The biggest problem was the changes to the classloading system.

Specifically, they no longer use URLClassLoader for system classloaders, meaning that any attempts to "rip out the classpath" will not work any longer.

I managed to hack together a working compile where I check if java 9 classloaders are in use, and if so, use reflection (with requires --add-opens for using reflection on the classloader, plus opening the source module so that the gwt code can see external resources), to get access to those URLs.

What I did is only one way to fix; we could also add classpath declarations to gwt (I use an annotation system that can reference maven modules for my own compiles, so I could actually get classpath without looking inside classloader).  There might also be less terrible hacks we can use once the module APIs are cemented in place.



If you really want to play with this RFN, I can push a build of my gwt fork to maven central for you to try out.  I don't really have a snapshot repo, or time to respond to bugfixes atm (though I am considering opening a gwt support shop this fall, and will "do it right" at that time).  If you are comfortable doing local installs to maven just to assess possibilities (or if you maintain your own nexus repo), I could just send you jars directly (though, that is generally a bit sketchy, imho).

Let me know; I won't have time to do a release this weekend as it is my wife's birthday, but I can fit it in if you'd like (and the comments in the G+ post aren't helpful enough).

[James Nelson]

Also, the reason gwt.xml files aren't loading sanely has to do with how resources are handled in java 9. 

You are going to have to either declare your source modules (with the gwt.xml) as `open` (no documentation for this, I found it trolling JCP forums),

or you can open your module to your gwt module (I built this with an unspeakable hack for exploration purposes) with --add-opens VM args.

If you dig into classloaders, you will discover that they will allow access to .class files from non-opened modules, but all other resources are effectively hidden unless explicitly opened.

[shital patil]

can you please share your library and i can try with that.

[James Nelson]

Hi.

I am currently very busy this week, but can try to schedule a push to maven central this weekend (I have other people waiting on it to use various other tools I dabble in as well).

Please remind me if I don't post links back here by next Monday.

Worst case scenario, I can just upload jars to github and push a gist of the pom I used, with some instructions on how to set the system properties to make it work.

I used the IDE to handle vm args, as standard maven plugins are less amenable to hacking / debugging (though I'm sure it must be possible, I did not have enough free time to get that far on it).

I'll probably update to latest java 9 spec, since the module system has undergone another iteration since I tried these hacks.

Please keep in mind, however, that my fork has diverged from mainline for quite a while, and does not undergo the same rigorous testing that you might expect.

In particular, if you start using any of the other features I've added (reflection, arbitrary magic method injection), it can break incremental recompilations.
It's a known issue I'm avoiding looking at, since most of the 2.X stack is going to go away, and I have to migrate all my magic into apt-generators to run as a pre-gwtc stage.

While I might be able to help you get something that works as a proof of concept, I would urge you to hold off on using it in production, as I am not (yet) ready to offer fulltime support.

A couple colleagues and I are playing with the idea of offering fulltime support and maintenance of 2.X around mid-September (barring a funding miracle for our current money-source).

So, please take this caveats to heart; I can probably get you up and compiling, but this should all be viewed as experimental and not-production ready for a while yet.

[Pratik Parikh]

does anyone have an update on this sissu?  I am running into the same problem, so an update would help.

[Thomas Broyer]

There have been some changes [1,2] to make it (at least partially) work with a Java 9 VM; you can try HEAD-SNAPSHOT (from https://oss.sonatype.org/content/repositories/google-snapshots/) until we release 2.8.2 with the changes.

[1] https://github.com/gwtproject/gwt/commit/87f27659af55d7d549521405ef10889e8dfe3f3a

[2] https://github.com/gwtproject/gwt/commit/5b7560c4bb6376e997981387e4f2feee1816e1dc

[Pratik Parikh]

Thank you. 

[Thomas Broyer]

Fwiw, I confirm that HEAD-SNAPSHOT works with Java 9: https://travis-ci.org/tbroyer/gwt-maven-plugin/jobs/277854932

[Dave Bradlee]

FYI. Google released a GWT update in October (http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_2) that supposed includes fixes to allow it to work with Java9. We'll be trying that soon.

[James Nelson]

If you aren't using java 9 modules, the latest release will work.  It does this by reading the classpath from System.getProperty("java.class.path"), so if you are using standard tools for creating classpath, everything should work fine.  If you are doing anything non-standard for assigning classpaths, or if you are using java 9 modules (i.e. you supply a modulepath instead of classpath), this will very likely not work for you.

Per my previous comments, my colleagues (Colin Alworth and Justin Hickman) and I did start a GWT-based services company, vertispan.com.  If you want to chat, you can send an email to sup...@vertispan.com or come chat in https://gitter.im/gwtproject/gwt  We generally help anyone for free in the public chat room, since it helps everyone to learn about fixes, but for anything requiring dedicated engineering effort, we prefer to do a support contract.

While I cannot say what the team at Google has in store for java 9 in gwt 2, I do have a prototype fix for java 9 modules on an old branch, so if you do run into trouble, feel free to post here, but you'll likely get a much faster response in gitter.  I have the jars pushed to a public-facing artifactory, and can give out coordinates if you have more exotic needs (and are willing to use coarse workarounds while a better solution is developed).  My fix resorts to reflection to access new java 9 classloader types, needs a bunch of ugly flags to open modules for reading by classloaders, and even had to unpack all of gwt-user and gwt-dev to avoid overloaded packages (no longer legal to have the same package in more than one jar in java 9).

Getting a prototype "this can work" was pretty easy, but getting it fully cleaned up with necessary modularization / refactoring is a potentially large chunk of work that could affect many files.  

So, I hope the "java.class.path" workaround works for you.  If it doesn't, come see us in gitter, or post back here (if you are ok waiting a few days for a response).