+1 if it is switchable to the old mechanism.
When loading the proxy class in a different classloader you cannot access any
protected or package scoped methods as it is basically treated as 'outside'. A
package - even if it has the same package name - is only treated the same if it
is loaded by the very same ClassLoader. Different CL, different package so to
say.
Plus: Jigsaw doesn't deliver. The adoption rate is sub-stelar. If not to say
crappy. And for a reason. It doesn't add much benefit from a security pot.
Especially when compared to the costs. Reminds me a bit to SecurityManager.
Sounds nice in theory, but is a performance hog and not easy to get safe. So
almost nobody is using it. I guess the same will happen to Jigsaw.
LieGrue,
Strub
> Am 11.06.2019 um 12:37 schrieb Thomas Andraschko
> <andraschko.tho...@gmail.com>:
>
> hmmm
> basically +1 if we can solve the protected/package scoping by a fallback
>
> lets wait about mark's opinion?
>
> Am Di., 11. Juni 2019 um 11:23 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
>> Hi guys,
>>
>> Do we want to add an option to switch to a classloader based proxy
>> definition?
>>
>> Idea is that instead of using reflection or unsafe to define our proxies we
>> create a class loader - likely in WebBeansContext and shared accross all
>> AbstractProxyFactories. It looks like (ignore the visibility, I took it
>> from a poc as a nested class):
>>
>> private static class InternalClassLoader extends ClassLoader {
>> private final ConcurrentMap<String, Class<?>> classes = new
>> ConcurrentHashMap<>();
>>
>> private InternalClassLoader(final ClassLoader applicationClassLoader) {
>> super(applicationClassLoader);
>> }
>>
>>
>> @Override
>> protected Class<?> loadClass(final String name, final boolean
>> resolve) throws ClassNotFoundException {
>> final Class<?> clazz = classes.get(name);
>> if (clazz == null) {
>> return getParent().loadClass(name);
>> }
>> return clazz;
>> }
>>
>> private Class<?> getOrRegister(final String proxyClassName, final
>> byte[] proxyBytes) {
>> return classes.computeIfAbsent(
>> proxyClassName.replace('/', '.'),
>> n -> {
>> final Class<?> defined =
>> super.defineClass(proxyClassName, proxyBytes, 0, proxyBytes.length);
>> resolveClass(defined);
>> return defined;
>> });
>> }
>> }
>>
>>
>> Then AbstractProxyFactory would make getProxyClass behaving as - assuming
>> we have proxies the instance of this classloader:
>>
>> return proxies;.
>>
>> I suspect it can need to use that classloader instead of TCCL for
>> deserialization but it is not a big deal too.
>>
>> The big advantage is to work on java >= 9 without warning (WARNING: Illegal
>> reflective access ) but it has a disavantage to not support
>> protected/package scope proxying (since we use 2 classloaders).
>>
>> If we want to be clever we could use both strategies at the same time, i.e.
>> if we can proxy through this classloader then we do, otherwise we keep
>> current impl.
>>
>> Any opinion? i'd really like to have a clean run on java 11 for 2.0.12 or
>> 2.0.13, even if we must add a few limitations like this visibility thing.
>>
>> wdyt?
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>
>>
