Re: RFR 8192986: Inconsistent handling of exploded modules in jlink

[Jim Laskey (Oracle)]

+1


> On Dec 7, 2017, at 11:27 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Hi,
> 
> * On stricter check for missing module-info.class in a directory: There is a 
> similar check for non-modular jars.
> 
> jlink --add-modules java.base --module-path t.jar  --output foo
> Error: Unable to derive module descriptor for t.jar
> 
> t.jar in the above command is a non-modular jar. I think it is better to 
> detect and report non-modular exploded dirs as well.
> 
> * Fixed to avoid second resolve for "module-info.class" in JlinkTask.java
> 
> Please review updated webrev: 
> http://cr.openjdk.java.net/~sundar/8192986/webrev.02/
> 
> Thanks
> -Sundar
> 
> On 07/12/17, 9:15 PM, Sundararajan Athijegannathan wrote:
>> Hi,
>> 
>> Comments below...
>> 
>> On 07/12/17, 8:54 PM, Claes Redestad wrote:
>>> Hi Sundar,
>>> 
>>> thanks for picking this up so quick!
>>> 
>>> On 2017-12-07 16:21, Sundararajan Athijegannathan wrote:
 Updated: http://cr.openjdk.java.net/~sundar/8192986/webrev.01/
>>> 
>>> Looks ok, butunless my understanding is flawed it seems the logic is now 
>>> getting more strict about a directory on the module path containing a 
>>> well-formed module. Should this be made more graceful, say ignore empty 
>>> directories? Maybe just warn about malformed and/or missing modules?
>> I'd prefer stricter checks. But I'd like to hear from others as well...
>>> Nits:
>>> 
>>> JlinkTask: resolves module-info.class twice (resolve once and pass as 
>>> parameter?)
>> 
>> Yes, I'll fix that.
>> 
>>> 
>>> ExplodedModuleNameTest:
>>> 
>>>  58 if (helper == null) {
>>>  59 System.err.println("Test not run");
>>>  60 return;
>>>  61 }
>>> 
>>> Should this fail the test (by throwing an exception)?
>> 
>> This is similar to other tests. For eg. ModuleNamesOrderTest
>> 
>>>  66 // rename the module containing directory
>>>  67 Path renamedModDir = 
>>> modDir.resolveSibling("modified_mod8192986");
>>>  68 // copy the content from original directory to modified name 
>>> directory
>>>  69 copyDir(modDir, renamedModDir);
>>> 
>>> Any reason not to use Files.move(modDir, 
>>> renamedModDir|,StandardCopyOption.REPLACE_EXISTING|) instead of copying 
>>> here?
>>> 
>> 
>> https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#move(java.nio.file.Path,%20java.nio.file.Path,%20java.nio.file.CopyOption...)
>>  
>> 
>> "To move a file tree may involve copying rather than moving directories and 
>> this can be done using the copy method in conjunction with the 
>> Files.walkFileTree utility method."
>> 
>> Thanks,
>> -Sundar
>> 
>>> Thanks!
>>> 
>>> /Claes
>>> 

Re: RFR: 8175891, 8192892: JrtPath improvements

[Jim Laskey (Oracle)]

+1


> On Dec 1, 2017, at 9:34 AM, Claes Redestad  wrote:
> 
> Hi,
> 
> please review this patch that resolves two small but sometimes significant 
> inefficiencies in jdk.internal.jrtfs.JrtPath:
> 
> Improve JrtPath::getResolved fast-path test:
> https://bugs.openjdk.java.net/browse/JDK-8192892
> 
> Testing for '.' is insufficient as it's likely all paths have a dot in them, 
> while resolving is rare. Patch uses a test that is logically equivalent to 
> that in ZipPath::getResolved to better filter out paths that don't need to 
> take the slow path.
> 
> JrtPath::resolve off-by-one pre-sizing cause for memory pressure:
> https://bugs.openjdk.java.net/browse/JDK-8175891
> 
> As path is normalized to never end with a / this code can be simplified.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8192892/open.0/
> 
> In a JMH micro[1] that naively walks all entries in the JDK lib/modules and 
> counts classes, these fixes work together to remove overhead both in repeated 
> and single-shot settings (the latter is relevant since jrtfs usage may 
> influence startup times in certain applications and tools):
> 
> Benchmark   Mode  Cnt  Score   Error  Units
> JRTWalk.walkJImage  avgt   25  0.049 ± 0.003   s/op
> JRTWalk.walkJImage  avgt   25  0.027 ± 0.001   s/op  # 1.8x
> 
> Benchmark   Mode  Cnt  Score   Error  Units
> JRTWalk.walkJImagess   20  0.436 ± 0.018   s/op  (best: 0.389 s/op)
> JRTWalk.walkJImagess   20  0.388 ± 0.017   s/op  (best: 0.363 s/op)
> 
> Thanks!
> 
> /Claes
> 
> [1] http://cr.openjdk.java.net/~redestad/8192892/JRTWalk.java

Re: RFR: 8175561: Memory churn in jimage code affects startup after resource encapsulation changes

[Jim Laskey (Oracle)]

My only concern at this point is if Claes and I get hit by a bus, no one will 
be able to figure this out.  I recommend that next release that we switch to 
character based hash.  This means some minor complexity in the C code but I 
think the java code will be much simpler (and the C not so bad.)


