Re: Re: is ClassLoader.loadClass() supposed to work on module-info classes?

To add a bit of perspective from the build tool side (disclaimer, I'm on the Gradle team), what we do today is that we rely on our model of exports, which basically follows the Jigsaw one, to generate different artifacts depending on the target JDK. This has several consequences: - our model can

hg: jigsaw/jake/jdk: Configuration.empty().reads(...) throws NPE

Changeset: e9c02ef97b43 Author:alanb Date: 2015-12-04 08:12 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e9c02ef97b43 Configuration.empty().reads(...) throws NPE ! src/java.base/share/classes/java/lang/module/Configuration.java !

Aw: Re: is ClassLoader.loadClass() supposed to work on module-info classes?

since the world does not only consist of java and javac and since there are many more bytecode files producing languages out there, I expect multiple such tools working on the bytecode plus language based tools, for those that want to support strong encapsulation at runtime. > Gesendet:

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 04/12/2015 08:22, Cédric Champeau wrote: Obviously compiling a single JDK 9 module-info file seems pretty cheap, but if you think about the fact that you will want to have a JDK 8 installed to compile your classes, plus a JDK 9 Jigsaw installed to compile the descriptor, and then add that

Re: The rationale for runtime modularization

Hi Mark, thank you for your answer. I am glad to hear that the feedback is taken into serious consideration. Here is however one point I disagree with: Maven does not offer compile-time moduarization. Maven only assures that all dependencies are in scope but it does not offer any means to cut

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

Hi, On Fri, Dec 4, 2015 at 4:33 AM, Alex Buckley wrote: > On 12/3/2015 4:47 AM, David M. Lloyd wrote: > > If you're splitting or merging modules -- especially someone else's! -- > then you need to let the compiler check that the newly factored modules are > well-formed:

RE: The rationale for runtime modularization

Since "you're definitely going to look into ways to address that", I would like to send a bit of personal opinion. The module encapsulation sounds like access modifier, but non-public member can be accessed through reflection, so it looks more like accessClassInPackage barrier of security

Aw: Re: The rationale for runtime modularization

> Gesendet: Freitag, 04. Dezember 2015 um 10:43 Uhr [...] > Here is however one point I disagree with: Maven does not offer > compile-time moduarization. Maven only assures that all dependencies are in > scope but it does not offer any means to cut down this dependency tree to > the set of

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

Hi, On Fri, Dec 4, 2015 at 2:06 AM, Alex Buckley wrote: > When the author of B decided to shade A, it became B's responsibility to > configure the readability needed by A's reflective code. > In other word, after shading we don't have module A in play but one big module

hg: jigsaw/jake: Made error message for --with-import-modules a little bit better

Changeset: f204b6d539cb Author:erikj Date: 2015-12-04 12:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f204b6d539cb Made error message for --with-import-modules a little bit better ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4

Re: RFE support jar as modulepath argument

On 03/12/2015 19:49, Robert Scholte wrote: After reading the specs it seems like I can only refer to a directory containing modules. For a dependency specified in the pom.xml I could refer to the directory (within the local repository) containing that specific artifact. However, such

Re: RFE support jar as modulepath argument

Hi, On Fri, Dec 4, 2015 at 3:33 PM, Alan Bateman wrote: > > On 03/12/2015 19:49, Robert Scholte wrote: > >> >> > I think *-tests.jar brings many discussion points and maybe something for > another thread. In brief, if the tests are in their own package hierarchy, > not

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/04/2015 09:18 AM, Alan Bateman wrote: On 04/12/2015 12:59, David M. Lloyd wrote: So you're saying that if I have C depending on A, then update A or I split A and B in my distribution, I need to recompile C? I don't think that's a realistic proposition. Do I then have to recompile

Re: RFE support jar as modulepath argument

Hi, On Fri, Dec 4, 2015 at 5:12 PM, Alan Bateman wrote: > > On 04/12/2015 12:27, Ali Ebrahimi wrote: > > > Just as I said in another thread post: > > If we have module group concept and modules belong to same module group > loaded by same classloader then we can support

Re: Feature complete?

On 12/04/2015 09:48 AM, Alan Bateman wrote: On 04/12/2015 13:50, Reinier Zwitserloot wrote: : Emphasis mine: "only"? "Just add some command line switches" is not exactly a nice solution. From personal experience, the vast majority of java users do not know how to add configure command line

RE: Feature complete?

I have come to a similar concern about command line options. First, it won't be acceptable for customers to change their scripts that say 'java myjavacommand'. The best that I have come up with so far is to hide JDK9 command line options in _JAVA_OPTIONS (it's likely that things will still need

Re: JVMTI and instrumentation

On 03/12/2015 15:12, Michael Rasmussen wrote: : As seen, the value of jdk.boot.class.path.append is the sun.boot.class.path from the index that was the original value before I changed it. I looked into this a bit further and I do see an issue when Agent_OnLoad changes

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 04/12/2015 12:59, David M. Lloyd wrote: So you're saying that if I have C depending on A, then update A or I split A and B in my distribution, I need to recompile C? I don't think that's a realistic proposition. Do I then have to recompile things that depend on C? Or things that

Re: RFE support jar as modulepath argument

On 04/12/2015 12:27, Ali Ebrahimi wrote: Just as I said in another thread post: If we have module group concept and modules belong to same module group loaded by same classloader then we can support splited packages. This way each module group maps to each classloader. This will support

Re: Feature complete?

On Tue, Dec 1, 2015 at 2:24 PM, Alan Bateman wrote: > This seems a bit pessimistic. One thing that would be helpful is to get > more help testing of these libraries with the EA builds. If there are > libraries and applications on the class path today that are using core

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/04/2015 09:41 AM, Alan Bateman wrote: On 04/12/2015 08:22, Cédric Champeau wrote: Obviously compiling a single JDK 9 module-info file seems pretty cheap, but if you think about the fact that you will want to have a JDK 8 installed to compile your classes, plus a JDK 9 Jigsaw

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/04/2015 08:18 AM, Cédric Champeau wrote: Just a related question: Do you expect the class file format to change in JDK9 and for what features? If it is only for supporting the module-info.class then would something like the following be possible: javac -source 9 -target 8 -mp modlib

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/04/2015 06:33 AM, Stephane Epardaud wrote: 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

Re: The rationale for runtime modularization

On 12/03/2015 06:19 PM, mark.reinh...@oracle.com wrote: 2015/12/3 1:36 -0800, Rafael Winterhalter : I am writing this after looking into Jigsaw for about two months and after running my open-source libraries and several enterprise applications of my current employer using

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

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

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/03/2015 07:03 PM, Alex Buckley wrote: On 12/3/2015 4:47 AM, David M. Lloyd wrote: On 12/02/2015 04:49 PM, Alex Buckley wrote: Now we reach the disagreement. We don't think the module declaration will be as fluid as you do. Yes, frameworks and other tools will want to modify module

Re: Optional dependencies

Perhaps just 'optional module module.name;' ? --Reinier Zwitserloot On Tue, Dec 1, 2015 at 9:48 PM, Paul Benedict wrote: > There is certain irony in seeing "requires optional" :-) Two contradictory > terms side-by-side. > > Cheers, > Paul > > On Tue, Dec 1, 2015 at 2:40

