Fw: SWT_AWT bridge fails with IllegalAccessException in Java 1.9

Hi, The Eclipse SWT (Standard Widget Toolkit) project’s SWT_AWT bridge is broken with the Java 1.9 + Jigsaw builds and fails with java.lang.IllegalAccessException (details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318). This is caused by the encapsulation of internal classes that are

Re: Fw: SWT_AWT bridge fails with IllegalAccessException in Java 1.9

On 08/12/2015 08:13, Lakshmi P Shanmugam wrote: : I would like to request for the addition of the above internal APIs to the critical API list in JEP 260 so that are accessible for Java 1.9. Also, please provide replacement APIs for them in the future. I think this needs someone with

Re: Is there really a jdk.proxy1 module?

No cycle is a property checked at compile time not at runtime. Having cycles at runtime is not a big deal, when have cyclic class dependencies since a long time now, At compile time, it's problematic because it means that you have to compile both modules at the same time defeating the idea that

Re: Is there really a jdk.proxy1 module?

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

Re: Is there really a jdk.proxy1 module?

On 08/12/2015 14:21, Stephane Epardaud wrote: 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

Re: Is there really a jdk.proxy1 module?

No, jdk.proxy1 is a module created dynamically by the class java.lang.reflect.Proxy. Rémi - Mail original - > De: "Stephane Epardaud" > À: jigsaw-dev@openjdk.java.net > Envoyé: Mardi 8 Décembre 2015 15:21:57 > Objet: Is there really a jdk.proxy1 module? > > I'm

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

Re: Is there really a jdk.proxy1 module?

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

Re: Is there really a jdk.proxy1 module?

Thanks, that helps, and that does describe what happened to me. On 08/12/15 16:17, Alan Bateman wrote: > The accessibility of the proxy class will be determined based on the > accessibility of the proxy interfaces. If there are proxy interfaces > is non-exported packages then the proxy will get

RE: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Hi Valerie, Here is the updated webrev: http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ Now the modular behavior for the test works as per expectation through JAKE build with the following condition. If the provider jar is available under ModulePath then the "java.security" file

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

Re: Is there really a jdk.proxy1 module?

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

Re: Is there really a jdk.proxy1 module?

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

Re: Is there really a jdk.proxy1 module?

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

Re: Is there really a jdk.proxy1 module?

On 12/08/2015 03:59 PM, Stephane Epardaud wrote: Actually no, I've found that insted of accessing the proxy class directly I should just access the proxied annotation class and it works. Thanks anyway. That's right. I was about to ask you about what you are doing to require access to

Re: Is there really a jdk.proxy1 module?

"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

Re: Is there really a jdk.proxy1 module?

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" > À: jigsaw-dev@openjdk.java.net > Envoyé: Mardi 8 Décembre 2015 16:05:06 > Objet: Re: Is there really a

Re: Running module jar programatically

Oh, OK thanks a lot. Will try that and let you know. I feel I'm really close now :) On 08/12/15 17:26, Alan Bateman wrote: > Layer.boot().modules() will give you the set of jlr.Module objects for > the module in the boot layer but that is probably not what you want. > > From your mail then it

hg: jigsaw/jake/hotspot: ework -XX:+TraceModules for the unified logging framework, changed to -Xlog:modules.

Changeset: c8ba58405e6b Author:rprotacio Date: 2015-12-08 10:45 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c8ba58405e6b ework -XX:+TraceModules for the unified logging framework, changed to -Xlog:modules. ! src/share/vm/classfile/moduleEntry.cpp !

Re: Is there really a jdk.proxy1 module?

On 08/12/15 16:47, Peter Levart wrote: > 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. Apparently not, see my exception. > >> I

Re: Is there really a jdk.proxy1 module?

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

Re: Is there really a jdk.proxy1 module?

On 08/12/15 17:20, Mandy Chung wrote: > I believe your code is calling Class::getMethod on proxy class something like: > > Method m = proxy.getClass().getMethod(“Y”); > m.invoke(proxy,….); Right, it has to use reflection because it doesn't "read" the application. > The above reflects

