Maybe I'm missing something, but looking at the code briefly, I see that StandardLinkerContext()'s constructor takes the ModuleDef, and the ModuleDef is passed around throughout the linking process, so I'm guessing a strong reference to the ModuleDef would persist throughout the linking process, thus ensuring it didn't get removed from the table in ModuleDefLoader. Isn't the ModuleDef needed during the linking process? On Sunday, December 28, 2014 5:59:30 PM UTC-6, Jens wrote: > > What if someone has written a custom primary linker that is unknown to > you? Would your linker still work? Basically you might not be able assume > that one of the linkers that are shipped with GWT are actually used by an > app. > > Maybe it is a better approach to create a sane abstract class of your > non-primary linker and then provide matching sub classes for all primary > linkers GWT provides. Then the developer must add the correct non-primary > linker of yours that matches their primary linker or have to sub class your > abstract linker. > > Not sure if your reflection "hack" will work. Although the method in > question is static and might be callable through reflection it only > operates on a cache which uses weak references. Thus the data you need > might not be in the cache anymore if the JVM has memory pressure and has > GC'd some cache contents between module parsing/compilation and finally > linking. I would not use that approach. > > Maybe it is worth creating a feature request so that LinkerContext has > more information about the primary linker in the future. > > -- J. >
-- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
