hg: jigsaw/jake/hotspot: VerifyMethodHandles can't verify access check without lookup modes when caller is jl.Object

Changeset: cca505877738 Author:alanb Date: 2017-02-04 07:28 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cca505877738 VerifyMethodHandles can't verify access check without lookup modes when caller is jl.Object ! src/share/vm/prims/methodHandles.cpp

Re: Automatic module names

Hi! > I think one option we should consider is to perhaps disable automatic > modules for 9 and revisit the idea for 10, as it's late in the day and > still clearly not settled. I disagree. The idea that modules should not depend "on the chaos of the class path" seems to be a very good one.

Re: ClassLoader.getResource("mypackageroot") fails against exploded module

On 03/02/2017 18:17, Juergen Hoeller wrote: Spring's classpath scanning works fine on JDK 9 for classpath resources (archives as well directories) and also for archives on the module path. One API to look at for scanning the module path is ModuleFinder.of(Path...). That will give you the set

Help Unsubscribe me from this chain

On Feb 3, 2017 10:04 PM, wrote: Send jigsaw-dev mailing list submissions to jigsaw-dev@openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev or, via email, send a

hg: jigsaw/jake/jdk: Add @spec tag on additional APIs for JPMS spec

Changeset: 5135bbdae96f Author:mchung Date: 2017-02-03 13:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5135bbdae96f Add @spec tag on additional APIs for JPMS spec ! src/java.base/share/classes/java/lang/StackTraceElement.java !

Re: ClassLoader.getResource("mypackageroot") fails against exploded module

On 03/02/2017 18:17, Juergen Hoeller wrote: Spring's classpath scanning works fine on JDK 9 for classpath resources (archives as well directories) and also for archives on the module path. However, it does not work for an exploded module layout, simply because

Re: Optional framework dependencies: requires static vs automatic modules

For "requires static" specifically, this effect is quite dramatic since it makes the optional runtime dependency feature useless for a large number of target scenarios. Alright, I'll re-test against build 156+ then. Juergen On Fri, Feb 3, 2017 at 8:07 PM, Alan Bateman

Re: Optional framework dependencies: requires static vs automatic modules

On 03/02/2017 18:14, Juergen Hoeller wrote: : Was it intentional for "requires static" to work that way? Am I missing something? From my perspective, "requires static" means that the referenced module has to be present when compiling the declaring module... but not when compiling other modules

ClassLoader.getResource("mypackageroot") fails against exploded module

Spring's classpath scanning works fine on JDK 9 for classpath resources (archives as well directories) and also for archives on the module path. However, it does not work for an exploded module layout, simply because ClassLoader.getResource("mypackageroot") always returns null in such a scenario.

Optional framework dependencies: requires static vs automatic modules

I've been experimenting with a Spring/Hibernate application on Jigsaw again, in particular with respect to including module-info descriptors in our framework jars... as opposed to using the framework jars as automatic modules. Unfortunately, it seems that "requires static" is transitive at

Re: Automatic module names

On 03/02/2017 16:42, David M. Lloyd wrote: : Sure, but the set of JARs you can't rewrite is really pretty spare. I've no doubt that many people would be uncomfortable taking responsibility to modularize a component that they don't maintain or have full knowledge of. In the early

Re: Automatic module names

On 02/03/2017 09:40 AM, Alan Bateman wrote: On 03/02/2017 11:44, Robert Scholte wrote: Hi Nicolai, let's consider that my project depends on the following dependencies: com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. I somehow want to have them both as requirements: module

Re: Automatic module names

On 02/03/2017 08:43 AM, Andrew Dinn wrote: On 03/02/17 14:29, David M. Lloyd wrote: I think one option we should consider is to perhaps disable automatic modules for 9 and revisit the idea for 10, as it's late in the day and still clearly not settled. I don't think this is thinking about the

Re: Automatic module names - "requires package" proposal

On 3 February 2017 at 15:40, Alan Bateman wrote: > I think automatic modules are critical to migration, otherwise things move > at the pace of the slowest project (which might be 0km/h in case of > unmaintained projects). A lot of the discussion here has been on the

