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
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
! src/jdk.compiler/share/classes/com/sun/tools/javac
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
> 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 Annotation.annotationType() inste
On 12/08/2015 05:20 PM, 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,….);
The above reflects on the generated proxy class but not the proxy interface X.
If you did t
Right, that'd be my expectation as well. Sounds like everything works.
I will change to look at your latest webrev.
Valerie
On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
Hi Valerie,
Here is the updated webrev:
http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
Now the modular behavior f
On Tue, Dec 8, 2015 at 2:26 PM, Neil Bartlett wrote:
> 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.
>
Neil, I think you are right. That's a very good poin
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 even
> 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 as modules, I generate
>> the module-inf
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 08/1
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 generate
> a module-i
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 t
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.
! src/share/vm/classfile/classFilePar
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 t
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"
> Cc: jigsaw-dev@openjdk.java.
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
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 sou
On 08/12/2015 16:07, Stephane Epardaud wrote:
OK, so now I have Java 9 + Jigsaw load my module's main method, and in
there I need to call a class from another module by reflection. That
other module is in the module path, and I know its name and version. I
can't use the boot class loader because
> 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 have a java.lang.Cl
OK, so now I have Java 9 + Jigsaw load my module's main method, and in
there I need to call a class from another module by reflection. That
other module is in the module path, and I know its name and version. I
can't use the boot class loader because it's not on the class path (it's
on the module p
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
! src/share/vm/c
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
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 delegatio
"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
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 ge
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 modul
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 jdk.proxy1 module?
>
> Or bette
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.
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 a
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 implem
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 f
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 i
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.
Except now I have to add a read to scan annotations of another module,
which naturally introduces a cycle. This can't be right. Suppose I've a
F
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
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.prox
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/ModuleBoots
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 getting:
>
> java.lang.I
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 j
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
sho
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 experti
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 used
41 matches
Mail list logo
