----- Mail original ----- > De: "Matej Novotny" <manov...@redhat.com>
> Hi, > > thanks for your time. Comments inline. > [...] >> >> If you are looking to define a class in a new runtime package and the >> class loader that is not your implementation then you are out of luck. >> Lookup is designed for doing computations in the context of an existing >> class. There is a note in the archives here from John Rose about >> extending the lookup API for cases like this but it would come with a >> lot of complexity. Also there isn't any notion of adding a package to a >> named module at this time. When java.lang.reflect.Proxy spins proxy >> classes then it doesn't add packages to named modules, it instead spins >> the proxy classes into its own module (something you could do too, >> assuming the classes that you are proxying are accessible). > > I think it's more or less what we did/are doing - we spin the proxies either > into the same package the came from or to our own package/module. > But in order to avoid proxy name clash in the same package, we just took the > original package and replaced the prefix 'java' with something like > 'org.jboss.weld.proxies'. > This effectively means that 'java.util.Map' proxy will end up as something > like > 'org.jboss.weld.proxies.util.Map$Proxy'. > Obviously, 'org.jboss.weld.proxies.util' did not exist beforehand and putting > everything into one existing package using Lookup is bound to blow up very > quickly. > So there is basically no way to achieve this with JDK 9? You can spin one module per package, by creating one ModuleLayer per package, not unlike j.l.r.Proxy does. Rémi > >> >> > >> > 3) All in all the changes carried along a lot of complexity compared to >> > plain old ClassLoader.defineClass >> > We need to create A LOT of Lookups (might present performance overhead, >> > haven't tested yet). >> > Extra care needs to be given to the packages for Lookup not to blow up >> > while we in fact don't really care where the proxy lands as long as it is >> > usable. >> Can you expand on the "don't really care" comment? Do you mean that you >> don't care about either the defining loader or runtime package? > > I was referring to the runtime package. > What we need is to ensure that there won't be a clash - there can be two > classes > with same name and different packages, which, for some reason, will have to > land in a package created by us. > If this happened and we were using a fixed existing package to place them in, > it > would blow up. > So what I meant was that with JDK 8 I don't need to care for this, I just use > prefix and I am done with it. In JDK 9, this seems like quite an obstacle. > >> >> > >> > >> > Another nasty thing is that the code of course needs to work with both, JDK >> > 9 and 8. >> > While it isn't impossible, it will add a not-so-nice reflection magic layer >> > to the mix. >> > >> Multi-release JARs (JEP 238 [3]) and the ability to compile to older >> releases (JEP 247 [4]) might be useful here (you might know about these >> features already). > > Haven't really explored this yet, it might be a way. > Gotta see how Maven deals with this feature to allow us to create MRJARs in a > reasonable manner. > > Matej > >> >> -Alan. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8171335 >> [2] http://openjdk.java.net/jeps/181 >> [3] http://openjdk.java.net/jeps/238 >> [4] http://openjdk.java.net/jeps/247
