On 20/04/2017 07:43, Matej Novotny wrote:
So I did some hacking and tried to make Weld use MethodHandles.Lookup and here
is a bit of a feedback for you.
But first of all, thanks for your quick advice on how to approach this.
Thank you for writing down your experiences.
So, how did Lookup work for us?
1) privateLookupIn + drop private mode
This was the way to go, as the bean classes can be anywhere (in classes not
openly accessible to us, especially if we consider modules).
BTW I am not sure about the purpose of the private mode as you always need to
drop it to be able to use lookup.
This should work fine for existing bean classes as presumably they are
in the class path or at least not in modules that are strongly
encapsulated. In the future then if the bean classes are compiled and
deployed as modules then the owner of the module will have to open the
packages to at least the library that wants to reflect deeply.
The reason you have to drop the PRIVATE mode is because it is expected
to be used in the future. JDK-8171335 [1] and JEP 181 [2] provide some
context as how this could evolve.
2) Lookup approach carries along the need to pass the reference to the base
lookup class at all times.
This is kind of weird because in some (not-so-rare) cases, we need to create
"artificial packages" in which we place proxy classes. For instance when we
create a proxy for Interger, Map, Principal,...
Ofc we cannot place in into java.* packages, so we create our own. For this to work with
Lookup, we need to have that package created ahead of time and have a reference to some
"dummy" useless class inside to be able to do the lookup.
Or is there a way to define a whole new (open by default) package where we could place it
using Lookup? Having the "dummy" package/class just to use Lookup is lame and
very error prone (I can think of several ways to break the proxy creation even now).
What is the defining loader of the proxy class that you spin for types
such as java.lang.Integer? If it's your class loader implementation then
you can invoke its defineClass method to define the class, your don't
need a Lookup to an existing class for that scenario.
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).
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?
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).
-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