Re: Is there really a jdk.proxy1 module?

> On Dec 8, 2015, at 7:10 AM, Stephane Epardaud wrote: > > On 08/12/15 16:07, Peter Levart wrote: >> >> >> Do you really have to addRead() ? Visibility of of classes >> (Class.forName()) should only depend on class loader delegation. >> Enumerating members, when you already

HAHA! It runs!

Finally I was able to run my Ceylon modules in Java9!! So what I have is that I generate module-info.class for every Ceylon distrib module (the bootstrap modules written in Java[1]), I made the Ceylon JVM compiler generate module-info.class for every Ceylon module, and with a few tweaks here and

Re: Is there really a jdk.proxy1 module?

It depends if you want to be able to unload the proxy class or not, If you want to unload it, you need to use your own class loader with the classloader of the annotation interface as parent. Rémi - Mail original - > De: "David M. Lloyd" > À: "Remi Forax"

hg: jigsaw/jake/hotspot: Correctly set the mirror's module field for primitives, arrays and classes defined within unnamed modules.

Changeset: 34b06d7ab75a Author:lfoltan Date: 2015-12-08 13:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/34b06d7ab75a Correctly set the mirror's module field for primitives, arrays and classes defined within unnamed modules. !

Re: HAHA! It runs!

Thanks :) TBH I would do the opposite and generate the module.xml from the module-info.java if I could, but I can't since our code should compile from Java 7 to Java 9, and module-info.java does not contain enough info for us to generate module.xml and OSGi descriptors (lacks versions) :( On

Re: HAHA! It runs!

On Tue, Dec 8, 2015 at 12:00 PM, Stephane Epardaud wrote: > Finally I was able to run my Ceylon modules in Java9!! > Congrats Stephane! > [1] ATM I can compile them with Java 9 but not as modules, I generate > the module-info.class from the JBoss Modules descriptor. I can

hg: jigsaw/jake/jdk: JVM correctly setting the module field for primitives, arrays and classes defined in unnamed module, java.lang.Class getModule can now reliably use the module field.

Changeset: cc95060fced6 Author:lfoltan Date: 2015-12-08 13:16 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cc95060fced6 JVM correctly setting the module field for primitives, arrays and classes defined in unnamed module, java.lang.Class getModule can now reliably use

Re: HAHA! It runs!

I suspect a more common approach will be to generate module-info.class directly, skipping the Java source file, since module-info.class is extensible whereas module-info.java is not. That's what I do ATM, but if we could add annotations to module-info.java, it could become extensible. I could

Re: HAHA! It runs!

> On 8 Dec 2015, at 18:39, Paul Benedict wrote: > > On Tue, Dec 8, 2015 at 12:00 PM, Stephane Epardaud wrote: > >> Finally I was able to run my Ceylon modules in Java9!! >> > > Congrats Stephane! > > >> [1] ATM I can compile them with Java 9 but not

Re: Is there really a jdk.proxy1 module?

> On Dec 8, 2015, at 2:05 PM, Peter Levart wrote: > > Hi Mandy, > > I don't think such special-casing for proxy classes is warranted and would > just complicate security-sensitive code. That was definitely a concern. Good point. Existing code should use

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Hi Siba, Here are some nits: I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. Since your provider is just an empty one, I don't think

hg: jigsaw/jake/langtools: 8133058: NPE while compiling empty javafile with -modulesourcepath option

Changeset: 8e4070f9a7ae Author:vromero Date: 2015-12-08 18:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8e4070f9a7ae 8133058: NPE while compiling empty javafile with -modulesourcepath option Reviewed-by: jjg !

Re: Fw: SWT_AWT bridge fails with IllegalAccessException in Java 1.9

On 12/08/2015 10:47 AM, Alan Bateman wrote: On 08/12/2015 08:13, Lakshmi P Shanmugam wrote: : I would like to request for the addition of the above internal APIs to the critical API list in JEP 260 so that are accessible for Java 1.9. Also, please provide replacement APIs for them in the