GWT Super-source location

[shauntarves]

I am having a problem with 25.0-jre since 38d2f3296b722e7d84a01d31037e31fade13951c, which super-sourced the nullToEmpty, emptyToNull, and others.

When running in super dev mode with the gwt-maven-plugin (https://tbroyer.github.io/gwt-maven-plugin), the Platform class is only on the runtime classpath (sourcemaps) under com/google/common/base/super/com/google/common/base. I'm not entirely sure what value needs to be modified to relocate the super sources. My module that inherits Guava has its own super-source folder and classes because I'm emulating jre.util.UUID.

[cpovirk]

Thanks for the report. I am in over my head here, but some thoughts:

• We do define a Base.gwt.xml that points to the super directory. I'm seeing it in the gwt jar, as expected, and it works OK in the tests in guava-gwt itself.
• I see that gwt-maven-plugin has some ways of adding super-source. But I don't know much about that. It's different than what we do, probably in part because we use the old gwt-maven-plugin. It's possible that the interaction of old and new plugins is part of the problem. But if it's just plain JSNI, that seems like less of a plugin thing and more of a general GWT thing.
• I take it that the methods outright don't work for you? Like, it's not just that Chrome shows an error but still works?
• Do you know whether our other super-sources have worked OK for you? Like, in past Guava releases, does Stopwatch.createUnstarted().elapsed(SECONDS) work? How about Stopwatch.createUnstarted().toString(), which uses JsInterop in a different way?
• Internally, we have a js file that contains JsInterop code in addition to the inline JSNI in Platform.java. Maybe GWT is looking for that rather than the JSNI for some reason, perhaps related to Super Dev Mode? My understanding was that GWT uses JSNI and that the JsInterop is more for J2CL. But maybe it could help to release the js file, possibly in combination with something like jsinterop-base??
• If we can't get this straightened out easily some other way, one thing we could try is to replace the GWT Platform.java with the "normal" Platform.java. The GWT version is just an optimization, which we could keep internally but back out if it's causing problems here.

[shauntarves]

Hi @cpovirk , I'll try to respond to each point while adding the pertinent information:

The super-sourced Platform.java file is definitely making into the jar AND my sources (according to the Chrome sourcemaps listing).

The issue seems to be the pathing, not the presence. Given that the sourcemaps show it located at super/com/google/common/base/Platform.java instead of just as Platform.java within the com/google/common/base path, Strings.java essentially can't find it because it's only looking within the same "package".

The methods definitely straight-up don't work. That uncaught reference is essentially a null pointer exception, which halts everything else.

I don't think I've ever hit called any of your other super-sourced methods, but I do see the same pathing behavior with super-sourced classes like those in the collect or math packages. They all get that extra super/com/xxxxx path. I wouldn't expect any of them to work, but I've been lucky to not be using them I guess.

Ultimately, I think the issue is around the relocation of super-sourced files. They should be getting all that extra pathing stripped off. That might fall into the realm of the maven plugin rather than Guava itself if your code works with the older plugin.

[cpovirk]

The relocation theory sounds reasonable to me.

When you say...

My module that inherits Guava

...you mean that your .gwt.xml has something like...

<inherits name="com.google.common.base.Base"/>

...right?

[shauntarves]

Yes...sorry if that wasn't clear.

To add even more fun to this, I only see the issue when running in superdev mode. The standard compile and optimization process looks to be doing the right thing.

On Wed, May 23, 2018 at 12:01 PM Chris Povirk notifications@github.com wrote:

The relocation theory sounds reasonable to me.

When you say...

My module that inherits Guava

...you mean that your .gwt.xml has something like...

...right?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/guava/issues/3153#issuecomment-391401693, or mute the thread https://github.com/notifications/unsubscribe-auth/AEgwsATlgfDVvpxlHdOSIevJ00g-FldVks5t1YfkgaJpZM4UJRXv .

[cpovirk]

Thanks, I figured but wanted to be sure.

Searching around, I saw https://groups.google.com/d/topic/google-web-toolkit/Qi5btTMre5s/discussion, which sounds similar but didn't reach any conclusion :\

I don't know how well tested Guava is with Super Dev Mode. I would have assumed that we'd have heard of problems internally, but maybe the JsInterop code is important or something.

I'll try to dig some more.

[cpovirk]

I did find a suggestion of using -noincremental, though of course you shouldn't have to. And the thread above suggested -style PRETTY (ditto). I've found some other threads that suggest that unusual GWT linkers can cause problems unless you do special handling. I don't know what you're using or whether it's easy for you to test with a different one.

[cpovirk]

(Also "clear the caches"... :\ )

[cpovirk]

I see https://github.com/tbroyer/gwt-maven-plugin/issues/111 that suggested that GWT itself is responsible. I'll try to keep an eye out for anything you file against them.

One other thought: Is --generateJsInteropExports necessary here -- on guava-gwt or on your project?

[cpovirk]

(Setting <generateJsInteropExports> in the guava-gwt gwt-maven-plugin compile configuration has no effect on the output jar. But I don't know if it affects downstream projects somehow.)