Re: Review request: JDK-8172870 test/tools/jmod/JmodTest.java fails on windows with AccessDeniedException

On 17/01/2017 21:23, Mandy Chung wrote: This test case attempts to verify that the temp file created by jmod is cleaned up and removed if jmod create command fails. It first cleans up any temp files matching the prefix and suffix created for this test case. The test fails because the fix

Re: RFR 8168254: Detect duplicated resources in packaged modules

> On Jan 17, 2017, at 10:03 PM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8168254/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8168254 Looks good except the copyright end year. Mandy

RFR 8168254: Detect duplicated resources in packaged modules

Please review http://cr.openjdk.java.net/~sundar/8168254/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8168254 Thanks, -Sundar

Re: Fwd: resource location problem in JDK 9 from build 148 onward

Thanks, David and Alan. The suggested workaround works for me. I will mouse your response into the commentary on https://issues.apache.org/jira/browse/DERBY-6856, where I have been collecting all of the issues I've encountered when building and testing Apache Derby with JDK 9. I strongly

hg: jigsaw/jake/langtools: jdeps update per ModuleDescriptor/Builder cleanup

Changeset: 2eac819e2faa Author:mchung Date: 2017-01-17 14:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2eac819e2faa jdeps update per ModuleDescriptor/Builder cleanup ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java !

Review request: JDK-8172870 test/tools/jmod/JmodTest.java fails on windows with AccessDeniedException

This test case attempts to verify that the temp file created by jmod is cleaned up and removed if jmod create command fails. It first cleans up any temp files matching the prefix and suffix created for this test case. The test fails because the fix for JDK-8160286 that creates the jmod temp

RE: Compact profile modules

Hi Alan, > > Are only the modules removed, and the javac options are still available? > We are compiling Apache Lucene Core using the compact1 profile currently: > > > > > > > > So we append "-profile compact1" when invoking javac. We have not > noticed any problems when doing this with

hg: jigsaw/jake/jdk: 2 new changesets

Changeset: f92bf219c0ec Author:alanb Date: 2017-01-17 12:55 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f92bf219c0ec Further clean-up of automatic module support ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java !

Re: Compact profile modules

On 17/01/2017 10:07, Uwe Schindler wrote: : Are only the modules removed, and the javac options are still available? We are compiling Apache Lucene Core using the compact1 profile currently: So we append "-profile compact1" when invoking javac. We have not noticed any problems when

RE: Compact profile modules

Hi Mandy, > java.compact$N modules were removed in jdk-9+150 [1][2]. > > We revisited the need for java.compact$N aggregator. Compact Profiles > were useful in SE 8 but are legacy in 9, as intended from the outset. > Highlighting them in the standard SE 9 module graph gives them > unnecessary

Re: RFR 8171380: Remove exports from jdk.jlink

- Mail original - > De: "Chris Hegarty" > À: "Remi Forax" > Cc: "jigsaw-dev" > Envoyé: Mardi 17 Janvier 2017 10:36:32 > Objet: Re: RFR 8171380: Remove exports from jdk.jlink >> On 17 Jan 2017, at 00:02, Remi

Re: RFR 8171380: Remove exports from jdk.jlink

> On 17 Jan 2017, at 00:02, Remi Forax wrote: > > Cris, > it seems that there is a mechanism for API that are experimental in the jdk, > by example java.net.http uses this mechanism, is it possible to reuse the > same mechanism for the jlink plugin API ? I did look at the

Re: Fwd: resource location problem in JDK 9 from build 148 onward

On 17/01/2017 00:55, Rick Hillegas wrote: : public class public class ResourceLocationProblem { public static void main(String... args) throws Exception { String resourceName = "/META-INF/MANIFEST.MF"; Class dummyClass = (new Object()).getClass(); Object is =