You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2019/06/11 09:23:08 UTC
[java 9-11] classloader based proxying?
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>
Re: [java 9-11] classloader based proxying?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Pushed through https://issues.apache.org/jira/browse/OWB-1289
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>
Le mer. 12 juin 2019 à 08:11, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Oki, will try to push a service this week.
>
> Side note: I agree on JPMS point but there is no link to jigsaw, it is
> linked to the enforced security more than modules.
>
> 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>
>
>
> Le mer. 12 juin 2019 à 07:59, Mark Struberg <st...@yahoo.de.invalid> a
> écrit :
>
>> +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.thomas@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 <
>> > rmannibucau@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
>> >>>
>> >>
>>
>>
Re: [java 9-11] classloader based proxying?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok for the JPMS point
- java.lang.reflect.AccessibleObject#logIfOpenedForIllegalAccess, can mean
we need to document the --add-opens too?
About OSGi, I think it should work but also not sure it should be used
since the OSGi classloaders have another specific API which abstracts the
classloader itself.
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>
Le mer. 12 juin 2019 à 10:24, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> the 'enforced' security is a side effect of the modules. It's a half baked
> OSGi.
> Btw, does your hack also work on OSGi?
> Have not looked at the commit yet due to time constraints :(
>
> LieGrue,
> strub
>
>
> > Am 12.06.2019 um 08:11 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Oki, will try to push a service this week.
> >
> > Side note: I agree on JPMS point but there is no link to jigsaw, it is
> > linked to the enforced security more than modules.
> >
> > 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
> >
> >
> >
> > Le mer. 12 juin 2019 à 07:59, Mark Struberg <st...@yahoo.de.invalid>
> a
> > écrit :
> >
> >> +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.thomas@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 <
> >>> rmannibucau@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
> >>>>>
> >>>>
> >>
> >>
>
>
Re: [java 9-11] classloader based proxying?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
the 'enforced' security is a side effect of the modules. It's a half baked OSGi.
Btw, does your hack also work on OSGi?
Have not looked at the commit yet due to time constraints :(
LieGrue,
strub
> Am 12.06.2019 um 08:11 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Oki, will try to push a service this week.
>
> Side note: I agree on JPMS point but there is no link to jigsaw, it is
> linked to the enforced security more than modules.
>
> 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>
>
>
> Le mer. 12 juin 2019 à 07:59, Mark Struberg <st...@yahoo.de.invalid> a
> écrit :
>
>> +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.thomas@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 <
>>> rmannibucau@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
>>>>>
>>>>
>>
>>
Re: [java 9-11] classloader based proxying?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Oki, will try to push a service this week.
Side note: I agree on JPMS point but there is no link to jigsaw, it is
linked to the enforced security more than modules.
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>
Le mer. 12 juin 2019 à 07:59, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> +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.thomas@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 <
> > rmannibucau@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
> >>>
> >>
>
>
Re: [java 9-11] classloader based proxying?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
+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 <an...@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 <
> rmannibucau@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
>>>
>>
Re: [java 9-11] classloader based proxying?
Posted by Thomas Andraschko <an...@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 <
rmannibucau@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
> >
>