> On Mar 1, 2017, at 7:42 PM, Mandy Chung  wrote:
> 
> 
>> On Feb 27, 2017, at 6:55 PM, Claes Redestad  
>> wrote:
>> 
>> Hi,
>> 
>> thanks Mandy and Jim for reviewing!
>> 
>> However, I've found enough evidence now that we should this
>> one step further and eliminating the allocation in
>> BasicImageReader::findLocation(String, String), which completely
>> gets rid of the regressions we're seeing:
>> 
>> http://cr.openjdk.java.net/~redestad/8175561/jdk.02/
>> http://cr.openjdk.java.net/~redestad/8175561/jdk.01.02.diff/
>> 
> 
> This looks correct but we need Jim to confirm the bug you spotted 
> ImageLocationWriter.
> 
>  59 public static int hashCode(String string) {
> 
> and all of other hashCode methods.
> 
> Nit: "String name" should work as it matches the parameter in the caller 
> method.  Or `s` might be better than “String string”.
> 
> 153 static boolean verify(String module, String name,
> 154 final long[] attributes, final ImageStrings strings) {
> 67 private static boolean verifyName(String name, int index, final int 
> length,
> 168 final long[] attributes, final ImageStrings strings) {
> 
> Nit: some final and some non-final parameters and better to be consistent. 
> Any reason why you mark it “final”?
> 
> No need for a new webrev.
> 
> Thanks
> Mandy

Re: RFR: 8169713: jimage fails with StringIndexOutOfBoundsException when path to the inspected image is an empty string

[Jim Laskey (Oracle)]

+1 

> On Feb 23, 2017, at 1:34 PM, Claes Redestad  wrote:
> 
> Hi,
> 
> please review this fix to make the jimage tool work correctly
> for empty string:
> 
> diff -r b2661d26e556 
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java
> --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java 
> Wed Feb 22 14:12:01 2017 -0800
> +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java 
> Thu Feb 23 18:27:48 2017 +0100
> @@ -524,7 +524,7 @@
> List rest = collectUnhandled? new ArrayList<>() : null;
> // process options
> for (int i = 0; i < args.length; i++) {
> -if (args[i].charAt(0) == '-') {
> +if (args[i].startsWith("-")) {
> String name = args[i];
> PluginOption pluginOption = null;
> Option option = getOption(name);
> 
> /Claes

Re: RFR: 8175010: ImageReader is not thread-safe

[Jim Laskey (Oracle)]

+1

> On Feb 15, 2017, at 9:22 AM, Claes Redestad  wrote:
> 
> Hi,
> 
> a few intermittent but rare test failures[1] that has appeared
> since the latest jake integration, and since one of the changes
> in there was to make initialization of the system ImageReader
> lazy there appears to be cases where ImageReaders are not
> safely published:
> 
> - Ensure ImageReader::open is called only once per Path in
> ImageReaderFactory by using CHM.computeIfAbsent
> - Ensure ImageReader.reader is safely published to a
> final field and signal close using a volatile boolean instead
> 
> webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/
> bug: https://bugs.openjdk.java.net/browse/JDK-8175010
> 
> Testing shows no issues (which admittedly doesn't mean we're
> actually solving the root cause for JDK-8174817), and performance
> numbers from adding a volatile read indicate that any overhead
> is lost in the noise on ImageReader-heavy workloads.
> 
> Thanks!
> 
> /Claes
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8174817

Re: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing

[Jim Laskey (Oracle)]

+1

> On Feb 14, 2017, at 9:52 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8174718
> 
> Thanks,
> -Sundar

Re: RFR 8174209: Renumber the compress levels

[Jim Laskey (Oracle)]

+1

> On Feb 13, 2017, at 1:03 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8174209/webrev/ for 
> https://bugs.openjdk.java.net/browse/JDK-8174209
> 
> Thanks,
> -Sundar

Re: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file

[Jim Laskey (Oracle)]

+1

> On Feb 13, 2017, at 1:58 PM, Denis Kononenko  
> wrote:
> 
> 
>  Hi,
> 
>  Optimized buffer's capacity checks.
> 
>  WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 
> 
> 
>> 
>> Could please someone review the fix for JDK-8169715.
>> 
>> The problem occurs when jimage tool is attempting to read an empty or
>> incomplete image. The current implementation works with ByteBuffer and
>> always relies on that there's enough data to inspect the image. This
>> results in IAE inside of BasicImageReader.slice method when the buffer
>> is smaller then it's expected.
>> 
>> I added a few checks to avoid IAE and throw IOException with a more
>> descriptive text.
>> 
>> 
>>  BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715
>>  WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01
>> 
>>  Thank you,
>>  Denis.
> 
> Thank you,
> Denis.

Re: RFR 8172864: Remove custom plugin module path

[Jim Laskey (Oracle)]

+1

> On Jan 27, 2017, at 2:45 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8172864/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8172864
> 
> Thanks,
> -Sundar

Re: RFR 8172659: PluginException("TargetPlatform attribute is missing ...") - should be ModuleTarget

[Jim Laskey (Oracle)]

+1

> On Jan 20, 2017, at 5:06 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8172659/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8172659
> 
> Thanks,
> -Sundar

Re: RFR 8168254: Detect duplicated resources in packaged modules

[Jim Laskey (Oracle)]

+1

> On Jan 18, 2017, at 2:03 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8168254/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8168254
> 
> Thanks,
> -Sundar

Re: RFR 8170618: jmod should validate if any exported or open package is missing

[Jim Laskey (Oracle)]

+1

> On Dec 21, 2016, at 8:08 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8170618/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8170618
> 
> Thanks,
> -Sundar

Re: RFR 8171316: Add IMPLEMENTOR property to the release file

[Jim Laskey (Oracle)]

+1

> On Dec 15, 2016, at 11:32 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8171316
> 
> top level webrev: http://cr.openjdk.java.net/~sundar/8171316/top/webrev.00/
> jdk webrev: http://cr.openjdk.java.net/~sundar/8171316/jdk/webrev.00/
> 
> Thanks,
> -Sundar

Re: RFR 8171138: Remove FileCopierPlugin

[Jim Laskey (Oracle)]

+1

> On Dec 14, 2016, at 1:02 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8171138/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8171138
> 
> Piggybacking cleanup: release file generation ("TOP" entry type handling) 
> moved to accept(ResourcePoolEntry)
> 
> Thanks,
> -Sundar

Re: RFR 8171070: Test ModuleNamesOrderTest.java fails

[Jim Laskey (Oracle)]

+1

> On Dec 14, 2016, at 9:37 AM, Alan Bateman  wrote:
> 
> On 14/12/2016 13:44, Sundararajan Athijegannathan wrote:
> 
>> Please review http://cr.openjdk.java.net/~sundar/8171070/webrev.00/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8171070
> Looks okay.
> 
> -Alan

Re: RFR 8168925: MODULES property should be topologically ordered and space-separated list

[Jim Laskey (Oracle)]

+1

> On Dec 9, 2016, at 4:49 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8168925/webrev.01/index.html 
> for https://bugs.openjdk.java.net/browse/JDK-8168925
> 
> PS. Mandy Chung wrote ModuleSorter for another fix (yet to be pushed).  I'm 
> using it for this fix after discussion with her (private email).
> 
> Thanks,
> -Sundar

Re: RFR 8160359: Improve jlink logging for cases when a plugin throws exception

[Jim Laskey (Oracle)]

+1

> On Nov 30, 2016, at 7:05 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8160359
> 
> jdk webrev: http://cr.openjdk.java.net/~sundar/8160359/webrev.01/
> 
> top webrev: http://cr.openjdk.java.net/~sundar/8160359/top/webrev.01/
> 
> This is mainly a debugging aid for jlink invocation - in particular from
> jdk makefiles. We'd like to get maximum info. like stack trace on
> exception from builtin plugin invocation from jdk makefiles.
> 
> Main changes from earlier round:
> 
> * Plugin.configure should throw only IllegalArgumentException (never
> PluginException)  - as suggested by Mandy earlier.
> 
> * jlink.debug turned on for JDK makefile's invocation of jlink (top
> webrev) - as suggested by Claes earlier.
> 
> Earlier round of review:
> 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010034.html
> 
> Thanks,
> 
> -Sundar
> 

Re: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory

[Jim Laskey (Oracle)]

+1

> On Nov 22, 2016, at 5:07 PM, Mandy Chung  wrote:
> 
> This patch moves src.zip and jrt-fs.jar from the top-level into
> the `lib` directory in the run-time image as we proposed [1].
> 
> Webrev:
>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/
> 
> thanks
> Mandy
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010128.html

Re: [9] RFR: 8170120: Several new jimage testcases should be excluded due to their failures

[Jim Laskey (Oracle)]

+1

> On Nov 22, 2016, at 8:51 AM, Denis Kononenko  
> wrote:
> 
> 
>  Hi,
> 
> Could someone please review this small fix.
> 
> Recently several failing test cases were delivered into jdk9-dev by my 
> mistake (https://bugs.openjdk.java.net/browse/JDK-8167240). I've just renamed 
> these test cases to temporarily avoid their execution. They should be renamed 
> back when appropriate fixes for 4 product bugs are delivered.
> Also I've fixed testcase JImageVerifyTest.testVerifyNotExistingImage, it 
> contained a regrettable error and duplicated another test case 
> (testVerifyImageNotSpecified).
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170120
> WEBREV: http://cr.openjdk.java.net/~dkononenko/8170120/webrev.00
> 
> 
> Now the tests have 100% pass rate.
> 
> JImageListTest:
> 
> Invoking testList
> jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListHelp
> jimage [list, -h]
> jimage [list, --help]
> Invoking testListVerbose
> jimage [list, --verbose, /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListIncludeAllWithGlob
> jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules]
> jimage [list, --include, **, /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListIncludeWithGlob
> jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules]
> jimage [list, --include, /java.base/java/util/zip/**, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListIncludeNoMatchWithGlob
> jimage [list, --include, not_matching, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListIncludeAllWithExplicitGlob
> jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules]
> jimage [list, --include, glob:**, /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListIncludeAllWithRegex
> jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules]
> jimage [list, --include, regex:.*, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListIncludeWithRegex
> jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules]
> jimage [list, --include, regex:/java.base/java/text/.*, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListIncludeNoMatchWithRegex
> jimage [list, --include, regex:not_matching, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListIncludeMultiplePatterns
> jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules]
> jimage [list, --include, 
> glob:/java.base/java/time/**,regex:/java.base/java/util/zip/.*, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testListNotExistingImage
> jimage [list, ./not_existing_image]
> Invoking testListWithUnknownOption
> jimage [list, --unknown]
> STDERR:
> STATUS:Passed.
> 
> 
> JImageExtractTest:
> 
> Invoking testExtract
> jimage [extract, /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testExtractHelp
> jimage [extract, --help]
> jimage [extract, --help]
> Invoking testExtractToDir
> jimage [extract, --dir, ./JImageExtractTest3092688479608335903, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testExtractNotExistingImage
> jimage [extract, ./not_existing_image]
> Invoking testExtractToUnspecifiedDir
> jimage [extract, --dir, --, /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testExtractToNotExistingDir
> jimage [extract, --dir, ./JImageExtractTest9794403129293432977, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testExtractFromDir
> jimage [extract, home/dnk/projects/oracle/jdk-9/lib]
> Invoking testExtractToDirBySymlink
> jimage [extract, --dir, ./symlink, 
> /home/dnk/projects/oracle/jdk-9/lib/modules]
> STDERR:
> STATUS:Passed.
> 
> 
> JImageVerifyTest:
> 
> Invoking testVerify
> jimage [verify, /home/dnk/projects/oracle/jdk-9/lib/modules]
> Invoking testVerifyHelp
> jimage [verify, -h]
> jimage [verify, --help]
> Invoking testVerifyNotExistingImage
> jimage [verify, ./not_existing_image]
> Invoking testVerifyWithUnknownOption
> jimage [verify, --unknown]
> STDERR:
> STATUS:Passed.
> 
> Also I need a sponsor to push the change into jdk9-dev.
> 
>  Thank you,
>  Denis.
> 
> 

RFR: JDK-8168256 - Plugin alias options in jlink --help output seems to be in an arbitrary order

[Jim Laskey (Oracle)]

Sorts options by full name

http://cr.openjdk.java.net/~jlaskey/8168256/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8168256

Re: RFR 8153038: The set of jlink plugins enabled by default should be the same via CLI or jlink API

[Jim Laskey (Oracle)]

+1

> On Nov 16, 2016, at 4:30 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8153038/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8153038
> 
> PS. Pre-existing IntegrationTest.java test already checks the Jlink API code 
> path [so, no new test added].
> 
> Thanks,
> -Sundar

RFR: JDK-8169505 - Update changes by JDK-8159393 to reflect CCC review

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8169505/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8169505

Re: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options

[Jim Laskey (Oracle)]

+1

Really nice, thank you.

> On Nov 15, 2016, at 11:16 AM, Denis Kononenko  
> wrote:
> 
> 
> Hi,
> 
> Please do re-review for these changes.
> 
> 1) tests for list --include were rewritten accordingly to 
> https://bugs.openjdk.java.net/browse/JDK-8167384;
> 2) removed tests for '@filename', see 
> https://bugs.openjdk.java.net/browse/JDK-8169720;
> 3) two new CRs were submitted: 
> https://bugs.openjdk.java.net/browse/JDK-8169715, 
> https://bugs.openjdk.java.net/browse/JDK-8169713;
> 
> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.04/
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240
> 
> Thank you,
> Denis.
> 
> 
>> Hi Andrey,
>> 
>> No, it isn't. I submitted a new CR:
>> https://bugs.openjdk.java.net/browse/JDK-8167384.
>> 
>> Thank you,
>> Denis.
>> 
>>> Hi,
>>> 
>>> Looks OK.  Is it 100% pass rate?
>>> 
>>> —Andrey
 On 9 Nov 2016, at 20:36, Denis Kononenko
>>>  wrote:
 
 
 
 Hi,
 
 After discussion with Andrey we decided to add more tests for
>> corner
>>> cases.
 The new changes are available by the link below.
 
 WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/
 BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240
 
 
 Thank you,
 Denis.
 
> Hi,
> 
> Looks OK to me.
> I can suggest two more cases. A directory and file symlink can
>> be
> passed in options where tool requires a file path. 
> 
> —Andrey
> 
>> On 8 Nov 2016, at 16:17, Denis Kononenko
>  wrote:
>> 
>> 
>> Hi,
>> 
>> The new version of changes.
>> 
>> - Switched back to jdk/test/testlibrary to avoid unwanted
> dependencies (JImageToolTest.java);
>> - Verified tests on smallest possible JDK build.
>> 
>> WEBREV:
>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240
>> 
>> Thank you,
>> Denis.
>> 
>>> Denis,
>>> 
>>> I can see that you have switched to the top level test library
> with
>>> this change. With that you are getting more module
>> dependencies
> than 
>>> just java.base. First of all, it would probably make sense to
> build
>>> only the classes you needed (which would be 
>>> jdk.test.lib.process.ProcessTools, I assume), but even if you
>>> only
>>> build that, jdk.test.lib.process.ProcessTools has dependencies
> outside
>>> java.base module.
>>> 
>>> You either have to declare @modules in your test or go back to
>>> the
>>> jdk/test/lib/testlibrary. Then, of course, unneeded module
>>> dependencies are questionable.
>>> 
>>> Shura
>>> 
>>> 
 On Nov 3, 2016, at 6:29 AM, Denis Kononenko
>>>  wrote:
 
 Hi,
 
 I've done some rework accordingly to Alan's and Shura's
>>> comments:
 
 1) removed overlapped tests from JImageToolTest.java;
 
 2) added new tests JImageVerifyTest.java for jimage verify;
 
 3) reorganized jtreg's tags;
 
 The new WEBREV can be found here:
>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/
 
 Thank you,
 Denis.
 
 On 06.10.2016 19:37, Denis Kononenko wrote:
> Hi,
> 
> Could someone please review these new tests for jimage
>>> utility.
> 
> There're 5 new files containing tests to cover use cases for
>>> 'info', 'list', 'extract' and other options. No new tests for
>>> 'verify'.
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240
> WEBREV:
> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/
> 
> 
> Thank you,
> Denis.
 

RFR: JDK-8169720 - jimage help message for --include option should be corrected

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8169720/webrev/index.html 

https://bugs.openjdk.java.net/browse/JDK-8169720 

RFR: JDK-8155756 - Better context for some jlink exceptions

[Jim Laskey (Oracle)]

Only 2 of 3 examples still present.

http://cr.openjdk.java.net/~jlaskey/8155756/webrev/index.html 

https://bugs.openjdk.java.net/browse/JDK-8155756 

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

Suits me.


> On Nov 7, 2016, at 12:06 PM, Sean Mullan <sean.mul...@oracle.com> wrote:
> 
> On 11/7/16 9:13 AM, Jim Laskey (Oracle) wrote:
>> The bug https://bugs.openjdk.java.net/browse/JDK-8159393
>> <https://bugs.openjdk.java.net/browse/JDK-8159393> is really about
>> warning developers that their image does not support signing.  If
>> they are okay with that then they can override with
>> --strip-signing-information.
> 
> I find the option name --strip-signing-information a little bit confusing. To 
> me this implies jlink might remove the signature information from the 
> original signed modular JAR, which is not what you are doing, correct? Why 
> not call it "--ignore-signing-information"?
> 
> --Sean
> 
>> 
>> — Jim
>> 
>> 
>> 
>>> On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle)
>>> <james.las...@oracle.com> wrote:
>>> 
>>> The security entries are (have been) ignored when building the
>>> image.  At some future date (post-9), we need to decide how to sign
>>> an image.
>>> 
>>> — Jim
>>> 
>>> 
>>>> On Nov 7, 2016, at 10:06 AM, Wang Weijun <weijun.w...@oracle.com>
>>>> wrote:
>>>> 
>>>> The code block below checking if a jar file was signed is
>>>> correct.
>>>> 
>>>> There is one thing I don't understand, the
>>>> --strip-signing-information option. It looks like you will remove
>>>> the signature-related files if this option is set. But, where are
>>>> they stripped?
>>>> 
>>>> Thanks Max
>>>> 
>>>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote:
>>>>> Apologies for the poor links earlier.
>>>>> 
>>>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
>>>>> https://bugs.openjdk.java.net/browse/JDK-8159393
>>>>> 
>>>>> 
>>>>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle)
>>>>>> <james.las...@oracle.com> wrote:
>>>>>> 
>>>>>> Revising to
>>>>>> 
>>>>>> String name = entry.name().toUpperCase(Locale.ENGLISH);
>>>>>> 
>>>>>> return name.startsWith("META-INF/") && name.indexOf('/', 9)
>>>>>> == -1 && ( name.endsWith(".SF") || name.endsWith(".DSA") ||
>>>>>> name.endsWith(".RSA") || name.endsWith(".EC") ||
>>>>>> name.startsWith("META-INF/SIG-") );
>>>>>> 
>>>>>> 
>>>>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle)
>>>>>>> <james.las...@oracle.com> wrote:
>>>>>>> 
>>>>>>> Right.  From SignatureFileVerifier.java
>>>>>>> 
>>>>>>> 
>>>>>>> /** * Utility method used by JarVerifier and JarSigner * to
>>>>>>> determine the signature file names and PKCS7 block * files
>>>>>>> names that are supported * * @param s file name * @return
>>>>>>> true if the input file name is a supported *
>>>>>>> Signature File or PKCS7 block file name */ public static
>>>>>>> boolean isBlockOrSF(String s) { // we currently only
>>>>>>> support DSA and RSA PKCS7 blocks return s.endsWith(".SF")
>>>>>>> || s.endsWith(".DSA") || s.endsWith(".RSA") ||
>>>>>>> s.endsWith(".EC"); }
>>>>>>> 
>>>>>>> /** * Yet another utility method used by JarVerifier and
>>>>>>> JarSigner * to determine what files are signature related,
>>>>>>> which includes * the MANIFEST, SF files, known signature
>>>>>>> block files, and other * unknown signature related files
>>>>>>> (those starting with SIG- with * an optional [A-Z0-9]{1,3}
>>>>>>> extension right inside META-INF). * * @param name file
>>>>>>> name * @return true if the input file name is signature
>>>>>>> related */ public static boolean isSigningRelated(String
>>>>>>> name) { name = name.toUpperCase(Locale.ENGLISH); if
>>>>>>> (!name.startsWith("META-INF/")) { return false; } name =
>>>>>>> name.substring(9); if (name.indexOf('/') != -1) { return
>>>>>>> false; } if (isBlockOrSF(name) ||
>>>>>>> name.equals("MANIFEST.MF")) { return true; } else if
>>>>>>> (name.startsWith("SIG-")) { // check filename extension //
>>>>>>> see
>>>>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures
>>>>>>> 
>>>>>>> 
> // for what filename extensions are legal
>>>>>>> int extIndex = name.lastIndexOf('.'); if (extIndex != -1)
>>>>>>> { String ext = name.substring(extIndex + 1); // validate
>>>>>>> length first if (ext.length() > 3 || ext.length() < 1) {
>>>>>>> return false; } // then check chars, must be in [a-zA-Z0-9]
>>>>>>> per the jar spec for (int index = 0; index < ext.length();
>>>>>>> index++) { char cc = ext.charAt(index); // chars are
>>>>>>> promoted to uppercase so skip lowercase checks if ((cc <
>>>>>>> 'A' || cc > 'Z') && (cc < '0' || cc > '9')) { return
>>>>>>> false; } } } return true; // no extension is OK } return
>>>>>>> false; }
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman
>>>>>>>> <alan.bate...@oracle.com> wrote:
>>>>>>>> 
>>>>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote:
>>>>>>>> 
>>>>>>>>> Thank you.  Regarding SIG- I was just followed the
>>>>>>>>> spec.
>>>>>>>>> 
>>>>>>>> I hope Sean or Max can jump in on this, the other
>>>>>>>> question is .EC as I believe the JDK allows this when
>>>>>>>> signing too.
>>>>>>>> 
>>>>>>>> -Alan
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

It’s the lack of inclusion as oppose to exclusion.

> On Nov 7, 2016, at 10:33 AM, Wang Weijun <weijun.w...@oracle.com> wrote:
> 
> Great. I asked the question because you will need the exact same check to 
> determine what files should be ignored and I thought they should appear in 
> the same webrev. If it's already done somewhere else please make sure it is 
> the same. 
> 
> Thanks
> Max
> 
>> 在 2016年11月7日，22:11，Jim Laskey (Oracle) <james.las...@oracle.com> 写道：
>> 
>> The security entries are (have been) ignored when building the image.  At 
>> some future date (post-9), we need to decide how to sign an image.
>> 
>> — Jim
>> 
>> 
>>> On Nov 7, 2016, at 10:06 AM, Wang Weijun <weijun.w...@oracle.com> wrote:
>>> 
>>> The code block below checking if a jar file was signed is correct.
>>> 
>>> There is one thing I don't understand, the --strip-signing-information 
>>> option. It looks like you will remove the signature-related files if this 
>>> option is set. But, where are they stripped?
>>> 
>>> Thanks
>>> Max
>>> 
>>>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote:
>>>> Apologies for the poor links earlier.
>>>> 
>>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
>>>> https://bugs.openjdk.java.net/browse/JDK-8159393
>>>> 
>>>> 
>>>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>>>>> wrote:
>>>>> 
>>>>> Revising to
>>>>> 
>>>>> String name = entry.name().toUpperCase(Locale.ENGLISH);
>>>>> 
>>>>> return name.startsWith("META-INF/") && name.indexOf('/', 
>>>>> 9) == -1 && (
>>>>> name.endsWith(".SF") ||
>>>>> name.endsWith(".DSA") ||
>>>>> name.endsWith(".RSA") ||
>>>>> name.endsWith(".EC") ||
>>>>> name.startsWith("META-INF/SIG-")
>>>>> );
>>>>> 
>>>>> 
>>>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) 
>>>>>> <james.las...@oracle.com> wrote:
>>>>>> 
>>>>>> Right.  From SignatureFileVerifier.java
>>>>>> 
>>>>>> 
>>>>>> /**
>>>>>> * Utility method used by JarVerifier and JarSigner
>>>>>> * to determine the signature file names and PKCS7 block
>>>>>> * files names that are supported
>>>>>> *
>>>>>> * @param s file name
>>>>>> * @return true if the input file name is a supported
>>>>>> *  Signature File or PKCS7 block file name
>>>>>> */
>>>>>> public static boolean isBlockOrSF(String s) {
>>>>>>// we currently only support DSA and RSA PKCS7 blocks
>>>>>>return s.endsWith(".SF")
>>>>>>|| s.endsWith(".DSA")
>>>>>>|| s.endsWith(".RSA")
>>>>>>|| s.endsWith(".EC");
>>>>>> }
>>>>>> 
>>>>>> /**
>>>>>> * Yet another utility method used by JarVerifier and JarSigner
>>>>>> * to determine what files are signature related, which includes
>>>>>> * the MANIFEST, SF files, known signature block files, and other
>>>>>> * unknown signature related files (those starting with SIG- with
>>>>>> * an optional [A-Z0-9]{1,3} extension right inside META-INF).
>>>>>> *
>>>>>> * @param name file name
>>>>>> * @return true if the input file name is signature related
>>>>>> */
>>>>>> public static boolean isSigningRelated(String name) {
>>>>>>name = name.toUpperCase(Locale.ENGLISH);
>>>>>>if (!name.startsWith("META-INF/")) {
>>>>>>return false;
>>>>>>}
>>>>>>name = name.substring(9);
>>>>>>if (name.indexOf('/') != -1) {
>>>>>>return false;
>>>>>>}
>>>>>>if (isBlockOrSF(name) || name.

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

The bug https://bugs.openjdk.java.net/browse/JDK-8159393 
<https://bugs.openjdk.java.net/browse/JDK-8159393> is really about warning 
developers that their image does not support signing.  If they are okay with 
that then they can override with --strip-signing-information.

— Jim



> On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> The security entries are (have been) ignored when building the image.  At 
> some future date (post-9), we need to decide how to sign an image.
> 
> — Jim
> 
> 
>> On Nov 7, 2016, at 10:06 AM, Wang Weijun <weijun.w...@oracle.com> wrote:
>> 
>> The code block below checking if a jar file was signed is correct.
>> 
>> There is one thing I don't understand, the --strip-signing-information 
>> option. It looks like you will remove the signature-related files if this 
>> option is set. But, where are they stripped?
>> 
>> Thanks
>> Max
>> 
>> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote:
>>> Apologies for the poor links earlier.
>>> 
>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
>>> https://bugs.openjdk.java.net/browse/JDK-8159393
>>> 
>>> 
>>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>>>> wrote:
>>>> 
>>>> Revising to
>>>> 
>>>>  String name = entry.name().toUpperCase(Locale.ENGLISH);
>>>> 
>>>>  return name.startsWith("META-INF/") && name.indexOf('/', 
>>>> 9) == -1 && (
>>>>  name.endsWith(".SF") ||
>>>>  name.endsWith(".DSA") ||
>>>>  name.endsWith(".RSA") ||
>>>>  name.endsWith(".EC") ||
>>>>  name.startsWith("META-INF/SIG-")
>>>>  );
>>>> 
>>>> 
>>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>>>>> wrote:
>>>>> 
>>>>> Right.  From SignatureFileVerifier.java
>>>>> 
>>>>> 
>>>>> /**
>>>>>  * Utility method used by JarVerifier and JarSigner
>>>>>  * to determine the signature file names and PKCS7 block
>>>>>  * files names that are supported
>>>>>  *
>>>>>  * @param s file name
>>>>>  * @return true if the input file name is a supported
>>>>>  *  Signature File or PKCS7 block file name
>>>>>  */
>>>>> public static boolean isBlockOrSF(String s) {
>>>>> // we currently only support DSA and RSA PKCS7 blocks
>>>>> return s.endsWith(".SF")
>>>>> || s.endsWith(".DSA")
>>>>> || s.endsWith(".RSA")
>>>>> || s.endsWith(".EC");
>>>>> }
>>>>> 
>>>>> /**
>>>>>  * Yet another utility method used by JarVerifier and JarSigner
>>>>>  * to determine what files are signature related, which includes
>>>>>  * the MANIFEST, SF files, known signature block files, and other
>>>>>  * unknown signature related files (those starting with SIG- with
>>>>>  * an optional [A-Z0-9]{1,3} extension right inside META-INF).
>>>>>  *
>>>>>  * @param name file name
>>>>>  * @return true if the input file name is signature related
>>>>>  */
>>>>> public static boolean isSigningRelated(String name) {
>>>>> name = name.toUpperCase(Locale.ENGLISH);
>>>>> if (!name.startsWith("META-INF/")) {
>>>>> return false;
>>>>> }
>>>>> name = name.substring(9);
>>>>> if (name.indexOf('/') != -1) {
>>>>> return false;
>>>>> }
>>>>> if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) {
>>>>> return true;
>>>>> } else if (name.startsWith("SIG-")) {
>>>>>     // check filename extension
>>>>> // see 
>>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures
>>>>> // for what filename extensions are legal
>>>>> int extIndex = name.lastIndexOf('.');
>>>>> if (extIndex != -1) {
>>>>> String ext = name.substring(extIndex + 1);
>>>>> // validate length first
>>>>> if (ext.length() > 3 || ext.length() < 1) {
>>>>> return false;
>>>>> }
>>>>> // then check chars, must be in [a-zA-Z0-9] per the jar spec
>>>>> for (int index = 0; index < ext.length(); index++) {
>>>>> char cc = ext.charAt(index);
>>>>> // chars are promoted to uppercase so skip lowercase 
>>>>> checks
>>>>> if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) {
>>>>> return false;
>>>>> }
>>>>> }
>>>>> }
>>>>> return true; // no extension is OK
>>>>> }
>>>>> return false;
>>>>> }
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
>>>>>> 
>>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote:
>>>>>> 
>>>>>>> Thank you.  Regarding SIG- I was just followed the spec.
>>>>>>> 
>>>>>> I hope Sean or Max can jump in on this, the other question is .EC as I 
>>>>>> believe the JDK allows this when signing too.
>>>>>> 
>>>>>> -Alan
>>>>> 
>>>> 
>>> 
> 

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

The security entries are (have been) ignored when building the image.  At some 
future date (post-9), we need to decide how to sign an image.

— Jim


> On Nov 7, 2016, at 10:06 AM, Wang Weijun <weijun.w...@oracle.com> wrote:
> 
> The code block below checking if a jar file was signed is correct.
> 
> There is one thing I don't understand, the --strip-signing-information 
> option. It looks like you will remove the signature-related files if this 
> option is set. But, where are they stripped?
> 
> Thanks
> Max
> 
> On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote:
>> Apologies for the poor links earlier.
>> 
>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8159393
>> 
>> 
>>> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>>> wrote:
>>> 
>>> Revising to
>>> 
>>>   String name = entry.name().toUpperCase(Locale.ENGLISH);
>>> 
>>>   return name.startsWith("META-INF/") && name.indexOf('/', 
>>> 9) == -1 && (
>>>   name.endsWith(".SF") ||
>>>   name.endsWith(".DSA") ||
>>>           name.endsWith(".RSA") ||
>>>   name.endsWith(".EC") ||
>>>   name.startsWith("META-INF/SIG-")
>>>   );
>>> 
>>> 
>>>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>>>> wrote:
>>>> 
>>>> Right.  From SignatureFileVerifier.java
>>>> 
>>>> 
>>>>  /**
>>>>   * Utility method used by JarVerifier and JarSigner
>>>>   * to determine the signature file names and PKCS7 block
>>>>   * files names that are supported
>>>>   *
>>>>   * @param s file name
>>>>   * @return true if the input file name is a supported
>>>>   *  Signature File or PKCS7 block file name
>>>>   */
>>>>  public static boolean isBlockOrSF(String s) {
>>>>  // we currently only support DSA and RSA PKCS7 blocks
>>>>  return s.endsWith(".SF")
>>>>  || s.endsWith(".DSA")
>>>>  || s.endsWith(".RSA")
>>>>  || s.endsWith(".EC");
>>>>  }
>>>> 
>>>>  /**
>>>>   * Yet another utility method used by JarVerifier and JarSigner
>>>>   * to determine what files are signature related, which includes
>>>>   * the MANIFEST, SF files, known signature block files, and other
>>>>   * unknown signature related files (those starting with SIG- with
>>>>   * an optional [A-Z0-9]{1,3} extension right inside META-INF).
>>>>   *
>>>>   * @param name file name
>>>>   * @return true if the input file name is signature related
>>>>   */
>>>>  public static boolean isSigningRelated(String name) {
>>>>  name = name.toUpperCase(Locale.ENGLISH);
>>>>  if (!name.startsWith("META-INF/")) {
>>>>  return false;
>>>>  }
>>>>  name = name.substring(9);
>>>>  if (name.indexOf('/') != -1) {
>>>>  return false;
>>>>  }
>>>>  if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) {
>>>>  return true;
>>>>  } else if (name.startsWith("SIG-")) {
>>>>  // check filename extension
>>>>  // see 
>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures
>>>>  // for what filename extensions are legal
>>>>  int extIndex = name.lastIndexOf('.');
>>>>  if (extIndex != -1) {
>>>>  String ext = name.substring(extIndex + 1);
>>>>  // validate length first
>>>>  if (ext.length() > 3 || ext.length() < 1) {
>>>>  return false;
>>>>  }
>>>>  // then check chars, must be in [a-zA-Z0-9] per the jar spec
>>>>  for (int index = 0; index < ext.length(); index++) {
>>>>  char cc = ext.charAt(index);
>>>>  // chars are promoted to uppercase so skip lowercase 
>>>> checks
>>>>  if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) {
>>>>  return false;
>>>>  }
>>>>  }
>>>>  }
>>>>  return true; // no extension is OK
>>>>  }
>>>>  return false;
>>>>  }
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
>>>>> 
>>>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote:
>>>>> 
>>>>>> Thank you.  Regarding SIG- I was just followed the spec.
>>>>>> 
>>>>> I hope Sean or Max can jump in on this, the other question is .EC as I 
>>>>> believe the JDK allows this when signing too.
>>>>> 
>>>>> -Alan
>>>> 
>>> 
>> 

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

Apologies for the poor links earlier.

http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8159393


> On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> Revising to
> 
>String name = entry.name().toUpperCase(Locale.ENGLISH);
> 
>return name.startsWith("META-INF/") && name.indexOf('/', 
> 9) == -1 && (
>name.endsWith(".SF") ||
>name.endsWith(".DSA") ||
>name.endsWith(".RSA") ||
>name.endsWith(".EC") ||
>        name.startsWith("META-INF/SIG-")
>);
> 
> 
>> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>> wrote:
>> 
>> Right.  From SignatureFileVerifier.java
>> 
>> 
>>   /**
>>* Utility method used by JarVerifier and JarSigner
>>* to determine the signature file names and PKCS7 block
>>* files names that are supported
>>*
>>* @param s file name
>>* @return true if the input file name is a supported
>>*  Signature File or PKCS7 block file name
>>*/
>>   public static boolean isBlockOrSF(String s) {
>>   // we currently only support DSA and RSA PKCS7 blocks
>>   return s.endsWith(".SF")
>>   || s.endsWith(".DSA")
>>   || s.endsWith(".RSA")
>>   || s.endsWith(".EC");
>>   }
>> 
>>   /**
>>* Yet another utility method used by JarVerifier and JarSigner
>>* to determine what files are signature related, which includes
>>* the MANIFEST, SF files, known signature block files, and other
>>* unknown signature related files (those starting with SIG- with
>>* an optional [A-Z0-9]{1,3} extension right inside META-INF).
>>*
>>* @param name file name
>>* @return true if the input file name is signature related
>>*/
>>   public static boolean isSigningRelated(String name) {
>>   name = name.toUpperCase(Locale.ENGLISH);
>>   if (!name.startsWith("META-INF/")) {
>>   return false;
>>   }
>>   name = name.substring(9);
>>   if (name.indexOf('/') != -1) {
>>   return false;
>>   }
>>   if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) {
>>   return true;
>>   } else if (name.startsWith("SIG-")) {
>>   // check filename extension
>>   // see 
>> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures
>>   // for what filename extensions are legal
>>   int extIndex = name.lastIndexOf('.');
>>   if (extIndex != -1) {
>>   String ext = name.substring(extIndex + 1);
>>   // validate length first
>>   if (ext.length() > 3 || ext.length() < 1) {
>>   return false;
>>   }
>>   // then check chars, must be in [a-zA-Z0-9] per the jar spec
>>   for (int index = 0; index < ext.length(); index++) {
>>   char cc = ext.charAt(index);
>>   // chars are promoted to uppercase so skip lowercase checks
>>   if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) {
>>   return false;
>>   }
>>   }
>>   }
>>   return true; // no extension is OK
>>   }
>>   return false;
>>   }
>> 
>> 
>> 
>> 
>> 
>>> On Nov 7, 2016, at 9:16 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
>>> 
>>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote:
>>> 
>>>> Thank you.  Regarding SIG- I was just followed the spec.
>>>> 
>>> I hope Sean or Max can jump in on this, the other question is .EC as I 
>>> believe the JDK allows this when signing too.
>>> 
>>> -Alan
>> 
> 

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

Revising to

String name = entry.name().toUpperCase(Locale.ENGLISH);

return name.startsWith("META-INF/") && name.indexOf('/', 9) 
== -1 && (
name.endsWith(".SF") ||
name.endsWith(".DSA") ||
name.endsWith(".RSA") ||
name.endsWith(".EC") ||
name.startsWith("META-INF/SIG-")
    );


> On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> Right.  From SignatureFileVerifier.java
> 
> 
>/**
> * Utility method used by JarVerifier and JarSigner
> * to determine the signature file names and PKCS7 block
> * files names that are supported
> *
> * @param s file name
> * @return true if the input file name is a supported
> *  Signature File or PKCS7 block file name
> */
>public static boolean isBlockOrSF(String s) {
>// we currently only support DSA and RSA PKCS7 blocks
>return s.endsWith(".SF")
>|| s.endsWith(".DSA")
>|| s.endsWith(".RSA")
>|| s.endsWith(".EC");
>}
> 
>/**
> * Yet another utility method used by JarVerifier and JarSigner
> * to determine what files are signature related, which includes
> * the MANIFEST, SF files, known signature block files, and other
> * unknown signature related files (those starting with SIG- with
> * an optional [A-Z0-9]{1,3} extension right inside META-INF).
> *
> * @param name file name
> * @return true if the input file name is signature related
> */
>public static boolean isSigningRelated(String name) {
>name = name.toUpperCase(Locale.ENGLISH);
>if (!name.startsWith("META-INF/")) {
>return false;
>}
>name = name.substring(9);
>if (name.indexOf('/') != -1) {
>return false;
>}
>if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) {
>return true;
>} else if (name.startsWith("SIG-")) {
>// check filename extension
>// see 
> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures
>// for what filename extensions are legal
>int extIndex = name.lastIndexOf('.');
>if (extIndex != -1) {
>String ext = name.substring(extIndex + 1);
>// validate length first
>if (ext.length() > 3 || ext.length() < 1) {
>return false;
>}
>// then check chars, must be in [a-zA-Z0-9] per the jar spec
>for (int index = 0; index < ext.length(); index++) {
>char cc = ext.charAt(index);
>// chars are promoted to uppercase so skip lowercase checks
>if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) {
>return false;
>}
>}
>}
>return true; // no extension is OK
>}
>return false;
>}
> 
> 
> 
> 
> 
>> On Nov 7, 2016, at 9:16 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
>> 
>> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote:
>> 
>>> Thank you.  Regarding SIG- I was just followed the spec.
>>> 
>> I hope Sean or Max can jump in on this, the other question is .EC as I 
>> believe the JDK allows this when signing too.
>> 
>> -Alan
> 

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

Right.  From SignatureFileVerifier.java


/**
 * Utility method used by JarVerifier and JarSigner
 * to determine the signature file names and PKCS7 block
 * files names that are supported
 *
 * @param s file name
 * @return true if the input file name is a supported
 *  Signature File or PKCS7 block file name
 */
public static boolean isBlockOrSF(String s) {
// we currently only support DSA and RSA PKCS7 blocks
return s.endsWith(".SF")
|| s.endsWith(".DSA")
|| s.endsWith(".RSA")
|| s.endsWith(".EC");
}

/**
 * Yet another utility method used by JarVerifier and JarSigner
 * to determine what files are signature related, which includes
 * the MANIFEST, SF files, known signature block files, and other
 * unknown signature related files (those starting with SIG- with
 * an optional [A-Z0-9]{1,3} extension right inside META-INF).
 *
 * @param name file name
 * @return true if the input file name is signature related
 */
public static boolean isSigningRelated(String name) {
name = name.toUpperCase(Locale.ENGLISH);
if (!name.startsWith("META-INF/")) {
return false;
}
name = name.substring(9);
if (name.indexOf('/') != -1) {
return false;
}
if (isBlockOrSF(name) || name.equals("MANIFEST.MF")) {
return true;
} else if (name.startsWith("SIG-")) {
// check filename extension
// see 
http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures
// for what filename extensions are legal
int extIndex = name.lastIndexOf('.');
if (extIndex != -1) {
String ext = name.substring(extIndex + 1);
// validate length first
if (ext.length() > 3 || ext.length() < 1) {
return false;
}
// then check chars, must be in [a-zA-Z0-9] per the jar spec
for (int index = 0; index < ext.length(); index++) {
char cc = ext.charAt(index);
// chars are promoted to uppercase so skip lowercase checks
if ((cc < 'A' || cc > 'Z') && (cc < '0' || cc > '9')) {
return false;
}
}
}
return true; // no extension is OK
}
return false;
}





> On Nov 7, 2016, at 9:16 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 07/11/2016 13:09, Jim Laskey (Oracle) wrote:
> 
>> Thank you.  Regarding SIG- I was just followed the spec.
>> 
> I hope Sean or Max can jump in on this, the other question is .EC as I 
> believe the JDK allows this when signing too.
> 
> -Alan

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

But I need to be more careful with "Note that if such files are located in 
META-INF subdirectories, they are not considered signature-related.”


> On Nov 7, 2016, at 9:09 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> Thank you.  Regarding SIG- I was just followed the spec.
> 
> 
> Signed JAR File
> <>Overview
> A JAR file can be signed by using the command line jarsigner 
> <http://docs.oracle.com/javase/7/docs/technotes/guides/security/SecurityToolsSummary.html>
>  tool or directly through the java.security API. Every file entry, including 
> non-signature related files in the META-INF directory, will be signed if the 
> JAR file is signed by the jarsigner tool. The signature related files are:
> META-INF/MANIFEST.MF
> META-INF/*.SF
> META-INF/*.DSA
> META-INF/*.RSA
> META-INF/SIG-*
> Note that if such files are located in META-INF subdirectories, they are not 
> considered signature-related. Case-insensitive versions of these filenames 
> are reserved and will also not be signed.
> Subsets of a JAR file can be signed by using the java.security API. A signed 
> JAR file is exactly the same as the original JAR file, except that its 
> manifest is updated and two additional files are added to the META-INF 
> directory: a signature file and a signature block file. When jarsigner is not 
> used, the signing program has to construct both the signature file and the 
> signature block file.
> 
> 
>> On Nov 7, 2016, at 8:40 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
>> 
>> 
>> n 07/11/2016 12:29, Jim Laskey (Oracle) wrote:
>>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html
>>>  
>>> <http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html>
>>> https://bugs.openjdk.java.net/browse/JDK-8159393
>>> 
>> I think this is the link:
>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
>> 
>> I hope someone from the security area will be able to help review this. One 
>> thing that isn't clear to me is whether the check for META-INF/SIG-* is 
>> right. Also I assume you need to toUpperCase(Locale.ENGLISH) to align with 
>> how JAR file verification checks for signed JARs.
>> 
>> In passing, should the usage and warning use "modular JAR" rather than 
>> "modular jar"?
>> 
>> -Alan
>> 
> 

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

Thank you.  Regarding SIG- I was just followed the spec.


Signed JAR File
 <>Overview
A JAR file can be signed by using the command line jarsigner 
<http://docs.oracle.com/javase/7/docs/technotes/guides/security/SecurityToolsSummary.html>
 tool or directly through the java.security API. Every file entry, including 
non-signature related files in the META-INF directory, will be signed if the 
JAR file is signed by the jarsigner tool. The signature related files are:
META-INF/MANIFEST.MF
META-INF/*.SF
META-INF/*.DSA
META-INF/*.RSA
META-INF/SIG-*
Note that if such files are located in META-INF subdirectories, they are not 
considered signature-related. Case-insensitive versions of these filenames are 
reserved and will also not be signed.
Subsets of a JAR file can be signed by using the java.security API. A signed 
JAR file is exactly the same as the original JAR file, except that its manifest 
is updated and two additional files are added to the META-INF directory: a 
signature file and a signature block file. When jarsigner is not used, the 
signing program has to construct both the signature file and the signature 
block file.


> On Nov 7, 2016, at 8:40 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> 
> n 07/11/2016 12:29, Jim Laskey (Oracle) wrote:
>> http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html
>>  
>> <http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html>
>> https://bugs.openjdk.java.net/browse/JDK-8159393
>> 
> I think this is the link:
>  http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
> 
> I hope someone from the security area will be able to help review this. One 
> thing that isn't clear to me is whether the check for META-INF/SIG-* is 
> right. Also I assume you need to toUpperCase(Locale.ENGLISH) to align with 
> how JAR file verification checks for signed JARs.
> 
> In passing, should the usage and warning use "modular JAR" rather than 
> "modular jar"?
> 
> -Alan
> 

RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8159393/webrev/test/tools/jlink/JLinkSigningTest.java.html
 

https://bugs.openjdk.java.net/browse/JDK-8159393

Re: RFR 8166286: jmod fails on symlink to directory

[Jim Laskey (Oracle)]

+1

> On Nov 4, 2016, at 7:36 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8166286/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8166286
> 
> Thanks,
> -Sundar

Re: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options

[Jim Laskey (Oracle)]

Nice work. +1



> On Nov 3, 2016, at 10:29 AM, Denis Kononenko  
> wrote:
> 
> Hi,
> 
> I've done some rework accordingly to Alan's and Shura's comments:
> 
> 1) removed overlapped tests from JImageToolTest.java;
> 
> 2) added new tests JImageVerifyTest.java for jimage verify;
> 
> 3) reorganized jtreg's tags;
> 
> The new WEBREV can be found here: 
> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/
> 
> Thank you,
> Denis.
> 
> On 06.10.2016 19:37, Denis Kononenko wrote:
>> Hi,
>> 
>> Could someone please review these new tests for jimage utility.
>> 
>> There're 5 new files containing tests to cover use cases for 'info', 'list', 
>> 'extract' and other options. No new tests for 'verify'.
>> 
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240
>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/
>> 
>> 
>> Thank you,
>> Denis.
> 

Re: RFR 8160063: Provide a means to disable a plugin via the command line

[Jim Laskey (Oracle)]

+1

> On Oct 31, 2016, at 12:11 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.02/ for 
> https://bugs.openjdk.java.net/browse/JDK-8160063
> 
> PS. Earlier review thread on slightly different fix: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009392.html
> 
> Thanks,
> -Sundar

Re: RFR 8166810: jlink should fail on extra arguments

[Jim Laskey (Oracle)]

+1

> On Oct 25, 2016, at 2:37 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8166810/webrev.00/index.html 
> for https://bugs.openjdk.java.net/browse/JDK-8166810
> 
> Thanks,
> -Sundar

Re: RFR 8168091: jlink should check security permission early when programmatic access is used

[Jim Laskey (Oracle)]

+1

> On Oct 17, 2016, at 2:23 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8168091/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8168091
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Jim Laskey (Oracle)]

+1

> On Oct 12, 2016, at 12:11 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167614
> 
> jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/
> 
> nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8165735: jlink incorrectly accepts multiple --module-path and --limit-modules options

[Jim Laskey (Oracle)]

+1

> On Sep 28, 2016, at 7:36 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8165735/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8165735
> 
> Thanks,
> -Sundar

Re: RFR 8160063: Provide a means to disable a plugin via the command line

[Jim Laskey (Oracle)]

+1

> On Sep 15, 2016, at 11:31 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for 
> https://bugs.openjdk.java.net/browse/JDK-8160063
> 
> * Adding --disable- option for any plugin that is auto-enabled.
> * Removed ad-hoc "none" option of generate-jli-classes plugin.
> * Simple test to make sure --disable-generate-jli-classes option is accepted.
> * Manual verified that when generate-jli-classes plugin is deactivated, JLI 
> classes are not generated.
> 
> Thanks,
> -Sundar
> 

Re: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java

[Jim Laskey (Oracle)]

+1

> On Sep 12, 2016, at 9:32 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165772
> 
> This VersionCheck.java test failed after main class was added to nashorn
> modules. VersionCheck expects all jdk/bin tools to be derived from the
> standard launcher. But, jlink generates shell scripts and batch files
> for modules with main class.  I'm reverting back nashorn module main
> class addition makefile change and also removing VersionCheck from
> ProblemList.txt:
> 
> Webrevs:
> 
> Top: http://cr.openjdk.java.net/~sundar/8165772/top/webrev.02/
> 
> Jdk: http://cr.openjdk.java.net/~sundar/8165772/jdk/webrev.02/
> 
> I'm withdrawing my earlier jlink fix attempt:
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009339.html
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java

[Jim Laskey (Oracle)]

+1

> On Sep 9, 2016, at 10:58 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8165772/webrev.01/ for
> https://bugs.openjdk.java.net/browse/JDK-8165772
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8165697: jlink running on Mac with Windows jmods produces non-runnable image

[Jim Laskey (Oracle)]

+1

> On Sep 8, 2016, at 11:32 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8165697/webrev.01/ for
> https://bugs.openjdk.java.net/browse/JDK-8165697
> 
> Thanks
> 
> -Sundar
> 

Re: RFR 8165503: jlink exclude VM plugin's handling of jvmlibs is wrong

[Jim Laskey (Oracle)]

+1

> On Sep 7, 2016, at 8:43 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8165503/webrev.01/ for
> https://bugs.openjdk.java.net/browse/JDK-8165503
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8163952: jlink exclude VM plugin does not support static libraries

[Jim Laskey (Oracle)]

I missed that as well.  Good catch.


> On Sep 6, 2016, at 11:50 AM, Anthony Vanelverdinghe 
>  wrote:
> 
> Hi Sundar
> 
> I'm not familiar with the code, but the for-loop at lines 105-107 looks like 
> a bug, since only the first element is considered:
> 
> 105 for (String jvmlib : jvmlibs) {
> 106 return t.path().endsWith("/" + jvmlib);
> 107 }
> 
> Kind regards,
> Anthony
> 
> 
> On 6/09/2016 12:12, Sundararajan Athijegannathan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for
>> https://bugs.openjdk.java.net/browse/JDK-8163952
>> 
>> Thanks,
>> 
>> -Sundar
>> 
> 

Re: RFR 8163952: jlink exclude VM plugin does not support static libraries

[Jim Laskey (Oracle)]

+1

> On Sep 6, 2016, at 7:12 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for
> https://bugs.openjdk.java.net/browse/JDK-8163952
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8157992: Improve jlink help message on optimization-related options

[Jim Laskey (Oracle)]

+1

> On Sep 2, 2016, at 6:10 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Cleas, Alan:
> 
> Thanks for the reviews. Uploaded updated webrev for the record:
> http://cr.openjdk.java.net/~sundar/8157992/webrev.02/
> 
> And going ahead with push..
> 
> Thanks.
> 
> -Sundar
> 
> 
> On 9/2/2016 1:42 PM, Alan Bateman wrote:
>> On 02/09/2016 07:07, Sundararajan Athijegannathan wrote:
>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/
>>> for https://bugs.openjdk.java.net/browse/JDK-8157992
>>> 
>> "details" should have one "d" :-)   Looks fine otherwise.
> 

Re: RFR 8159004: jlink attempts to create launcher scripts when root/bin dir does not exist

[Jim Laskey (Oracle)]

+1

> On Aug 29, 2016, at 9:00 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8159004/webrev.01/ for 
> https://bugs.openjdk.java.net/browse/JDK-8159004
> 
> Piggybacking couple of cleanups suggested (but missed) in this thread -> 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009186.html
> 
> 
> Thanks,
> -Sundar

Re: RFR 8164800: Cross targeting Windows

[Jim Laskey (Oracle)]

+1

> On Aug 26, 2016, at 11:54 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Hi,
> 
> Fixed as suggested: http://cr.openjdk.java.net/~sundar/8164800/webrev.02/
> 
> * Field name changed to targetOsName
> 
> * Throwing RuntimeException if os name can't be determined from java.base
> 
> -Sundar
> 
> 
> On 8/26/2016 7:30 PM, Alan Bateman wrote:
>> On 26/08/2016 14:51, Sundararajan Athijegannathan wrote:
>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8164800/webrev.01/ for
>>> https://bugs.openjdk.java.net/browse/JDK-8164800
>>> 
>>> 
>> What would you think about rename osName to targetOsName to make it
>> clearer?
>> 
>> Also in releaseProperties then I wonder if it should be an error if
>> java.base's osName returns null. If you don't agree then maybe it is
>> at least a warning.
>> 
>> -Alan
> 

Re: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file

[Jim Laskey (Oracle)]

+1

> On Aug 2, 2016, at 8:39 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8159487
> 
> OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another
> fix. Just adding "JAVA_VERSION" and a test change to check these
> properties exist in release file.
> 
> Thanks
> 
> -Sundar
> 

Re: RFR 8162782: jlink ResourcePool.releaseProperties should be removed

[Jim Laskey (Oracle)]

+1

> On Jul 29, 2016, at 11:42 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8162782/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8162782
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8162538: plugin API should avoid read only pool, have module view separated from resource view and have pool builder to modify

[Jim Laskey (Oracle)]

+1

> On Jul 26, 2016, at 11:38 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8162538/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8162538
> 
> Thanks,
> 
> -Sundar
> 

RFR: JDK-8158407 - jimage: verify should do more extensive test

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8158407/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8158407

Re: [9] RFR: 8159214: jlink --include-locales problems

[Jim Laskey (Oracle)]

+1

> On Jul 18, 2016, at 12:54 PM, Naoto Sato  wrote:
> 
> Ping.
> 
> On 7/14/16 5:42 AM, Naoto Sato wrote:
>> Hello,
>> 
>> Please review the fix to the following issue:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8159214
>> 
>> The fix is located at:
>> 
>> http://cr.openjdk.java.net/~naoto/8159214/webrev.04/
>> 
>> Naoto

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

[Jim Laskey (Oracle)]

> How about the following helper method on ModulePool:
> 
>  Optional findModule(ModuleEntry me);
> 
> then the intent in code might be a littler clearer on the context.

After thinking about this at bit: If we did that and then later worked out a 
way to optimize across modules, we’d have to hunt down those cases.What if 
I were to rename the method to findEntryInContext(String path, ModuleEntry 
context)?

— Jim


> On Jul 11, 2016, at 11:15 AM, James Laskey <james.las...@oracle.com> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jul 11, 2016, at 11:09 AM, Paul Sandoz <paul.san...@oracle.com> wrote:
>> 
>> 
>>> On 11 Jul 2016, at 14:17, Jim Laskey (Oracle) <james.las...@oracle.com> 
>>> wrote:
>>> 
>>> I’m not sure if we can determine supplied classes vs others unless we 
>>> provide a flag or the set of supplied modules.  At any rate, the rules for 
>>> cross module optimization would still be complex.
>> 
>> Ok.
>> 
>> 
>>> ModuleEntry.findEntry: I was half thinking the same once I realized the 
>>> limits of the lookup.  The complication is that a ModuleEntry may exist in 
>>> several pools (direct copy).  So, though we have to create new LinkModules 
>>> each pass, we would also be forced to create new ModuleEntrys for each 
>>> pass.  In practice, I’m not sure findEntry will be used frequently in 
>>> relation to the #plugins x #classes.
>> 
>> Ah, i see, so the rule being: go back to the pool to query for stuff.
>> 
>> How about the following helper method on ModulePool:
>> 
>>  Optional findModule(ModuleEntry me);
>> 
>> then the intent in code might be a littler clearer on the context.
>> 
> 
> Ok
> 
>> 
>> ImagePluginStack
>> 
>> 407 return res.isPresent()? 
>> Optional.of(getUncompressed(res.get())) : Optional.empty();
>> 
>> You could do:
>> 
>> return res.map(this::getUncompressed);
>> 
> 
> Good
> 
> 
>> 
>> ClassForNamePLugin
>> 
>> 148 .filter(resource -> resource != null)
>> 
>> Can a resource ever be null?
> 
> I don't think it can. Just cloning JFs code. Might have true at some point. 
> Will drop and see what falls out. 
> 
>> 
>> Paul.
> 

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

[Jim Laskey (Oracle)]

I’m not sure if we can determine supplied classes vs others unless we provide a 
flag or the set of supplied modules.  At any rate, the rules for cross module 
optimization would still be complex.

ModuleEntry.findEntry: I was half thinking the same once I realized the limits 
of the lookup.  The complication is that a ModuleEntry may exist in several 
pools (direct copy).  So, though we have to create new LinkModules each pass, 
we would also be forced to create new ModuleEntrys for each pass.  In practice, 
I’m not sure findEntry will be used frequently in relation to the #plugins x 
#classes.

— Jim


> On Jul 11, 2016, at 7:10 AM, Paul Sandoz <paul.san...@oracle.com> wrote:
> 
> Hi Jim.
> 
> Do you anticipate support across module boundaries given your comment?
> 
> 282 // Navigating other modules via requires and exports is 
> problematic
> 283 // since we cannot construct the runtime model of loaders and 
> layers.
> 
> it might be possible to emulate runtime resolution at link time for the set 
> of idk.modules but not possible by default for non-idk modules because as you 
> say we don’t know the runtime properties (such as layering), that would 
> require some input from the developer (if it is indeed possible to express).
> 
> I ask because there is a simpler way to express the current functionality, 
> provide a method on ModuleEntry to obtain the LinkModule, rather than, or in 
> addition to, the module name. Such functionality is much clearer regarding 
> the scope of resolution.
> 
> Paul.
> 
> 
>> On 8 Jul 2016, at 17:53, Jim Laskey (Oracle) <james.las...@oracle.com> wrote:
>> 
>> http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8161067
>> 
> 

RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8161067

RFR: JDK-8160829 - Remove ASMPool support from jlink

[Jim Laskey (Oracle)]

Much of the removed code seems unnecessary since the same functionality can be 
accomplished with much simpler code.  An example is provided with 
ClassForNamePlugin.java (temporary.)  A shipping byte code optimizer plugin 
will be supplied later.  Additional changes to the plugin API will supply a 
cross resource resolver that will make byte code optimizing code even simpler. 

http://cr.openjdk.java.net/~jlaskey/8160829/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8160829

RFR: JDK-8160348 - jlink should use System.out for usage messages

[Jim Laskey (Oracle)]

Trivial patch

http://cr.openjdk.java.net/~jlaskey/8160348/webrev/index.html 

https://bugs.openjdk.java.net/browse/JDK-8160348 

Re: RFR 8157936: Files.size(Path p) returns 0 if path is from JrtFileSystem with exploded build

[Jim Laskey (Oracle)]

+1

> On Jun 27, 2016, at 5:16 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Thanks for the review. I'll include a space in test and push.
> 
> -Sundar
> 
> 
> On 6/27/2016 1:42 PM, Paul Sandoz wrote:
>>> On 27 Jun 2016, at 09:03, Sundararajan Athijegannathan 
>>>  wrote:
>>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8157936/webrev.00/ for
>>> https://bugs.openjdk.java.net/browse/JDK-8157936
>>> 
>>> Note: no regrestion test added as jrt-fs automated testing is not done
>>> in exploded mode JDK. But, I'm adding a simple class file size test to
>>> Basic.java so that a manual run of jrt-fs tests on exploded image can
>>> verify the fix.
>>> 
>> Look good.
>> 146 return isDirectory()? 0 : Files.size(path);
>> Trivially a missing space between ‘)’ and ‘?’.
>> 
>> Paul.
>> 
> 

Re: RFR 8160346: JLinkTest.java should compute exact number of plugins from jdk.jlink module [ was Re: RFR 8153238: Improve test/tools/jlink/JLinkTest.java not to hard code the number of plugins]

[Jim Laskey (Oracle)]

+1

> On Jun 27, 2016, at 8:19 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Sorry I had that test change already. I've filed another bug to track
> your suggestions.
> 
> Please review http://cr.openjdk.java.net/~sundar/8160346/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8160346
> 
> Thanks,
> 
> -Sundar
> 
> On 6/25/2016 4:10 AM, Mandy Chung wrote:
>>> On Jun 24, 2016, at 9:54 AM, Sundararajan Athijegannathan 
>>>  wrote:
>>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8153238/webrev.00/ for
>>> https://bugs.openjdk.java.net/browse/JDK-8153238
>>  86 if (builtInPlugins.size() < numPlugins) {
>> 
>> What about just count the plugins defined in jdk.jlink module (i.e. matching 
>> what getNumJlinkPlugins counts)?
>> 
>> Since you are on this file, -verbose:gc is not needed for a test.  Maybe 
>> good to take this out.
>> 
>>  56  * @run main/othervm -verbose:gc -Xmx1g JLinkTest
>> 
>> Mandy
> 

Re: RFR 8147794: Jlink's ModuleEntry.stream can't be consumed more than once and ModuleEntry content should be read only if needed

[Jim Laskey (Oracle)]

+1 nice to get this done


> On Jun 24, 2016, at 10:12 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8147794/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8147794
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR: JDK-8159172 - Update usage of jlink/jimage/jmod to show option patterns

[Jim Laskey (Oracle)]

Thank you

> On Jun 23, 2016, at 4:33 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 23/06/2016 19:40, Jim Laskey (Oracle) wrote:
> 
>> http://cr.openjdk.java.net/~jlaskey/8159172/webrev/index.html 
>> <http://cr.openjdk.java.net/~jlaskey/8159172/webrev/index.html>
>> https://bugs.openjdk.java.net/browse/JDK-8159172 
>> <https://bugs.openjdk.java.net/browse/JDK-8159172>
>> 
>> This is an initial clean up of help for jlink/jimage/jmod.  More work is 
>> required (like unifying the options tooling), but comments welcome. — Jim
>> 
>> 
> This looks okay to me. Just a minor nit in the jimage resources where there 
> is a trailing ".w"
> 
> In jmod then shouldn't "Main operation modes" be moved to a resource.
> 
> As regards the updates to the module options then I expect your changes 
> should merge okay.
> 
> -Alan

Re: RFR 8159593: Plugin Set getType() should return a Category

[Jim Laskey (Oracle)]

59 public static boolean isPostProcessor(Category category) {
  60 return category.equals(Category.VERIFIER)
  61 || category.equals(Category.PROCESSOR)
  62 || category.equals(Category.PACKAGER);
  63 }
  64 
  65 public static boolean isPreProcessor(Category category) {
  66 return category.equals(Category.COMPRESSOR)
  67 || category.equals(Category.FILTER)
  68 || category.equals(Category.MODULEINFO_TRANSFORMER)
  69 || category.equals(Category.SORTER)
  70 || category.equals(Category.TRANSFORMER)
  71 || category.equals(Category.METAINFO_ADDER);
  72 }

Wondering if we can handle this with a field in the enum.

+1 otherwise.


> On Jun 21, 2016, at 7:25 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8159593/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8159593
> 
> Thanks,
> -Sundar

Re: RFR JDK-8159206 - All jlink tests failing

[Jim Laskey (Oracle)]

Webrev updated in place.

> On Jun 15, 2016, at 9:50 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> 
>> On Jun 14, 2016, at 11:51 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
>> 
>> I reviewed http://cr.openjdk.java.net/~jlaskey/8159206/webrev
>> 
>> Looks much cleaner.  Thanks for the update
>> 
>> 342 StringSharingPlugin(String[] patterns) throws IOException {
>> 343 this(ResourceFilter.includeFilter(Arrays.asList(patterns)));
>> 344 }
>> 
>> Looks like it’s not used except the no-arg constructor.  Perhaps just drop 
>> this constructor and change the implementation of the no-arg constructor.
> 
> will do
> 
>> 
>> 44 private static final String[] PATTERNS = {"*.diz”};
>> 
>> I think this should be fixed too. The jdk build no longer packages *.diz 
>> files in the jdk packaged modules.  We should create a test to include *.diz 
>> files to verify —-strip-native-debug and —-strip-debug plugins.  It’s okay 
>> to file a JBS issue to add that test.
>> 
> 
> will do
> 
>> 
>> I’m fine to separate the help message update from this patch.  It looks like 
>> it may need some iteration.  This patch is looking good that you should push 
>> soon.
>> 
> 
> will do
> 
>> About the help message, you have this section in jlink/jimage/jmod:
>> 
>> For options requiring a , the argument value will be a comma
>> separated list of elements each using one the following forms:
>>  - a pattern string using the glob pattern syntax
>> glob: - a pattern string using the glob pattern syntax
>> regex: - a pattern string using the regex pattern syntax
>> @ - the name of a file containing patterns to be use, one pattern 
>> per line
>> 
>> 1. It does not apply to jmod —-hash-modules  which is a regex.
> 
> It does apply to -exclude.  I’ll work it out of general comment and into the 
> specific argument.
> 
>> 2. It belongs to jlink —-list-plugins output but not jlink —-help.
>> 
> 
> will do
> 
> 
>> I have the impression that @ is an undocumented option for the 
>> build to use.  Is it intended to document it?
>> 
> 
> It’s been there for some of the filters since the beginning.  We should have 
> it documented.
> 
>> For jimage —help
>> --dir Target directory for extract directive
>> —-filter  Filter [syntax:] entries for list 
>> or extract
>> 
>> This should be
>> —dir   Target directory for extract directive
>> —-filter  Filter [syntax:] entries for 
>> list or extract
>> 
> 
> will do
> 
> 
>> Mandy
> 

Re: RFR JDK-8159206 - All jlink tests failing

[Jim Laskey (Oracle)]

> On Jun 14, 2016, at 11:51 PM, Mandy Chung  wrote:
> 
> I reviewed http://cr.openjdk.java.net/~jlaskey/8159206/webrev
> 
> Looks much cleaner.  Thanks for the update
> 
> 342 StringSharingPlugin(String[] patterns) throws IOException {
> 343 this(ResourceFilter.includeFilter(Arrays.asList(patterns)));
> 344 }
> 
> Looks like it’s not used except the no-arg constructor.  Perhaps just drop 
> this constructor and change the implementation of the no-arg constructor.

will do

> 
>  44 private static final String[] PATTERNS = {"*.diz”};
> 
> I think this should be fixed too. The jdk build no longer packages *.diz 
> files in the jdk packaged modules.  We should create a test to include *.diz 
> files to verify —-strip-native-debug and —-strip-debug plugins.  It’s okay to 
> file a JBS issue to add that test.
> 

will do

> 
> I’m fine to separate the help message update from this patch.  It looks like 
> it may need some iteration.  This patch is looking good that you should push 
> soon.
> 

will do

> About the help message, you have this section in jlink/jimage/jmod:
> 
> For options requiring a , the argument value will be a comma
> separated list of elements each using one the following forms:
>   - a pattern string using the glob pattern syntax
>  glob: - a pattern string using the glob pattern syntax
>  regex: - a pattern string using the regex pattern syntax
>  @ - the name of a file containing patterns to be use, one pattern 
> per line
> 
> 1. It does not apply to jmod —-hash-modules  which is a regex.

It does apply to -exclude.  I’ll work it out of general comment and into the 
specific argument.

> 2. It belongs to jlink —-list-plugins output but not jlink —-help.
> 

will do


> I have the impression that @ is an undocumented option for the 
> build to use.  Is it intended to document it?
> 

It’s been there for some of the filters since the beginning.  We should have it 
documented.

> For jimage —help
>  --dir Target directory for extract directive
>  —-filter  Filter [syntax:] entries for list 
> or extract
> 
> This should be
>  —dir   Target directory for extract directive
>  —-filter  Filter [syntax:] entries for 
> list or extract
> 

will do


> Mandy

RFR JDK-8159206 - All jlink tests failing

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8159206/webrev/index.html 
https://bugs.openjdk.java.net/browse/JDK-8159206
 

Re: RFR: JDK-8158402 - jlink: should use regex for all pattern operations (--order-resources or --exclude-resources)

[Jim Laskey (Oracle)]

I’ll followup shortly.


> On Jun 9, 2016, at 11:51 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> 
> On 09/06/2016 12:00, Jim Laskey (Oracle) wrote:
>> :
>> I have changes for the make files as well.
>> 
>> diff -r 6a78ef1d1e58 make/Images.gmk
>> --- a/make/Images.gmkMon May 30 16:17:11 2016 +0200
>> +++ b/make/Images.gmkWed Jun 08 15:24:53 2016 -0300
>> @@ -115,16 +115,16 @@
>>  # Use this file inside the image as target for make rule
>>  JIMAGE_TARGET_FILE := bin/java$(EXE_SUFFIX)
>>  -JLINK_ORDER_RESOURCES := *module-info.class*
>> +JLINK_ORDER_RESOURCES := **module-info.class
>>  ifeq ($(ENABLE_GENERATE_CLASSLIST), true)
>>JLINK_ORDER_RESOURCES += @$(SUPPORT_OUTPUTDIR)/classlist/classlist
>>  endif
>>  JLINK_ORDER_RESOURCES += \
>> -/java.base/java/* \
>> -/java.base/jdk/* \
>> -/java.base/sun/* \
>> -/java.base/com/* \
>> -/jdk.localedata/* \
>> +/java.base/java/** \
>> +/java.base/jdk/** \
>> +/java.base/sun/** \
>> +/java.base/com/** \
>> +/jdk.localedata/** \
>>  #
>>JLINK_TOOL := $(JLINK) --modulepath $(IMAGES_OUTPUTDIR)/jmods \
>> 
>> 
> This looks okay. So are there changes to the usage messages?
> 
> -Alan

Re: RFR: JDK-8158402 - jlink: should use regex for all pattern operations (--order-resources or --exclude-resources)

[Jim Laskey (Oracle)]

> On Jun 9, 2016, at 8:52 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:
> 
>> 
>> On 9 Jun 2016, at 11:16, Alan Bateman <alan.bate...@oracle.com> wrote:
>> 
>> On 08/06/2016 20:45, Jim Laskey (Oracle) wrote:
>> 
>>> Consistent use of PathPatterns for jlink, jimage and jmod options.
>>> 
>>> —optionName=(regex:|glob:|) ?? where  => 
>>> glob:
>>> 
>>> http://cr.openjdk.java.net/~jlaskey/8158402/webrev/index.html 
>>> <http://cr.openjdk.java.net/~jlaskey/8158402/webrev/index.html>
>>> https://bugs.openjdk.java.net/browse/JDK-8158402 
>>> <https://bugs.openjdk.java.net/browse/JDK-8158402>
>>> 
>> This look okay to me but two questions:
>> 
>> 1. Do any of the usage resources need to be updated?
>> 
>> 2. Does this introduce an inconsistency in the jmod tool in that 
>> --hash-modules takes a regex whereas --exclude takes a pattern that is a 
>> glob (at least by default, it could be a regex too if prefixed with 
>> "regex:").
> 
> As things currently stand --hash-modules accepts a regex, and --exclude 
> accepts a glob. So this change does not affect default behaviour.
> 
> It makes sense for --exclude to take a glob ( and optionally a regex ).
> I don’t think it makes sense for --hash-modules to take anything other
> than a regex.
> 
> Are there issues with this?
> 
> Jim,   can you please rename GlobConverter to PatternConverter or 
> ExcludeConverter,
> or similar.

diff -r 766e969fc3e0 src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
--- a/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java  Thu Jun 09 
07:55:38 2016 -0300
+++ b/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java  Thu Jun 09 
08:56:46 2016 -0300
@@ -1072,6 +1072,10 @@
 @Override
 public Pattern convert(String value) {
 try {
+if (value.startsWith("regex:")) {
+value = value.substring("regex:".length()).trim();
+}
+
 return Pattern.compile(value);
 } catch (PatternSyntaxException e) {
 throw new CommandException("err.bad.pattern", value);
@@ -1083,7 +1087,7 @@
 @Override public String valuePattern() { return "pattern"; }
 }
 
-static class GlobConverter implements ValueConverter {
+static class PathMatcherConverter implements ValueConverter {
 @Override
 public PathMatcher convert(String pattern) {
 try {
@@ -1199,7 +1203,7 @@
 OptionSpec excludes
 = parser.accepts("exclude", getMessage("main.opt.exclude"))
 .withRequiredArg()
-.withValuesConvertedBy(new GlobConverter());
+.withValuesConvertedBy(new PathMatcherConverter());
 
 OptionSpec hashModules
 = parser.accepts("hash-modules", 
getMessage("main.opt.hash-modules"))

> 
> -Chris.

Re: RFR: JDK-8158402 - jlink: should use regex for all pattern operations (--order-resources or --exclude-resources)

[Jim Laskey (Oracle)]

> On Jun 9, 2016, at 7:16 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 08/06/2016 20:45, Jim Laskey (Oracle) wrote:
> 
>> Consistent use of PathPatterns for jlink, jimage and jmod options.
>> 
>> —optionName=(regex:|glob:|) ?? where  => 
>> glob:
>> 
>> http://cr.openjdk.java.net/~jlaskey/8158402/webrev/index.html 
>> <http://cr.openjdk.java.net/~jlaskey/8158402/webrev/index.html>
>> https://bugs.openjdk.java.net/browse/JDK-8158402 
>> <https://bugs.openjdk.java.net/browse/JDK-8158402>
>> 
> This look okay to me but two questions:
> 
> 1. Do any of the usage resources need to be updated?

I have changes for the make files as well. 

diff -r 6a78ef1d1e58 make/Images.gmk
--- a/make/Images.gmk   Mon May 30 16:17:11 2016 +0200
+++ b/make/Images.gmk   Wed Jun 08 15:24:53 2016 -0300
@@ -115,16 +115,16 @@
 # Use this file inside the image as target for make rule
 JIMAGE_TARGET_FILE := bin/java$(EXE_SUFFIX)
 
-JLINK_ORDER_RESOURCES := *module-info.class*
+JLINK_ORDER_RESOURCES := **module-info.class
 ifeq ($(ENABLE_GENERATE_CLASSLIST), true)
   JLINK_ORDER_RESOURCES += @$(SUPPORT_OUTPUTDIR)/classlist/classlist
 endif
 JLINK_ORDER_RESOURCES += \
-/java.base/java/* \
-/java.base/jdk/* \
-/java.base/sun/* \
-/java.base/com/* \
-/jdk.localedata/* \
+/java.base/java/** \
+/java.base/jdk/** \
+/java.base/sun/** \
+/java.base/com/** \
+/jdk.localedata/** \
 #
 
 JLINK_TOOL := $(JLINK) --modulepath $(IMAGES_OUTPUTDIR)/jmods \


> 
> 2. Does this introduce an inconsistency in the jmod tool in that 
> --hash-modules takes a regex whereas --exclude takes a pattern that is a glob 
> (at least by default, it could be a regex too if prefixed with "regex:”).

I was taking Chris’ advisement on this.

> 
> -Alan

RFR: JDK-8158402 - jlink: should use regex for all pattern operations (--order-resources or --exclude-resources)

[Jim Laskey (Oracle)]

Consistent use of PathPatterns for jlink, jimage and jmod options.  

—optionName=(regex:|glob:|) ?? where  => 
glob:

http://cr.openjdk.java.net/~jlaskey/8158402/webrev/index.html 

https://bugs.openjdk.java.net/browse/JDK-8158402 

Re: RFR (S) 8158851: MH.publicLookup() init circularity, triggered by custom SecurityManager with String concat and -limitmods java.base

[Jim Laskey (Oracle)]

If it’s in the jimage, I/O should not be an issue (defineClass from a direct 
memory mapped buffer) vs assembling and assigning a byte array.  Measure first?


> On Jun 7, 2016, at 12:44 PM, Aleksey Shipilev <aleksey.shipi...@oracle.com> 
> wrote:
> 
> On 06/07/2016 06:09 PM, Jim Laskey (Oracle) wrote:
>> Generally I disagree with this kind of hack. It will bite you in the
>> @$$ at some point. Why not just have a class file containing the bytes?
> 
> What's the difference between a small binary blob in a
> filesystem/resource vs a small binary blob inlined? Apart from the
> additional hassle of packing things into resources (which probably
> requires dealing with build?), hitting the I/O for loading it (which
> probably defeats the purpose of constructing the class on the fly), etc.
> 
> I wonder if the whole LookupHelper business is here to stay: Alan said
> that part of mechanics is up to a reimplementation?
> 
> Thanks,
> -Aleksey
> 
>>> On Jun 7, 2016, at 11:56 AM, Aleksey Shipilev <aleksey.shipi...@oracle.com> 
>>> wrote:
>>> 
>>> On 06/07/2016 04:51 PM, Alan Bateman wrote:
>>>> On 07/06/2016 14:38, Aleksey Shipilev wrote:
>>>>> Please review a fix for a MH.publicLookup() circularity, which is
>>>>> triggered if you run existing String concat tests with -limitmods
>>>>> java.base:
>>>>>  https://bugs.openjdk.java.net/browse/JDK-8158851
>>>>> 
>>>>> Webrev:
>>>>>  http://cr.openjdk.java.net/~shade/8158851/webrev.01/
>>>> As a short term fix then this looks okay. It may be (once there is
>>>> another round of work on MethodHandles w/modules) that PL moves back to
>>>> java.lang.Object but that has many discussion points for another thread.
>>>> 
>>>> If you want then the doPriv in LookupHelper can do away as it is not
>>>> required when you can guarantee that it is initialized before a security
>>>> manager is set.
>>> 
>>> Done so.
>>> 
>>>> One downside to initializing PL early is that is LookupHelper will
>>>> trigger some ASM to be loaded. This could avoid by generating it at link
>>>> time and loading the class bytes as resource. Hard to know if it's worth
>>>> it as the first lambda usage is going to trigger these classes to load
>>>> anyway.
>>> 
>>> Yes. I agree with Claes here, can't we inline the bytecode to avoid
>>> messing with ASM?
>>> 
>>> See:
>>> http://cr.openjdk.java.net/~shade/8158851/webrev.02/
>>> 
>>> Still passes all java/lang tests.
>>> 
>>> Thanks,
>>> -Aleksey
>>> 
>>> 
>> 
> 
> 

Re: RFR (S) 8158851: MH.publicLookup() init circularity, triggered by custom SecurityManager with String concat and -limitmods java.base

[Jim Laskey (Oracle)]

Generally I disagree with this kind of hack.  It will bite you in the @$$ at 
some point.  Why not just have a class file containing the bytes?

Otherwise, you should probably embed some of the ASM constants in the array to 
handle things like class version? 52 => CLASS_VERSION, et cetera. These would 
be compile time symbols and no less efficient and slightly more readable.

— Jim



> On Jun 7, 2016, at 11:56 AM, Aleksey Shipilev  
> wrote:
> 
> On 06/07/2016 04:51 PM, Alan Bateman wrote:
>> On 07/06/2016 14:38, Aleksey Shipilev wrote:
>>> Please review a fix for a MH.publicLookup() circularity, which is
>>> triggered if you run existing String concat tests with -limitmods
>>> java.base:
>>>   https://bugs.openjdk.java.net/browse/JDK-8158851
>>> 
>>> Webrev:
>>>   http://cr.openjdk.java.net/~shade/8158851/webrev.01/
>> As a short term fix then this looks okay. It may be (once there is
>> another round of work on MethodHandles w/modules) that PL moves back to
>> java.lang.Object but that has many discussion points for another thread.
>> 
>> If you want then the doPriv in LookupHelper can do away as it is not
>> required when you can guarantee that it is initialized before a security
>> manager is set.
> 
> Done so.
> 
>> One downside to initializing PL early is that is LookupHelper will
>> trigger some ASM to be loaded. This could avoid by generating it at link
>> time and loading the class bytes as resource. Hard to know if it's worth
>> it as the first lambda usage is going to trigger these classes to load
>> anyway.
> 
> Yes. I agree with Claes here, can't we inline the bytecode to avoid
> messing with ASM?
> 
> See:
>  http://cr.openjdk.java.net/~shade/8158851/webrev.02/
> 
> Still passes all java/lang tests.
> 
> Thanks,
> -Aleksey
> 
> 

Who is using jlink --exclude-files, --exclude-resources or --order-resources (was RFR: JDK-8156995 - jimage: extract specified contents)

[Jim Laskey (Oracle)]

We plan to change these plugins to use regex instead of “*" notation.  This 
requires some coordination with users.

https://bugs.openjdk.java.net/browse/JDK-8158402

Speak up.

— Jim


> On Jun 1, 2016, at 12:56 PM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> I’ll change both jlink and jimage for consistency and optimize jlink if it 
> becomes an issue.  Will file separate bugs.
> 
> — Jim
> 
> 
>> On Jun 1, 2016, at 12:45 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
>> 
>> 
>> 
>> On 01/06/2016 16:35, Jim Laskey (Oracle) wrote:
>>> We tried using regex in jlink for various filters and found that it made 
>>> jlink > 10x slower.  Granted jlink is time critical and jimage is not.  I 
>>> made the assumption that filter expressions would be very basic, most of 
>>> the time, and tried to be consistent with filters for both tools.  I could 
>>> easily change it to use regex if not a basic pattern.
>>> 
>>> Note we also chose not to use java.lang.regex in Nashorn for similar 
>>> reasons (plus the fact it didn’t meet JS spec. .)  Might be worth 
>>> revisiting regex performance.
>>> 
>> I understand that this was an issue in Nashorn. I wasn't aware of this being 
>> a problem with jlink as the regex usage should be very simple with the 
>> order-resources or exclude-resources plugins. Note that jar and jmod both 
>> have options that are patterns so we are a bit inconsistent on this point.
>> 
>> -Alan.
> 

Re: RFR: JDK-8156994 - jimage --help is not helpful

[Jim Laskey (Oracle)]

> On Jun 1, 2016, at 12:33 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 01/06/2016 15:47, Jim Laskey (Oracle) wrote:
> 
>> http://cr.openjdk.java.net/~jlaskey/8156994/webrev/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8156994
> Good to see this fixed. I wonder about the usage message for -verify :
>   "Reports on any .class entries that don't verify as classes"
> 
> "verify" isn't clear here, one might thing it runs the verifier when all it 
> does is check that each class resource has the 0xCAFEBABE magic number. 
> Instead of changing the usage message then what would you think about 
> changing the implementation to work like the VerifyJImage test? Separate 
> issue of course but I suspect it might be more useful. We could even think 
> about having it be run in the build.

I have looked at the VerifyJImage test and wonder how it works if jimage being 
used is not the boot jimage.  Would creating a loader and using defineClass be 
reasonable?


> 
> -Alan

Re: RFR: JDK-8156995 - jimage: extract specified contents

[Jim Laskey (Oracle)]

We tried using regex in jlink for various filters and found that it made jlink 
> 10x slower.  Granted jlink is time critical and jimage is not.  I made the 
assumption that filter expressions would be very basic, most of the time, and 
tried to be consistent with filters for both tools.  I could easily change it 
to use regex if not a basic pattern.

Note we also chose not to use java.lang.regex in Nashorn for similar reasons 
(plus the fact it didn’t meet JS spec. .)  Might be worth revisiting regex 
performance.

— Jim
 


> On Jun 1, 2016, at 12:24 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 01/06/2016 15:48, Jim Laskey (Oracle) wrote:
> 
>> http://cr.openjdk.java.net/~jlaskey/8156995/webrev/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8156995
> Jim - should this allow regex rather than just "*" ?
> 
> -Alan

RFR: JDK-8156995 - jimage: extract specified contents

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8156995/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8156995

Re: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds

[Jim Laskey (Oracle)]

+1

> On May 26, 2016, at 7:58 AM, Felix Yang  wrote:
> 
> Hi there,
> 
>please review the following change.
> 
> Webrev:   http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/
> 
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8157931
> 
> 
> The test "jdk/internal/jrtfs/Basic.java" fails when testing with exploded 
> builds. It tried to access jrt-fs.jar which not exists in exploded builds.
> 
> In this fix, those tests will be skipped, if the build is identified as an 
> exploded one. And please note that, a bug (JDK-8157936 
> ) was found with the 
> updated test.
> 
> Thanks,
> 
> Felix
> 

Re: RFR: JDK-8156602 - javac crashes again on Windows 32-bit with ClosedChannelException

[Jim Laskey (Oracle)]

This does work for the test provided.  The interrupted thread fails on the 
closed channel, but other theads continue to run on reopened channel.

The problem with the non-interruptible I/O is the jdk8 backport issue.  There 
is no way to use the non-interruptible read without loading new classes at 
start up (reflection or method handles.)  I could check version and use 
different paths on JDK-9 and JDK-8.

Other suggestions?

— Jim















> On May 19, 2016, at 10:46 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 19/05/2016 14:03, Jim Laskey (Oracle) wrote:
>> On 32 bit, a shared jimage channel closed by an interrupted thread 
>> (ClosedChannelException) disrupts other threads sharing jimage.  Fix is to 
>> reopen channel on not interrupted thread.
>> 
>> http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8156602
> Does this work? The interrupt status isn't cleared so I would expect the 
> second and subsequent reads to fail and so hit the retry limit.
> 
> In generally them I'm uneasy about this approach and would prefer if we used 
> non-interruptible I/O. I don't mind working on it if you'd like to get rid of 
> it.
> 
> -Alan

RFR: JDK-8156602 - javac crashes again on Windows 32-bit with ClosedChannelException

[Jim Laskey (Oracle)]

On 32 bit, a shared jimage channel closed by an interrupted thread 
(ClosedChannelException) disrupts other threads sharing jimage.  Fix is to 
reopen channel on not interrupted thread.

http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8156602

RFR: JDK-8156781 - change to jlink has result in test failure

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8156781/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8156781

Re: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

[Jim Laskey (Oracle)]

> On May 11, 2016, at 2:21 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
> 
>> 
>> On May 11, 2016, at 10:17 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>> wrote:
>> 
>> 
>>> On May 11, 2016, at 2:03 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
>>> 
>>> 
>>>> On May 9, 2016, at 10:41 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>>>> wrote:
>>>> 
>>>> Modifies the jlink sort-plugin to accept a classlist to order files in the 
>>>> jimage.
>>>> 
>>>> http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html
>>>> https://bugs.openjdk.java.net/browse/JDK-8155237
>>> 
>>> This looks good and also cleaned up the original code.  I saw that it’s 
>>> pushed which is fine. 
>>> 
>>> A small comment: this plugin should throw error if @file not exists.
>> 
>> This is deliberate, since the classlist may not be there during one phase of 
>> the build.  We could issue a warning.
>> 
> 
> At build time, it should know the image is created using classlist or not and 
> so the —-order-resources option can only be specified when it’s present.  
> This would help catching issue at link time in case if anything goes wrong.


Erik, comments?

> 
>> 
>>> Does jimage list command show the jimage entries in alphabetically order?  
>>> It would be useful to provide an option to list the entries as layout in 
>>> the jimage file (a RFE).
>> 
>> Yes to alphabetically.  Please post an RFE for file order.
>> 
> 
> OK.
> 
> Mandy

Re: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

[Jim Laskey (Oracle)]

> On May 11, 2016, at 2:03 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
> 
> 
>> On May 9, 2016, at 10:41 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>> wrote:
>> 
>> Modifies the jlink sort-plugin to accept a classlist to order files in the 
>> jimage.
>> 
>> http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8155237
> 
> This looks good and also cleaned up the original code.  I saw that it’s 
> pushed which is fine. 
> 
> A small comment: this plugin should throw error if @file not exists.

This is deliberate, since the classlist may not be there during one phase of 
the build.  We could issue a warning.



> Does jimage list command show the jimage entries in alphabetically order?  It 
> would be useful to provide an option to list the entries as layout in the 
> jimage file (a RFE).

Yes to alphabetically.  Please post an RFE for file order.

— Jim

Re: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

[Jim Laskey (Oracle)]

Only that experimentation is still ongoing.  I have an agreement with Claes 
that he will make that change when he is satisfied with an improvement.


> On May 11, 2016, at 9:35 AM, Alan Bateman  wrote:
> 
> 
> 
> On 11/05/2016 13:30, Claes Redestad wrote:
>> Updated changes look good, too.
>> 
>> I will file a new RFE to deal with the top level changes to actually enable 
>> the use of this functionality.
> Is there any reason not to update the jlink usage in Images.gmk as part of 
> this?
> 
> -Alan

RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

[Jim Laskey (Oracle)]

Modifies the jlink sort-plugin to accept a classlist to order files in the 
jimage.

http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8155237

Re: Having problem building jdk9-dev

[Jim Laskey (Oracle)]

Mac OS X - reproducible with a clean repo.


> On May 9, 2016, at 10:08 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> 
> 
> 
> Generating blacklisted certs
> java.lang.ClassNotFoundException: sun.text.resources.BreakIteratorRules
>   at 
> jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-ea/BuiltinClassLoader.java:366)
>   at 
> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-ea/ClassLoaders.java:184)
>   at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
>   at java.lang.Class.forName0(java.base@9-ea/Native Method)
>   at java.lang.Class.forName(java.base@9-ea/Class.java:294)
>   at 
> build.tools.generatebreakiteratordata.GenerateBreakIteratorData.generateFiles(GenerateBreakIteratorData.java:94)
>   at 
> build.tools.generatebreakiteratordata.GenerateBreakIteratorData.main(GenerateBreakIteratorData.java:66)
> 

Having problem building jdk9-dev

[Jim Laskey (Oracle)]

Generating blacklisted certs
java.lang.ClassNotFoundException: sun.text.resources.BreakIteratorRules
at 
jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-ea/BuiltinClassLoader.java:366)
at 
jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-ea/ClassLoaders.java:184)
at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
at java.lang.Class.forName0(java.base@9-ea/Native Method)
at java.lang.Class.forName(java.base@9-ea/Class.java:294)
at 
build.tools.generatebreakiteratordata.GenerateBreakIteratorData.generateFiles(GenerateBreakIteratorData.java:94)
at 
build.tools.generatebreakiteratordata.GenerateBreakIteratorData.main(GenerateBreakIteratorData.java:66)

RFR: JDK-8132994 - /modules and /packages should not be parsed by the jimage parser

[Jim Laskey (Oracle)]

Changed to special case parse /modules/ and /packages/.  Will actually reduce 
string table size slightly (better common string match.)

http://cr.openjdk.java.net/~jlaskey/8132994/webrev/index.html 

https://bugs.openjdk.java.net/browse/JDK-8132994 

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

[Jim Laskey (Oracle)]

Thank you, changes incorporated.

> On Apr 22, 2016, at 2:08 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
> 
> Hi Jim,
> 
>> On Apr 22, 2016, at 6:12 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
>> wrote:
>> 
>> Listing is by module, extract has been by module for some time.
>> 
>> http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html 
>> <http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html>
> 
> 
> JDK-8069079 was filed long time ago and I now retested it. jimage list and 
> extract in jdk9 works as what I'd like to see when filing the issue.
> 
> $ ./bin/jimage list lib/modules
> 
> jimage: modules
> /java.activation/META-INF/mailcap.default
> /java.activation/META-INF/mimetypes.default
> /java.activation/com/sun/activation/registries/LineTokenizer.class
> /java.activation/com/sun/activation/registries/LogSupport.class
> :
> 
> The current output looks fine to me.  This issue can be issued.
> 
> A minor comment (a separate issue):
> 
> jimage: modules
> 
> It would help to print the path supplied in the command line than just the 
> base filename.
> 
> $ ./bin/jimage list
> 
> This silently returns.  Since the list/extract command requires to specify 
> the path to the jimage file, it would be helpful to report that.
> 
> Mandy

Re: RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

[Jim Laskey (Oracle)]

Thank you.

> On Apr 24, 2016, at 5:23 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> 
> 
> On 22/04/2016 14:12, Jim Laskey (Oracle) wrote:
>> The unused cache is being unnecessarily activated (ThreadLocal) when buffers 
>> are being released.
>> 
>> http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html 
>> <http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html>
>> https://bugs.openjdk.java.net/browse/JDK-8154179 
>> <https://bugs.openjdk.java.net/browse/JDK-8154179>
>> 
>> 
> This looks okay to me.
> 
> -Alan

Re: RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND

[Jim Laskey (Oracle)]

JCK change incorporated.

Thank you.

> On Apr 24, 2016, at 5:22 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> 
> On 22/04/2016 14:12, Jim Laskey (Oracle) wrote:
>> JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the 
>> jdk jimage.hpp header.  Brought the headers in line.
>> 
>> http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html 
>> <http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html>
>> https://bugs.openjdk.java.net/browse/JDK-8147426 
>> <https://bugs.openjdk.java.net/browse/JDK-8147426>
>> 
> This looks okay to me but comment on JIMAGE_MAX_PATH about the JCK caught by 
> eye and maybe now is a good time to remove that.
> 
> -Alan

Build craziness

[Jim Laskey (Oracle)]

make clean ; make images

Building target 'images' in configuration 
'macosx-x86_64-normal-server-fastdebug'
Building JVM variant 'server' with features 'all-gcs cds compiler1 compiler2 
dtrace fprof jni-check jvmci jvmti management nmt services vm-structs'
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Creating adlc from 13 file(s)
Creating libjsig.dylib from 1 file(s)
dtrace: failed to compile script 
/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot.h.d:
 line 1: empty D program translation unit
make[4]: *** 
[/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/dtracefiles/hotspot.h]
 Error 1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [variant-server-gensrc] Error 2
make[3]: *** Waiting for unfinished jobs
Compiling 19 properties into resource bundles for jdk.javadoc
Parsing 1 properties into enum-like class for jdk.compiler
Compiling 9 properties into resource bundles for jdk.jdeps
make[2]: *** [hotspot] Error 2
make[2]: *** Waiting for unfinished jobs
Compiling 3 properties into resource bundles for jdk.jshell
Compiling 16 properties into resource bundles for jdk.compiler

ERROR: Build failed for target 'images' in configuration 
'macosx-x86_64-normal-server-fastdebug' (exit code 2) 
=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_gensrc_dtracefiles_hotspot.h:
dtrace: failed to compile script 
/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot.h.d:
 line 1: empty D program translation unit
=== End of repeated output ===
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: If caused by a warning, try configure --disable-warnings-as-errors.

make[1]: *** [main] Error 2
make: *** [images] Error 2

Re: RFR: JDK-8154090 - Remove support for jimage recreate

[Jim Laskey (Oracle)]

Thank you.

> On Apr 22, 2016, at 10:53 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> 
> 
> On 22/04/2016 14:12, Jim Laskey (Oracle) wrote:
>> http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html 
>> <http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html>
>> https://bugs.openjdk.java.net/browse/JDK-8154090 
>> <https://bugs.openjdk.java.net/browse/JDK-8154090>
>> 
> This looks to me assuming that it's only the one test that needs changing.
> 
> -Alan

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

[Jim Laskey (Oracle)]

Will change.  Thank you.

> On Apr 22, 2016, at 10:59 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> 
> 
> On 22/04/2016 14:54, Jim Laskey (Oracle) wrote:
>> It can be outside, does the change add value?
>> 
>> 
> I think so as it's always been odd that the jimage tool would exit without 
> printing anything when calling without any arguments. My comment on the place 
> of the check is that it wasn't clear why it is done in the try/catch, it's a 
> minor comment/question, nothing more.
> 
> -Alan

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

[Jim Laskey (Oracle)]

It can be outside, does the change add value?

> On Apr 22, 2016, at 10:12 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> Now prints usage.
> 
> http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html 
> <http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html>
> https://bugs.openjdk.java.net/browse/JDK-8082537 
> <https://bugs.openjdk.java.net/browse/JDK-8082537>
> 

RFR: JDK-8147634 - Need a JImage API that given a JImageLocationRef returns class name

[Jim Laskey (Oracle)]

Implemented as requested by the runtime team.

http://cr.openjdk.java.net/~jlaskey/8147634/webrev/index.html 

https://bugs.openjdk.java.net/browse/JDK-8147634 

RFR: JDK-8069079 - jimage extract / list to organize classes by modules

[Jim Laskey (Oracle)]

Listing is by module, extract has been by module for some time.

http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html 

https://bugs.openjdk.java.net/browse/JDK-8069079