Re: Optional dependencies

Hi, On Fri, Dec 4, 2015 at 8:23 PM, Stephen Colebourne wrote: > I've been pondering whether -addReads is sufficient for this use case. > > While type 1 of my classification below (annotations) would work using > compile-time -addReads, I don't think types 2 and 3 would.

Re: Optional dependencies

I've been pondering whether -addReads is sufficient for this use case. While type 1 of my classification below (annotations) would work using compile-time -addReads, I don't think types 2 and 3 would. (Type 2 is reflection based, type 3 is usage based) Here is the setup: module user {

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 04/12/2015 15:52, David M. Lloyd wrote: Ah, yeah specifically I'm referring to splitting/merging or upgrading some given module in an existing system, possibly using aggregate modules for compatibility or alternatively updating the module descriptors of existing installed modules to

Re: The rationale for runtime modularization

2015/12/4 6:55 -0800, rein...@zwitserloot.com: > On Fri, Dec 4, 2015 at 1:19 AM, wrote: >> Strong encapsulation at run time greatly improves both >> * security* and maintainability. (Strong encapsulation at compile time >> makes it much easier to prepare for strong

-Xpatch with jar, jimage, or other non-exploded format?

The usage of -Xpatch is to be a replacement for -Xbootclasspath/p, to enable to patch boot CP classes, but at the moment it only seems to support pointing to an "exploded" directory, containing the individual .class files. Are there any plans to extend this to also support some kind of container

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/04/2015 03:37 PM, Jonathan Gibbons wrote: On 12/04/2015 06:33 AM, Stephane Epardaud wrote: 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

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

- Mail original - > De: "Alex Buckley" > À: jigsaw-dev@openjdk.java.net > Envoyé: Samedi 5 Décembre 2015 00:09:16 > Objet: Re: is ClassLoader.loadClass() supposed to work on module-info classes? > > On 12/4/2015 11:58 AM, Peter Levart wrote: > > I know about

Re: Feature complete?

This is backwards though: instead of saying "these modules can have some elevated privilege", which BTW is (in a way) the inverse of using a security manager to restrict permissions, doesn't it make more sense from a security POV to say "no modules have special access, however a module can

Re: -Xpatch with jar, jimage, or other non-exploded format?

On 04/12/2015 19:56, Michael Rasmussen wrote: The usage of -Xpatch is to be a replacement for -Xbootclasspath/p, to enable to patch boot CP classes, but at the moment it only seems to support pointing to an "exploded" directory, containing the individual .class files. Are there any plans to

Re: Question about jdk.internal.HotSpotIntrinsicCandidate

On 12/2/2015 11:44 AM, Alex Buckley wrote: On 12/2/2015 2:16 AM, Stephane Epardaud wrote: 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

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

Hi, On Sat, Dec 5, 2015 at 3:42 AM, Alex Buckley wrote: > On 12/4/2015 7:52 AM, David M. Lloyd wrote: > >> >> Yes, the tool is a Java compiler, piggybacking on the fact that a > compiler already needs to figure out an observable universe of types to > compile the source

Re: Feature complete?

Good point. The command line solution might work in a local context, but its viral nature means it will propagate to environments where often the best you can expect is for people to follow instructions mindlessly or to use an automated solution. So much for the idea that application developers