Is there really a jdk.proxy1 module?

[Peter Levart]

Hi Stephane,

On 12/08/2015 04:10 PM, Stephane Epardaud wrote:
>
> On 08/12/15 16:07, Peter Levart wrote:
>>> Except now I have to add a read to scan annotations of another module,
>> Do you really have to addRead() ? Visibility of of classes
>> (Class.forName()) should only depend on class loader delegation.
>> Enumerating members, when you already have a java.lang.Class object
>> likewise. Looking-up annotations likewise.
>>
>> What exactly are you trying to do and what exception do you get?
> I have a scanner that can scan annotations of type X (by name) and
> member Y (by name) so it must use reflection to load the annotation and
> member.

You can do that without readability of the target module.

> I got that when accessing the annotation's member Method:

Ok, for invoking the method on annotation interface, you need 
readability of the target module. That's it, yes.

>
>
> java.lang.IllegalAccessException: class
> com.redhat.ceylon.model.loader.impl.reflect.mirror.ReflectionAnnotation
> (in module com.redhat.ceylon.model) cannot access interface
> com.redhat.ceylon.compiler.java.metadata.Module (in module
> ceylon.language) because module ceylon.language does not export package
> com.redhat.ceylon.compiler.java.metadata to module com.redhat.ceylon.model
>      at
> sun.reflect.Reflection.throwIllegalAccessException(java.base at 9.0/Reflection.java:455)
>      at
> sun.reflect.Reflection.ensureMemberAccess(java.base at 9.0/Reflection.java:130)
>      at
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(java.base at 9.0/AccessibleObject.java:370)
>      at
> java.lang.reflect.AccessibleObject.checkAccess(java.base at 9.0/AccessibleObject.java:362)
>      at java.lang.reflect.Method.invoke(java.base at 9.0/Method.java:525)
>
>> Cycles are checked only when constructing a Layer. Later, they are not
>> any more. The problem with cycles is mainly in compile-time as I
>> understand.
> Well, they're not really a problem at all at compile-time, not any more
> than Class cycles are a problem, in the sense that the workaround is
> simple: compile them at the same time. But OK, at least I can solve my
> issue by introducing cycles at runtime.

Right, this is controversial. Some would say that when you have two 
modules that depend on each other, none of them can exist without the 
other, so why the split? At least one direction of the bi-directional 
dependency should be "optional" then.

Regards, Peter