Re: Automatic module names

On 03/02/2017 11:44, Robert Scholte wrote: Hi Nicolai, let's consider that my project depends on the following dependencies: com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. I somehow want to have them both as requirements: module M.N { requires static library; //

Re: Automatic module names

On 03/02/17 14:29, David M. Lloyd wrote: > I think one option we should consider is to perhaps disable automatic > modules for 9 and revisit the idea for 10, as it's late in the day and > still clearly not settled. I don't think this is thinking about the trade-off correctly. Automatic modules

Re: Automatic module names

I think one option we should consider is to perhaps disable automatic modules for 9 and revisit the idea for 10, as it's late in the day and still clearly not settled. On 02/03/2017 05:44 AM, Robert Scholte wrote: Hi Nicolai, let's consider that my project depends on the following

hg: jigsaw/jake/jdk: 2 new changesets

Changeset: a0a6f078fefe Author:alanb Date: 2017-02-03 12:06 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0a6f078fefe Tighten up ModuleReader for exploded modules ! src/java.base/share/classes/java/lang/module/ModuleReader.java !

Re: Automatic module names

Hi Nicolai, let's consider that my project depends on the following dependencies: com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. I somehow want to have them both as requirements: module M.N { requires static library; // com.foo.bar:library requires library; //

hg: jigsaw/jake/langtools: 17 new changesets

Changeset: 17a11ffc6a0a Author:jlahoda Date: 2017-01-24 13:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/17a11ffc6a0a 8153759: jshell tool: Smart completion detection is not reliable Summary: Reverting back to smart completion if any action follows a completion

hg: jigsaw/jake/jdk: 48 new changesets

Changeset: d191fcd1525d Author:rgoel Date: 2017-01-24 12:06 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d191fcd1525d 8167273: Calendar.getDisplayNames inconsistent with DateFormatSymbols Reviewed-by: naoto ! make/gensrc/GensrcLocaleData.gmk !

hg: jigsaw/jake/hotspot: 5 new changesets

Changeset: e20d7e4a25ac Author:adinn Date: 2017-01-26 11:47 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e20d7e4a25ac 8173339: AArch64: Fix minimum stack size computations Reviewed-by: aph ! src/cpu/aarch64/vm/globals_aarch64.hpp Changeset: 7b0f663ad09c Author:

hg: jigsaw/jake/jaxws: 2 new changesets

Changeset: 83c33cc9f158 Author:lana Date: 2017-02-02 21:20 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/83c33cc9f158 Added tag jdk-9+155 for changeset 9b9918656c97 ! .hgtags Changeset: 9af8d95119b5 Author:alanb Date: 2017-02-03 09:34 + URL:

hg: jigsaw/jake/corba: 5 new changesets

Changeset: b33379591dea Author:coffeys Date: 2017-01-25 12:09 + URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/b33379591dea 8077395: org.omg.CORBA_2_3.portable.InputStream constructor should not specify JDK-specific property Reviewed-by: lancea, rriggs !

hg: jigsaw/jake/jaxp: 6 new changesets

Changeset: 620d0c38581f Author:clanger Date: 2017-01-24 11:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/620d0c38581f 8173261: JAXP: TESTBUG: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh Reviewed-by: dfuchs, fyuan ! test/ProblemList.txt !

hg: jigsaw/jake: 6 new changesets

Changeset: 33169b3b9542 Author:chegar Date: 2017-01-25 14:10 + URL: http://hg.openjdk.java.net/jigsaw/jake/rev/33169b3b9542 8173354: javadoc warning notice for types in Incubator Modules Reviewed-by: erikj, michaelm ! make/Javadoc.gmk Changeset: c7e03e50dd5c Author:lana

hg: jigsaw/jake/nashorn: 7 new changesets

Changeset: 9aa94f11a8b9 Author:sundar Date: 2017-01-24 18:08 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9aa94f11a8b9 8173257: test/script/trusted/JDK-8021189.js and test/script/trusted/JDK-8021129.js fail in nashorn nightly Reviewed-by: hannesw, jlaskey !