Re: Portable retrieval of resource bundles across module path and class path

On 7/23/21 4:17 AM, Gunnar Morling wrote: Thanks a lot for your replies, Mandy and Alan! > I assume the class path is running on JDK <= 8, right? Otherwise Is there something missing after "Otherwise"? It was a typo (I should have taken it out). In fact, I'm looking for a way to run

Re: Portable retrieval of resource bundles across module path and class path

On 7/22/21 12:23 PM, Gunnar Morling wrote: Hi all, I'm trying to figure out how a modular application should handle cross-module resource bundle look-ups, supporting running on both the module path and the class path. At a first look, resource bundle semantics in the two modes are at odds

Re: MethodHandles.publicLookup().in() returns Lookup with no permissions?

On 11/24/20 11:21 AM, Simone Bordet wrote: Hi, On Tue, Nov 24, 2020 at 7:35 PM Alan Bateman wrote: On 24/11/2020 18:21, Simone Bordet wrote: Hi, testing the Jetty MethodHandle usages we encountered this situation: .class org.openjdk.mh.Main Class klass = Main.class;

Re: MethodHandles.publicLookup().in() returns Lookup with no permissions?

On 11/24/20 10:21 AM, Simone Bordet wrote: Hi, testing the Jetty MethodHandle usages we encountered this situation: .class org.openjdk.mh.Main Class klass = Main.class; MethodHandles.Lookup lookup = MethodHandles.publicLookup().in(klass); MethodHandle handle = lookup.findVirtual(klass,

Re: JNI changes for modules

On 8/21/20 4:42 AM, Florian Weimer wrote: I see there's a new GetModule entry point, but I can't find anything that interacts directly with it. The challenge I see is that FindClass often cannot find application classes once modules are involved. Technically, I guess that's not a new

Re: 8241770: Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module

On 6/10/20 12:51 PM, Alan Bateman wrote: This is a bug in Module.getXXXAnnotation implementation where it accidentally locates a module-info.class on the class path (say if someone deploys a modular JAR on the class path). An oversight in the original implementation. Simple fix to

Re: Review Request 8240910: jmod rejects duplicate entries in --class-path jars

I have taken a further step to clean this up by recording the written entries such that it can filter out duplicated entries properly: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240910/webrev.01/ thanks Mandy On 5/7/20 10:12 AM, Mandy Chung wrote: jmod tool should ignore duplicated

Review Request 8240910: jmod rejects duplicate entries in --class-path jars

jmod tool should ignore duplicated resources from class path and emit a warning.  It currently ignores duplicated resources when read from a directory but not from JAR entries.  It's an oversight from the fix for JDK-8134779 [1]

Re: 8243596: ModuleLayer::parents should return an unmodifiable list

On 5/5/20 12:05 PM, Alan Bateman wrote: This is an small oversight and inconsistency that crept in when the ModuleLayer was updated to support multiple parents. The list of parent layers returned by the parents() method should be specified (and implemented) to return an unmodifiable list. It

Re: 8243666: ModuleHashes attribute generated for JMOD and JAR files

Hi Alan, On 4/27/20 12:34 PM, Alan Bateman wrote: This is build reproducibility issue with the module-info.class files in the packaged modules (JMOD files in the case of the JDK build). One part to this is the ModulePackages class file attribute that is added by the tools, including the

Re: RFR: JDK-8241463 Move build tools to respective modules

Hi Magnus, On 3/24/20 4:16 AM, Magnus Ihse Bursie wrote: At the core, we'd like to "invert" the current structure where we have files like: make/lib/Lib-java.base.gmk make/lib/Lib-java.desktop.gmk make/gensrc/Gensrc-java.base.gmk make/gensrc/Gensrc-java.desktop.gmk ... etc and instead have

Re: RFR: JDK-8241463 Move build tools to respective modules

Hi Magnus, Modularizing the build tools is a good move.    This patch suggests to place the build tools under     src/$MODULE/share/tools/$PACKAGE/*.java I think the modular source location of the build tools needs more discussion, including jigsaw-dev for this discussion. The JDK source

Re: (14) RFR JDK-8229396: jdeps ignores multi-release when generate-module-info used on command line

On 1/10/20 7:09 AM, Alan Bateman wrote: On 09/01/2020 02:28, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk14/8229396/webrev.00/index.html This fixes jdeps --generate-module-info option to read a multi-release JAR with the version specified at --multi-release option

(14) RFR JDK-8225773: jdeps --check produces NPE if there are missing module dependences

Webrev:    http://cr.openjdk.java.net/~mchung/jdk14/8225773/webrev.00/ jdeps --check throws NPE when the module descriptor has missing dependences.  This patch fixes jdeps --check option to report a module with missing dependences as other jdeps options. This patch applies on the top of the

(14) RFR JDK-8229396: jdeps ignores multi-release when generate-module-info used on command line

Webrev: http://cr.openjdk.java.net/~mchung/jdk14/8229396/webrev.00/index.html This fixes jdeps --generate-module-info option to read a multi-release JAR with the version specified at --multi-release option.  Also it enhances jdeps to report missing dependences as other options such as

Re: Lookup objects and setAccessible

Have you looked at Lookup::revealDirect and MethodHandleInfo::reflectAs? Mandy On 1/8/20 5:49 AM, Kasper Nielsen wrote: Sorry, I could have been a bit more specific. I meant something like Method.setAccessible(Lookup, true) I want to base an API on lookup objects. But I want to still support

Re: 8233922: Service binding augments module graph with observable incubator modules

On 11/18/19 4:34 AM, Alan Bateman wrote: This issue concerns the interaction of service binding with incubator modules, a left over from JDK 9 that resurfaces with the upcoming JEP 343 Packaging Tool (Incubator). The summary on this issue is that service binding augments the module graph

Re: RFR 8220700: jlink generated launcher script needs quoting to avoid parameter expansion

On 8/21/19 4:33 AM, sundararajan.athijegannat...@oracle.com wrote: Thanks Severin for your test improvement suggestion! Updated: http://cr.openjdk.java.net/~sundar/8220700/webrev.02/index.html The test case is good. Mandy

Re: RFR 8220700: jlink generated launcher script needs quoting to avoid parameter expansion

+1 What we really want is to replace this stop-gap shell script some day with jlink to generate the native launcher [1]. Mandy [1] JDK-8182555 On 8/20/19 4:52 AM, sundararajan.athijegannat...@oracle.com wrote: Oops. Wrong bug link. Correct one:

Re: RFR 8216535: tools/jimage/JImageExtractTest.java timed out

Hi Sundar, On 5/30/19 10:12 AM, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8216535 Webrev: https://cr.openjdk.java.net/~sundar/8216535/webrev.00/ Looks okay. It seems cleaner to have a new JImageCliTest constructor that takes the path

Re: Script generated using jlink --launcher doesn't espace arguments

I have created https://bugs.openjdk.java.net/browse/JDK-8220700 for this issue. A better solution would be to get the native launcher support [1] to replace this stop-gap generated script. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8182555 On 3/14/19 7:49 AM, li...@bendem.be wrote:

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

Hi Severin, This is my initial set of comments. On 2/26/19 3:01 AM, Severin Gehwolf wrote: --list-plugins output for --strip-native-debug-symbols: Plugin Name: strip-native-debug-symbols Option: --strip-native-debug-symbols= Description: Strip debug symbols from native libraries (if any).

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 2/25/19 2:49 AM, Alan Bateman wrote: On 15/02/2019 17:01, Severin Gehwolf wrote: : ->8- Plugin Name: strip-native-debug-symbols Option: --strip-native-debug-symbols= Description: Strip debug symbols from native libraries (if any).   This plugin requires at

Re: [PING?] RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

is now runs StripNativeDebugSymbolsPluginTest on some systems. Especially with --with-native-debug-symbols=internal builds this can eat some memory. Please let me know what you think. Thanks, Severin On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: On 2/13/19 1:04 AM, S

Re: RFR: 8218913: Rename --strip-debug jlink plugin

On 2/18/19 1:50 AM, Severin Gehwolf wrote: On Fri, 2019-02-15 at 23:27 -0800, Mandy Chung wrote: On 2/15/19 8:12 AM, Severin Gehwolf wrote: Thanks for the review! I've remove the @author tag: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/03/webrev/ Looks good. As Alan said

Re: RFR: 8218913: Rename --strip-debug jlink plugin

On 2/15/19 8:12 AM, Severin Gehwolf wrote: Thanks for the review! I've remove the @author tag: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/03/webrev/ Looks good. As Alan said, this needs a CSR to document the new plugin command-line option. thanks Mandy

Re: RFR: 8218913: Rename --strip-debug jlink plugin

On 2/14/19 8:38 AM, Severin Gehwolf wrote: A bit of clarification would be needed here I think: 1) The current option is called '--strip-debug', not '--strip-debug-info'. Did you mean to say to rename --strip-debug to --strip-debug-info too? Perhaps make '--strip-debug' and alias for

Re: RFR: 8218913: Rename --strip-debug jlink plugin

On 2/14/19 1:04 AM, Severin Gehwolf wrote: Hi Mandy, You add a new DefaultStripDebugPlugin that will do the work. I have been assuming that this can be implemented as a jlink option that get translated into --strip-java-debug-symbols during the command line argument processing. The reason

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 2/13/19 1:04 AM, Severin Gehwolf wrote: --strip-native-debug-symbols no-keep-debuginfo --strip-native-debug-symbols strip-debuginfo --strip-native-debug-symbols remove-debuginfo It would avoid using negation. What about 'omit', i.e. --strip-native-debug-symbols omit-debuginfo

Re: RFR: 8218913: Rename --strip-debug jlink plugin

Hi Severin, Thanks for doing this. I review the webrev. You add a new DefaultStripDebugPlugin that will do the work. I have been assuming that this can be implemented as a jlink option that get translated into --strip-java-debug-symbols during the command line argument processing. I'm okay

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 2/12/19 11:52 AM, Severin Gehwolf wrote: Hi Mandy, Alan, Please find the proposal for CLI option of --strip-native-debug-symbols below. The current implementation here has the following options: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ [i]

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 2/12/19 12:05 PM, Severin Gehwolf wrote: Hi Mandy, Thanks for the review! OK. Here is the summary: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-February/014132.html Personally, I find --strip-native-debug-info or --strip-native-debug- symbols clearer than just

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 2/8/19 2:08 AM, Alan Bateman wrote: I agree with Mandy that the CLI options need examination. The proposed `--strip-native-debug-symbols` seems reasonable but it will be inconsistent with the existing `--strip-debug` option. Mandy - what you would think about renaming the existing option

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

Hi Severin, Using the plugin specific ResourceBundle is good. Thanks for making the change. I see that Alan's comment [1] on the plugin options and I assume you will investigate the plugin options and bring back a proposal. Did I miss the discussion on these options? Option:

Re: RFR: Move jlink plugin resources into their own files

On 1/29/19 2:44 AM, Severin Gehwolf wrote: Right, thanks! In fact, I've come up with something similar. Here is a patch which moves resource files for jlink plugins into their own properties files: http://cr.openjdk.java.net/~sgehwolf/webrevs/jlink-plugins-resources/01/webrev/ It's not

Re: Help with build changes for: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 1/28/19 1:26 AM, Severin Gehwolf wrote: Hi Alan, Mandy, On Sun, 2019-01-27 at 08:14 +, Alan Bateman wrote: On 26/01/2019 00:06, Mandy Chung wrote: Hi Severin, Another alternative would be to support per-jlink-plugin resource bundle to avoid merging .properties files at build time

Re: RFR: 8217877: Dead code in jdk.jlink's TaskHelper

On 1/28/19 11:01 AM, Alan Bateman wrote: On 28/01/2019 15:00, Severin Gehwolf wrote: Hi, There seems to be dead code in class TaskHelper. Plugins are loaded via ServiceLoader from the module boot loader. I don't see how this code could ever be reached. The proposal is to remove it for

Re: Newbie Jigsaw question: How should I use 'jmod hash'

On 1/22/19 4:59 AM, Andre Tadeu de Carvalho wrote: Em ter, 22 de jan de 2019 às 10:06, Alan Bateman escreveu: On 21/01/2019 12:57, Andre Tadeu de Carvalho wrote: Hi, I am exploring the jmod utility and I am stuck with the following: I already generated the jmod file and I want to add a

Re: [Proposal] jlink plugin which replaces dynamic shared libraries

I also like this, stripping the native debug symbols, as a jlink plugin. Currently jlink does not support platform-specific plugin.   The Plugin API will need to be extended to specific the supported platforms, for example Plugin::isSupported and default to return true.   jlink will need to

Re: RFR 8212137: Remove JrtFileSystem finalize method

On 12/7/18 12:47 AM, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8212137 Webrev: https://cr.openjdk.java.net/~sundar/8212137/webrev.00/ Looks okay to me. Mandy

Re: RFR: 8214230: Classes generated by SystemModulesPlugin.java are not reproducable

On 11/29/18 12:47 AM, Erik Helin wrote: I agree as well, nice suggestion Claes! Please see updated patches below: - incremental: http://cr.openjdk.java.net/~ehelin/8214230/00-01/ - full: http://cr.openjdk.java.net/~ehelin/8214230/01/ +1 Mandy

Re: RFR: 8214230: Classes generated by SystemModulesPlugin.java are not reproducable

On 11/28/18 1:59 AM, Erik Helin wrote: Hi all, this small patch ensures that two classes generated by jlink's SystemModulePlugin (SystemModules$default and SystemModules$all) are generated in a reproducible manner. That is, if you run jlink two times in a row with identical input, then

Re: Testing whether or not a Lookup object has access to members

You can submit from https://bugreport.java.com/bugreport/ Mandy On 10/26/18 2:48 AM, Kasper Nielsen wrote: Hi Mandy, I don't have access to JBS unfortunately. Cheers   Kasper On Wed, 24 Oct 2018 at 16:50, Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: Can you file a

Re: Testing whether or not a Lookup object has access to members

if something like this was available: boolean Lookup.isAccessible(Member member) boolean Lookup.isAccessible(Class member) /Kasper On Tue, 23 Oct 2018 at 00:07, Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: Lookup.accessClass(member.getDeclaringClass()) can be use

Re: Testing whether or not a Lookup object has access to members

Lookup.accessClass(member.getDeclaringClass()) can be used to test if the lookup class can access the declaring class of the given member. This only checks if a class is accessible.  I think unreflecting a member will do what you are looking for to check if the lookup object has access to the

Re: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module

On 10/8/18 7:46 AM, Alan Bateman wrote: This is the issue that Thomas Watson brought up here on Friday. If defineModulesWithXXX is used to create a module layer and it contains a module that reads an automatic module mapped to a different class loader (same layer or parent layer) then the

Re: Separate logging for JPMS module/layer

On 10/5/18 8:11 AM, Ralph Goers wrote: Benchmark Mode Cnt Score Error Units StackTraceBenchmark.defaultJava8 thrpt 3 113965.921 ± 119706.986 ops/s StackTraceBenchmark.securityManager thrpt 3 788004.237 ± 82578.567 ops/s StackTraceBenchmark.stackWalker thrpt 3 182902.031 ± 39018.395 ops/s

Re: Separate logging for JPMS module/layer

org>> wrote: Unfortunately, we can’t use getCallerClass. Some API methods can be called by users of the API or by other methods in the API class. Ralph On Oct 4, 2018, at 2:50 PM, Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: If you are looking for the immediate caller, you c

Re: Separate logging for JPMS module/layer

ive frames as I see). Mandy On Thu, Oct 4, 2018 at 3:51 PM Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: If you are looking for the immediate caller, you can try StackWalker::getCallerClass which only walks the top few frames and intends to be lower cost. Mand

Re: Separate logging for JPMS module/layer

If you are looking for the immediate caller, you can try StackWalker::getCallerClass which only walks the top few frames and intends to be lower cost. Mandy On 10/4/18 2:04 PM, Ralph Goers wrote: Hmm, it would probably be a safe assumption that a Logger will never be used outside of the

Re: RFR: 8209003: Consolidate use of empty collections in java.lang.module

This cleanup looks fine. Mandy On 8/7/18 9:16 AM, Claes Redestad wrote: Hi, feel free to review this cleanup to consolidate some uses of Collections.empty/unmodifiableXx.. to Set/Map/List.of()/copyOf(), as appropriate. This aligns better with code already generated by jlink, so avoids

[12] RFR JDK-8202941: GenModuleInfoSource build tool does not detect missing semicolons

GenModuleInfoSource build tool augments module-info.java to include platform-specific qualified exports/opens and uses/provides services. This fixes the build tool to catch syntax errors as closely as javac does. The build tool remains to allow duplicated provides until JDK-8208463 is resolved.

Re: RFR: 8205926: Support invokeSpecialIFC in GenerateJLIClassesPlugin

On 6/27/18 6:40 AM, Claes Redestad wrote: Hi, JDK-8200167 introduced a new DMH kind, invokeSpecialIFC, which slightly perturbed what forms we see on startup, which is linked to some minor startup regressions in 11+19 Add support for

Re: 8205533: Class.getPackage() fails with InternalError if class is defined to the bootstrap class loader but module is not in the boot layer

On 6/24/18 7:32 AM, Alan Bateman wrote: This is a corner case that showed up while chasing an issue in another area. If a tool uses the attach mechanism to start the JMX agent in a running VM that doesn't have the jdk.management.agent module in the boot layer then the module is resolved and

Re: 8194937: Inconsistent behavior of --validate-modules when combined with -m and other options

The change looks good. I'm glad that we get rid of the need for the minimal boot layer for validation and gets the option handling consistent. thanks Mandy On 6/20/18 11:40 PM, Alan Bateman wrote: The java `--validatate-modules` option is a very useful option to scan all modules to

Re: 8197532: Re-examine policy for the default set of modules when compiling or running code on the class path

I looked through the change and looks good. Mandy On 6/19/18 1:31 AM, Alan Bateman wrote: JEP 261 details how the default set of root modules is computed when compiling code in the unnamed module or when running code and the main class is loaded from the class path. I'd like to re-visit

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

On 6/15/18 12:45 PM, Alan Bateman wrote: On 15/06/2018 20:14, mandy chung wrote: Alan, Lance, I added a test case for JDK-8205116 in test/langtools/tools/jdeps/Options.java. Updated webrev for JDK-8205116 only: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205116/webrev.01

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

Alan, Lance, I added a test case for JDK-8205116 in test/langtools/tools/jdeps/Options.java. Updated webrev for JDK-8205116 only: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205116/webrev.01/ Mandy On 6/15/18 10:47 AM, Alan Bateman wrote: On 15/06/2018 17:34, mandy chung wrote

Review Request JDK-8200121: Remove unused qualified exports in java.base

A simple cleanup to remove unused qualified exports in java.base. The webrev also includes a fix for JDK-8205116 (jdeps --system $java.home fails) that I uncovered through this process where I ran `jdeps --check java.base --system $java.home` on the JDK binaries on several platforms. Webrev

Review Request 8205112: Remove non-existent modules from test/jdk/jdk/modules/etc/UpgradeableModules.java

This patch cleans up the list of upgradeable modules kept in test/jdk/jdk/modules/etc/UpgradeableModules.java test verification and take out the modules that have been removed. thanks Mandy --- a/test/jdk/jdk/modules/etc/UpgradeableModules.java +++

Re: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable

On 6/14/18 9:35 AM, Doug Simon wrote: I changed the test (thanks Mandy for pointing out exactly which one), fixed the alphabetic ordering of the list and am running tests now. I reviewed http://cr.openjdk.java.net/~dnsimon/8205025/. Looks good. Mandy

Re: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable

test/jdk/jdk/modules/etc/UpgradeableModules.java needs to be updated as it keeps the list of upgradeable modules as well to verify the hashes in java.base. Mandy On 6/14/18 1:09 AM, Doug Simon wrote: In the context of JDK-8202762, we to need to make the jdk.aot module upgradeable.

Re: jlink / jmods version compatibiltiy

On 6/1/18 3:24 PM, Bernd Eckenfels wrote: Hello, I am not sure what the Policy for backward/Forward compatibility for JMOD files is, but when I use JDK-9.0.4 jlink on 11ea JMODs I get a IllegalArgumentException and „error reading“ by JDK-10.0.1 with no further Details. jlink only supports

Re: RFR: 8202810: Remove class-for-name test

+1 I checked and this is the only test needed update. Mandy On 5/8/18 1:45 PM, Claes Redestad wrote: Hi, please review the removal of this test that explicitly attempts to run the now removed jlink --class-for-name plugin: diff -r 7f05a1e6a02a test/jdk/tools/jlink/JLinkPluginsTest.java

Re: RFR: 8202583: Remove experimental ClassForNamePlugin

On 5/7/18 6:23 AM, Claes Redestad wrote: Hi, the --class-for-name jlink plugin was added as an experiment to test and evolve the jlink plugin infrastructure. The actual effect of enabling this plugin on standard images is very limited (only a handful of Class.forName:s are replaced) and

Re: RFR: 8201794: [Graal] fix regressions from JDK-8187490

Looks okay.  Have you run all jdk_core tests in addition to other hotspot tests. Mandy On 4/18/18 7:00 PM, Doug Simon wrote: I've updated the webrev with a fix for another regression caused by JDK-8187490: --- old/test/jdk/jdk/modules/etc/UpgradeableModules.java2018-04-18

Re: Avoiding sun.misc.Unsafe and embracing modules in Java libraries: missing links

Hi Rafael, FYI.  I have sent a proposal [1] for item #1 to serviceability-dev and you for discussion.  JBS issue is:    https://bugs.openjdk.java.net/browse/JDK-8200559 Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-April/023529.html On 4/2/18 5:02 AM, Rafael

Re: RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

On 4/13/18 2:24 AM, Doug Simon wrote: Please review this change that removes the existing Graal service provider for hooking into the Platform MBean Server and makes jdk.internal.vm.compiler.management an upgradeable module. Please refer to

Re: RFR 8193033 remove terminally deprecated sun.misc.Unsafe.defineClass

+1 Mandy On 3/15/18 10:06 AM, Paul Sandoz wrote: Hi, Please review this patch to remove sun.misc.Unsafe.defineClass in 11. There has been much outreach, by Alan and the Jigsaw team, about its public replacement MethodHandles.Lookup.defineClass. CSR is here:

Re: RFR 8194922: jlink --exclude-resources should never exclude module-info.class

Looks good.  I agree that this should be an error when excluding module declaration. Mandy On 2/20/18 1:50 AM, Sundararajan Athijegannathan wrote: Throwing exception now -> http://cr.openjdk.java.net/~sundar/8194922/webrev.02/ Thanks -Sundar On 20/02/18, 2:54 PM, Alan Bateman wrote: On

Re: IllegalAccessException trying to load a ResourceBundle in 9u181

On 2/12/18 12:36 PM, Vitaly Davidovich wrote: Hi all, I'm not sure if core-libs is the right mailing list for jigsaw/modules questions these days (rather than jigsaw-dev), so please feel free to forward this there if it's the more appropriate list. cc'ing  jigsaw-dev I have the following

Re: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory

On 2/9/18 7:23 AM, Michal Vala wrote: Patch validates output directory before any jimage extracting happen. I've moved validation to extra private method as it is few lines of code. I've also added proper error message for case when output path is not a directory (JImageTask.java#449).

Re: [11] RFR JDK-8196310: jlink --suggest-providers fails with missing resource if --output specified

he message to …does not accept *the* “-output…” or …does not *support* *the* “-output…” Best Lance On Jan 30, 2018, at 7:31 PM, mandy chung <mandy.ch...@oracle.com <mailto:mandy.ch...@oracle.com>> wrote: (resend with fixed formatting) Webrev: http://cr.openjdk.java.net/~mchung

Re: [11] RFR JDK-8196310: jlink --suggest-providers fails with missing resource if --output specified

(resend with fixed formatting) Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8196310/webrev.00/ Improve the error message when invalid argument is specified to --suggest-providers option. $ jlink --add-modules java.base --suggest-providers java.security.Provider --output

[11] RFR JDK-8196310: jlink --suggest-providers fails with missing resource if --output specified

Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8196310/webrev.00/ Improve the error message when invalid argument is specified to --suggest-providers option. $ jlink --add-modules java.base --suggest-providers java.security.Provider --output myimage Error: --suggest-providers does

[10] RFR JDK-8194229: tools/jmod/JmodTest.jtr fails when no privilege to create sym link on windows

This is a simple test-only fix. IOException may be thrown when a symlink is failed to create on windows. The test should handle such case in addition to UOE. Webrev at: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8194229/webrev.00/ Mandy

Re: How does one handle a java method which returns a non-public sub-type via reflection?

On 1/12/18 10:26 AM, jeffrey kutcher wrote: m = o.getClass().getMethod("add", new Class[] { Object.class, }); o = m.invoke(o, new Object[] { button1, }); o.getClass().getMethod(...) is an anti-pattern for finding a public method.   Object.getClass() returns the

Re: jar --print-module-descriptor

I created https://bugs.openjdk.java.net/browse/JDK-8194653 to fix the docs bug.   The docs was missed to be updated when this jar option was renamed to --describe-module. Thanks for reporting this. Mandy On 1/4/18 2:16 PM, Nicolai Parlog wrote: Hi! The Java 9 jar documentation says[1]:

Re: Proposal for New Functionality: Allow module-info merging in GenModuleInfoSource.java

/java/lang/management/internal/ManagementUtils.java - com/ibm/java/lang/management/internal/LoggingMXBeanImpl.java - java/lang/management/PlatformLoggingMXBean.java Ideally it'd be good to keep this functionality in these classes. Best Regards Adam Farley From: Adam Farley8/UK/IBM To: mandy chung <mandy

Re: 8191867: Module attribute in 54.0+ class file cannot contains a requires java.base with ACC_TRANSITIVE or ACC_STATIC_PHASE

On 12/7/17 6:56 AM, Alan Bateman wrote: On 06/12/2017 17:17, mandy chung wrote: or it can print "java.base includes " + mods? I've adjusted the exception text so that it reads:    "The requires entry for java.base has ACC_TRANSITIVE set" and updated the webrev in

Re: Proposal for New Functionality: Allow module-info merging in GenModuleInfoSource.java

Can you send some example module-info.java & .extra files and source location that shows what functionality you depend on? Mandy On 12/7/17 4:20 AM, Adam Farley8 wrote: Update: OpenJ9 appears to need this functionality. Best Regards Adam Farley From: Adam Farley8/UK/IBM To: mandy c

Re: Proposal for New Functionality: Allow module-info merging in GenModuleInfoSource.java

Moving this to jigsaw-dev On 12/6/17 8:38 AM, Adam Farley8 wrote: Hi All, Currently, GenModuleInfoSource.java does not allow you to merge extra module-info files into the primary module-info file (for a given module) at build time. This tool intends to augment platform-specific

Re: Review Request JDK-8192945: Need stable sort for MODULES entry in the release file

Okay this is a better version (traversing the graph keyset directly): http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8192945/webrev.02/ Mandy

Re: 8191867: Module attribute in 54.0+ class file cannot contains a requires java.base with ACC_TRANSITIVE or ACC_STATIC_PHASE

On 12/6/17 9:00 AM, Paul Sandoz wrote: On 6 Dec 2017, at 07:42, Alan Bateman wrote: The draft JVMS for Java SE 10 forbids an entry in the requires table of a Module attribute in a 54.0 or newer class file to require java.base with the ACC_TRANSITIVE or

Re: Review Request JDK-8192945: Need stable sort for MODULES entry in the release file

Updated webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8192945/webrev.01/ I kept the nodes as a Deque as it polls one node for traversal.   I fixed line 110-111 to use a Set. thanks Mandy

Review Request JDK-8192945: Need stable sort for MODULES entry in the release file

The MODULES list in the `release` file is topologically sorted. For a given module graph, the patch traverses the graph in a stable order during the topological sort that will produce the same result for the same module graph. Webrev at:

Re: RFR 8185130: jlink should throw error if target image and current JDK versions don't match

On 12/5/17 9:43 AM, Sundararajan Athijegannathan wrote: Updated: http://cr.openjdk.java.net/~sundar/8185130/webrev.02/ Looks good.  Thanks for the update. Mandy

Re: RFR 8185130: jlink should throw error if target image and current JDK versions don't match

On 12/5/17 6:42 AM, Sundararajan Athijegannathan wrote: Updated to check minor version as well -> http://cr.openjdk.java.net/~sundar/8185130/webrev.01/index.html 454 throw new IllegalArgumentException(String.format("jlink version %d.%d != java.base version %d.%d", 455

Re: 8182742: ClassLoader.getResourceXXX throws NPE when ClassLoader created by defineModulesWithXXX

+1 Mandy On 12/5/17 6:11 AM, Alan Bateman wrote: I need a Reviewer for a trivial change to the class loaders that support the ModuleLayer defineModulesWithXXXLoader methods. These methods create one or many class loaders to load classes/resources from the modules in the layer. The parent

Re: 8186736: Spec clarifications for IllegalArgumentException throwing - ModuleLayer.defineX methods

Looks good to me. Mandy On 12/5/17 4:07 AM, Alan Bateman wrote: The description for the IllegalArgumentException thrown by the ModuleLayer.defineModulesXXX methods isn't very clear. Attached is the proposed patch to improve the wording, there are no implementation changes. Mandy has already

Re: 8192973: Adding "Resolution" to javadoc search index

+1 Mandy On 12/4/17 6:45 AM, Alan Bateman wrote: I'd like to add a search term to the javadoc search to make it easy to find the Resolution spec. Attached is the proposed patch. In terms we will need to do the same for service binding. -Alan $ hg diff

Re: RFR 8177471: jlink should use the version from java.base.jmod to find modules

Looks good.  Thanks for fixing this. Mandy On 11/13/17 2:02 AM, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8177471 Webrev: http://cr.openjdk.java.net/~sundar/8177471/webrev.00/index.html Thanks to Mandy for initial (internal) round of

Re: Regression in getImplementationVersion from Jigsaw

the limit was on line lengths, so I will watch and learn :) Thanks Michael On 9 November 2017 at 13:22, mandy chung <mandy.ch...@oracle.com> wrote: Hi Michael, It is indeed a bug and I file: https://bugs.openjdk.java.net/browse/JDK-8190987 The patch looks good and I will sponsor this

Re: Regression in getImplementationVersion from Jigsaw

Hi Michael, It is indeed a bug and I file:    https://bugs.openjdk.java.net/browse/JDK-8190987 The patch looks good and I will sponsor this patch for you. Thanks for the regression test.  It'd be good to wrap the long lines and I will clean that up before I push. thanks Mandy On 11/8/17

Re: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing

jlink --add-modules ALL-MODULE-PATH does not work in this patch since the default module is added after the roots set is computed. AppRuntimeImageBuilder could calls its moduleFinder method (that calls JlinkTask::newModuleFinder).   packager may already provide the default module path and we

Re: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing

On 10/23/17 9:05 PM, Sundararajan Athijegannathan wrote: Hi, * ALL-MODULE-PATH case seems to be handled fine (in  private JlinkConfiguration initJlinkConfig() throws BadArgs { method). When no --module-path is specified, default module path is used and all default observable modules are

Re: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing

On 10/23/17 3:37 AM, Sundararajan Athijegannathan wrote: Updated for getDefaultModulePath. moduleFinder uses three instance fields - modulepaths, limitmods and modules. We may have to pass all to the static method... http://cr.openjdk.java.net/~sundar/8189777/webrev.01 What happens to this

Re: RFR 8189671: jlink should clearly report error when an automatic module is used

On 10/20/17 1:03 AM, Sundararajan Athijegannathan wrote: Updated: http://cr.openjdk.java.net/~sundar/8189671/webrev.03/ Looks good. Mandy

Re: RFR 8189671: jlink should clearly report error when an automatic module is used as root

to include the pathname to the exception message. Nit: long line and good to wrap it into multiple lines. Mandy P.S.  My previous reply lost the formatting and I fixed the copy below (just as a record for easy viewing). On 10/19/17 2:58 PM, mandy chung wrote: On 10/19/17 7:04 AM, Sundararajan Athij

Re: RFR 8189671: jlink should clearly report error when an automatic module is used as root

On 10/19/17 7:04 AM, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8189671 Webrev: http://cr.openjdk.java.net/~sundar/8189671/webrev.00/ 441 ModuleFinder finder = config.finder(); 442 for (String root : config.getModules()) { This should

  1   2   3   4   5   6   7   8   9   10   >