Make the ModuleDef or Active Linker Class available to all Linkers

[dankurka]

Originally reported on Google Code with ID 9088

Found in GWT Release (e.g. 2.4.0, 2.5.1, trunk): FEATURE REQUEST

Encountered on OS / Browser (e.g. WinXP, IE9, FF10): OpenSUSE 13.1 x64

Detailed description (please be as specific as possible):
Inside a "post" (non-primary) linker's link() method call, I want to behave in different
ways depending on what linker is configured as the "primary" linker.  However, this
information doesn't appear to available.

If the default linker has been overridden, that may be available as a ConfigurationProperty,
but otherwise I'd have to use GWT.getVersion() and make assumptions about the default
primary linker.

That's why passing the ModuleDef or the the results of ModuleDef.getActivePrimaryLinker()
would solve this problem.

Shortest code snippet which demonstrates issue (please indicate where
actual result differs from expected result):
Create a custom linker extending AbstractLinker and try to write a link() method for
that linker with behavior conditional upon the primary linker's class.

Workaround if you have one:
Hypothetical:
Use Java Reflection to call private static method ModuleDefLoader.tryGetLoadedModule().
 I have been warned that this may not work if the GC is under memory pressure due to
reliance on weak references, but I'm not sure this since I'd assume that strong references
exist (elsewhere) to the ModuleDef during the linking process for that module.

Links to relevant GWT Developer Forum posts:
https://groups.google.com/forum/#!topic/google-web-toolkit/4m_962SLYnk

Link to patch posted at http://gwt-review.googlesource.com

Reported by bobbitdiddle on 2014-12-29 12:52:35

[dankurka]

Just to follow up with a clarification.  Apparently, you *can't* detect a linker override
made in the module file via <add-linker>, because that doesn't show up as a ConfigurationProperty.
 Thus, there's really no way to solve this without some sort of access to ModuleDef.

Some good news, though - the proposed hypothetical workaround using reflection works
in prototype code, though I have no idea whether it will fail in a low-memory situation.
 The ultimate application is not an embedded device, so I suppose the user could just
be told to configure Java with more memory in such a situation.

Reported by bobbitdiddle on 2014-12-29 22:00:20