setAccessible() alternative with Jigsaw - feedback on Lookup

[Remi Forax]

----- Mail original -----
> De: "Matej Novotny" <manovotn at 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