FTR, about mapping the module name to Maven group/artifact, Ceylon
modules are getting optional group/artifact descriptors in their module
descriptors too, because keeping a sane mapping between Maven and Ceylon
modules was too hard otherwise.
Similarly we now store the group/artifact IDs in JBoss
I don't think public ever meant "public to the world". In Java 1->8 it
means "visible to those who can see the containing scope". If you
declare a public inner class in a private (or package-private) class,
then those who cannot access the outer type also cannot access the
public inner class.
So how about a Java Language annotation (say, @RequiresExport) that we
could place on IoC framework annotation definitions (say, @Entity, from
JPA) that would tell the compiler that any type annotated with @Entity
must be exported?
That would solve the issue of making sure that users would not
Agreed, and this is the conclusion we came to in Ceylon wrt modules too.
But that's orthogonal to the format of the module descriptor.
I think the Java Modules already have a lot of overriding capabilities
in the form of command-line flags (-addExports and friends), but
ultimately an external
or hard. I don't think
module-info.class changes that much.
On 11/05/16 16:44, David M. Lloyd wrote:
On 05/11/2016 09:21 AM, Stephane Epardaud wrote:
I don't understand the problem with the module-info.java class. We also
repackage jars to add module descriptors (for OSGi, Maven and JBoss
I don't understand the problem with the module-info.java class. We also
repackage jars to add module descriptors (for OSGi, Maven and JBoss
Modules) and for Jigsaw we generate the `module-info.class` file when we
need to repackage them. Between this binary format and XML or
MANIFEST.MF, I don't
oxy2 does not export com.sun.proxy.jdk.proxy2”.
Regards,
Neil
On 7 Apr 2016, at 13:13, Stephane Epardaud wrote:
IIRC RestEasy needs to add a module read to that Class's module it wants to
create a Proxy of.
On 07/04/16 14:05, Alan Bateman wrote:
On 07/04/2016 12:39, Dawid Weiss wrote:
I don't w
IIRC RestEasy needs to add a module read to that Class's module it wants
to create a Proxy of.
On 07/04/16 14:05, Alan Bateman wrote:
On 07/04/2016 12:39, Dawid Weiss wrote:
I don't want to hijack the other thread, so here's a new one I'm stuck
with. I get this exception (simplified stack trac
On 18/01/16 17:28, Paul Sandoz wrote:
> Assuming the JodaTime library is not publicly exported (types in the
> dependent API) and used in a manner that is amenable to maintaining
> separate classes then i guess it (and it’s dependencies) would have
> tag along with a "one unit, one set of depende
Hi,
Well, I can think of at least one use-case where a JDK10 version of a
module would have different dependencies than JDK9: if the module used
an external lib for X in JDK9, and then JDK10 incorporated that
functionality X so that import would no longer be required but the
module would then impo
Hi,
I've summed up the work I did on making Ceylon modules compile and run
on Java 9 here: http://ceylon-lang.org/blog/2015/12/17/java9-jigsaw/
Feel free to give it a try :)
Cheers and thanks for the help!
As I already mentioned, we also have the need for this in Ceylon, for
the same reasons. Dependencies are required at compile-time but optional
at run-time, based on detection: if it's there fine, if not then no problem.
On 08/12/15 23:32, Mandy Chung wrote:
> Good point. Existing code should use Annotation.annotationType()
> instead of Annotation.getClass(). Annotation is an interface. Calling
> annotation.getClass() will only return the implementation class that
> may be encapsulated and not exported to the cal
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 08/12/15 19:39, Paul Benedict wrote:
> On Tue, Dec 8, 2015 at 12:00 PM, Stephane Epardaud <mailto:s...@epardaud.fr>> wrote:
>
> Finally I was able to run my Ceylon modules in Java9!!
>
>
> Congrats Stephane!
>
>
> [1] ATM I can compile them w
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
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
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
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
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/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.
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
hough, 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"
>
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
FTR I have nothing against it being module-info.class. As far as Ceylon
is concerned, that or MANIFEST.MF are both fine.
What concerns me far more is that it's not self-sufficient since I have
to recombine it with another source (OSGi or Maven metadata) to get
version numbers and optional imports.
Hi,
When there is a -modulepath argument, is it a path in the Unix sense?
With a list of File.pathSeparator-separated folders?
Ceylon produces `.car` files instead of `.jar` files, but they're really
zip files like jars. Will Java examine the file type to determine that
it's a zip file, or will i
I was THIS close to running Ceylon modules with Java 9:
atlantis stephane 18:04 compiler-java $
$HOME/no-backup/src/jdk1.9.0-jigsaw/bin/java -modulepath mlib -m
com.redhat.ceylon.compiler.java.test.interop.java9.user
Error occurred during initialization of VM
java.lang.module.ResolutionException:
Syntactic detail, but if you use "import" instead of "requires" then
"import optional" or "import public" both make sense ;)
On 04/12/2015 15:21, David M. Lloyd wrote:
IIRC there is *already* within Java 9 an option to compile against
previous JDK ABIs (which are bundled with JDK 9), isn't there?
Ah that's interesting, I got hit by calls to byteBuffer(int) which
compiled in JDK9 to ByteBuffer.position(int) which
9 yet :( [not interested in IDE
suggestions or any IDE flame war].
On 02/12/15 16:24, Stephane Epardaud wrote:
> Hi,
>
> I have a modular jar produced by Java 9 EA + Jigsaw, I can run it with
> "java -mp mlib -m my.module", but how can I run it programmatically in Java?
>
>
A bit off-topic, but I wanted to clarify something, in case my many
questions sound negative:
I think you guys have done a tremendous job with Jigsaw, and IMO the
hardest is behind you, I can see there was a huge amount of work (well,
you started it in Java 7…) to get to his point, and I feel that
Hi,
I have a modular jar produced by Java 9 EA + Jigsaw, I can run it with
"java -mp mlib -m my.module", but how can I run it programmatically in Java?
ATM I'm using URLClassLoader to load it and run it, but I _think_ it
does not make it "modular" and the module package visibility checks are
turn
On 02/12/15 14:56, Alan Bateman wrote:
> The this_class should be /module-info but in any case,
The funny thing is that this module-info.class was created by the Java
9+Jigsaw EA "stock" javac. How it got the ".Test" class mixed up in
there is not clear to me. Perhaps as a result of me specifyi
Just tried it and got:
Exception in thread "main" java.lang.ClassFormatError: Illegal class
name "com.ceylon.java9.Test" in class file module-info
at java.lang.ClassLoader.defineClass1(java.base@9.0/Native Method)
at java.lang.ClassLoader.defineClass(java.base@9.0/ClassLoader.java:854)
On 01/12/15 22:04, Alex Buckley wrote:
> There shouldn't be any surprise here. In Java SE 8, you can declare a
> package-private annotation type and use it to write annotations on
> public classes of that package. Going up a level in Java SE 9, you can
> declare a module-private annotation type (
On 30/11/15 17:14, Alan Bateman wrote:
> I assume you mean it can't access the types in
> sun.reflection.annotation rather than can't see them. In any case, it
> is a shame that there are types here that are used in annotation
> serialization. You can workaround it by using -XaddExports, document
Hi,
I'm using reflection to walk classes and methods, and walking
java.lang.Object.hashCode() I get an annotation of type
jdk.internal.HotSpotIntrinsicCandidate, which does not appear to be
exported by java.base (it exports jdk but not jdk.internal). Is that
intentional? I would have thought that
Well… turns out we were using it :(
We have a weird situation with Ceylon which is that we include a forked
javac (based on 1.7 with backports from 1.8), along with
javax.lang.model, which allow us to both compile and run in Java 7 and
Java 8. And we use the bootclasspath to tell the JVM to use ou
OK thanks a lot for all these answers, it's much clearer for me now :)
Hi,
I work on Ceylon, a JVM language, using a fork of javac 7 with backports
from javac 8, and currently trying to see how to make it work with Java
9, which is interesting in our case as Ceylon already has modularity and
adopted the JDK modularisation (as it was planned in Jigsaw) since Java 7.
41 matches
Mail list logo
