"Usually used" by whom? You cannot create a proxy class in a class
loader that cannot "see" the interfaces it implements, so if those
interfaces are in modules, and you choose some arbitrary parent class
loader (leaving aside the sore-thumb question of: why would there even
*be* a parent class loader besides the boostrap one in a module), the
proxy would not be able to be defined due to NoClassDefFoundError
because the proxy class wouldn't be able to link against the interface
it implements.
On 12/08/2015 09:16 AM, Remi Forax wrote:
No,
because the class loader that is usually used is not the module class loader
but one of its parent.
Rémi
----- Mail original -----
De: "David M. Lloyd" <david.ll...@redhat.com>
À: jigsaw-dev@openjdk.java.net
Envoyé: Mardi 8 Décembre 2015 16:05:06
Objet: Re: Is there really a jdk.proxy1 module?
Or better yet, to the module defining the proxy interface(s)... of
course, then you must ensure that they all are from the same module.
This is another area where having per-module class loaders is superior:
the getProxyClass()/newProxyInstance() methods already expect a class
loader for the first argument, so you can select a module which has
visibility to all the interfaces if so desired.
On 12/08/2015 09:02 AM, Rafael Winterhalter wrote:
What is the advantage of adding runtime generated classes to a specific
named module? If all generated classes are collected in a single module,
this module does not have a meaningful readability scope. If enough
interfaces are proxied, the proxy module will converge to full read access,
wouldn't it?
Why not add such proxy classes to a class loader's unnamed module?
2015-12-08 15:52 GMT+01:00 Sundararajan Athijegannathan <
sundararajan.athijegannat...@oracle.com>:
addRead -> addReads
-Sundar
On 12/8/2015 8:20 PM, Sundararajan Athijegannathan wrote:
Because jdk.proxy1 is a dynamically created module, you've to
programmatically add read using java.lang.reflect.Module (addRead method)
API.
-Sundar
On 12/8/2015 8:11 PM, Stephane Epardaud wrote:
Except I can't add reads to it:
$HOME/no-backup/src/jdk1.9.0-jigsaw/bin/java
-XaddReads:jdk.proxy1=com.redhat.ceylon.model ...
Error occurred during initialization of VM
java.lang.RuntimeException: Unknown module: jdk.proxy1
at
jdk.internal.module.ModuleBootstrap.fail(java.base@9.0/ModuleBootstrap.java:394)
at
jdk.internal.module.ModuleBootstrap.addMoreReads(java.base@9.0/ModuleBootstrap.java:319)
at
jdk.internal.module.ModuleBootstrap.boot(java.base@9.0/ModuleBootstrap.java:229)
at java.lang.System.initPhase2(java.base@9.0/System.java:1263)
That must be a mistake though, otherwise I can't use reflection to read
annotations…
On 08/12/15 15:32, Remi Forax wrote:
No,
jdk.proxy1 is a module created dynamically by the class
java.lang.reflect.Proxy.
Rémi
----- Mail original -----
De: "Stephane Epardaud" <s...@epardaud.fr>
À: jigsaw-dev@openjdk.java.net
Envoyé: Mardi 8 Décembre 2015 15:21:57
Objet: Is there really a jdk.proxy1 module?
I'm getting:
java.lang.IllegalAccessException: class
com.redhat.ceylon.model.loader.impl.reflect.mirror.ReflectionAnnotation
(in module com.redhat.ceylon.model) cannot access class
com.sun.proxy.jdk.proxy1.$Proxy3 (in module jdk.proxy1) because module
com.redhat.ceylon.model does not read module jdk.proxy1
When using reflection to load annotations. Is there really a
"jdk.proxy1" module I need to import when doing reflection? Sounds
fishy, no?
Cheers.
--
- DML
--
- DML
