Re: Integrated: 8257434: jpackage fails to create rpm on Fedora Linux

[Andy Herrick]

On Tue, 1 Dec 2020 23:54:11 GMT, Alexey Semenyuk  wrote:

> Add missing quotes to `%if` expressions in spec template. Required by 
> rpmbuild 4.16.0

looks good

-

Marked as reviewed by herrick (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1551

Re: [jdk18] RFR: 8278907: JPackage test - SigningPackageTest is failed with runtime exception

[Andy Herrick]

On Fri, 17 Dec 2021 03:28:12 GMT, Alexander Matveev  
wrote:

> This is regression from JDK-8263155. MacHelper.java is now calling test 
> verification callback with all content in DMG root. SigningPackageTest 
> expects only path with app name in it and thus it fails when trying to verify 
> app inside ".background" folder. Fixed by checking that provided path for 
> verification is actually an application we expecting. All other paths are 
> ignored.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk18/pull/42

Re: [jdk18] RFR: 8278233: [macos] tools/jpackage tests timeout due to /usr/bin/osascript

[Andy Herrick]

On Tue, 14 Dec 2021 06:10:51 GMT, Alexander Matveev  
wrote:

> This is regression from JDK-8276837. exec() was passing INFINITE_TIMEOUT 
> instead of actual value of timeout variable. Execution of osascript was 
> running without timeout and thus several tests timeout. Osascript hang during 
> test execution is intermittent issue.
> 
> Also, removed IconTest.java and MultiNameTwoPhaseTest.java from 
> ProblemList.txt.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk18/pull/18

Integrated: JDK-8276837: [macos]: Error when signing the additional launcher

[Andy Herrick]

On Wed, 1 Dec 2021 21:35:01 GMT, Andy Herrick  wrote:

> - We need to unsign all executables and libraries in the app-image before 
> signing. (not just those in the runtime).
>  - Clean up excessive output by executing the individual file sign and 
> unsigning commands in quiet mode.
>  - Add conditions in SigningAppImageTest to test signing of additional 
> launchers.

This pull request has now been integrated.

Changeset: 76968979
Author:Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/7696897932a35708b1632517127c1a3a59919878
Stats: 52 lines in 3 files changed: 21 ins; 5 del; 26 mod

8276837: [macos]: Error when signing the additional launcher

Reviewed-by: asemenyuk, almatvee

-

PR: https://git.openjdk.java.net/jdk/pull/6654

RFR: JDK-8276837: [macos]: Error when signing the additional launcher

[Andy Herrick]

- We need to unsign all executables and libraries in the app-image before 
signing. (not just those in the runtime).
 - Clean up excessive output by executing the individual file sign and 
unsigning commands in quiet mode.
 - Add conditions in SigningAppImageTest to test signing of additional 
launchers.

-

Commit messages:
 - JDK-8276837: [macos]: Error when signing the additional launcher
 - JDK-8276837: [macos]: Errorwhen signing the additional launcher

Changes: https://git.openjdk.java.net/jdk/pull/6654/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6654=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276837
  Stats: 52 lines in 3 files changed: 21 ins; 5 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6654/head:pull/6654

PR: https://git.openjdk.java.net/jdk/pull/6654

Re: RFR: JDK-8276837: [macos]: Error when signing the additional launcher

[Andy Herrick]

On Wed, 1 Dec 2021 14:25:52 GMT, Andy Herrick  wrote:

> Before signing, unsign all executables and libraries (not just those in 
> runtime).
> Also, run individual file sign and unsign commands in quiet mode.
> Also, add test case to SigningAppImageTest to test that signing app that has 
> additional launcher works, and results in validly signed launcher and 
> additional launcher (original reported problem).

last push was meant to be only one file - but got lots of unrelated changes.
will close this one and open new PR.

-

PR: https://git.openjdk.java.net/jdk/pull/6636

Withdrawn: JDK-8276837: [macos]: Error when signing the additional launcher

[Andy Herrick]

On Wed, 1 Dec 2021 14:25:52 GMT, Andy Herrick  wrote:

> Before signing, unsign all executables and libraries (not just those in 
> runtime).
> Also, run individual file sign and unsign commands in quiet mode.
> Also, add test case to SigningAppImageTest to test that signing app that has 
> additional launcher works, and results in validly signed launcher and 
> additional launcher (original reported problem).

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk/pull/6636

Re: RFR: JDK-8276837: [macos]: Error when signing the additional launcher [v2]

[Andy Herrick]

> Before signing, unsign all executables and libraries (not just those in 
> runtime).
> Also, run individual file sign and unsign commands in quiet mode.
> Also, add test case to SigningAppImageTest to test that signing app that has 
> additional launcher works, and results in validly signed launcher and 
> additional launcher (original reported problem).

Andy Herrick has updated the pull request incrementally with 85 additional 
commits since the last revision:

 - JDK-8276837: [macos]: Error when signing the additional launcher
 - 8277797: Remove undefined/unused SharedRuntime::trampoline_size()
   
   Reviewed-by: dholmes, stuefe
 - 8277789: G1: G1CardSetConfiguration prefixes num_ and max_ used 
interchangeably
   
   Reviewed-by: mli, tschatzl
 - 8277878: Fix compiler tests after JDK-8275908
   
   Reviewed-by: thartmann, chagedorn
 - 8277904: G1: Remove G1CardSetArray::max_entries
   
   Reviewed-by: tschatzl
 - 8277896: Remove unused BOTConstants member methods
   
   Reviewed-by: kbarrett
 - 8277450: Record number of references into collection set during gc
   
   Reviewed-by: kbarrett, iwalulya
 - 8277928: Fix compilation on macosx-aarch64 after 8276108
   
   Reviewed-by: shade, dholmes
 - 8275241: Unused ArrayList is created in RequestEngine.addHooks
   
   Reviewed-by: egahlin
 - 8276108: Wrong instruction generation in aarch64 backend
   
   Co-authored-by: Nick Gasson 
   Reviewed-by: aph, neliasso
 - ... and 75 more: https://git.openjdk.java.net/jdk/compare/34692c5d...2a3e19ff

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6636/files
  - new: https://git.openjdk.java.net/jdk/pull/6636/files/34692c5d..2a3e19ff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=6636=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6636=00-01

  Stats: 23719 lines in 463 files changed: 13755 ins; 6525 del; 3439 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6636/head:pull/6636

PR: https://git.openjdk.java.net/jdk/pull/6636

Re: RFR: JDK-8276837: [macos]: Error when signing the additional launcher

[Andy Herrick]

On Wed, 1 Dec 2021 19:59:57 GMT, Alexey Semenyuk  wrote:

>> Before signing, unsign all executables and libraries (not just those in 
>> runtime).
>> Also, run individual file sign and unsign commands in quiet mode.
>> Also, add test case to SigningAppImageTest to test that signing app that has 
>> additional launcher works, and results in validly signed launcher and 
>> additional launcher (original reported problem).
>
> test/jdk/tools/jpackage/macosx/SigningAppImageTest.java line 95:
> 
>> 93: SigningBase.verifyCodesign(launcherPath, true);
>> 94: SigningBase.verifyCodesign(testALPath, true);
>> 95: }
> 
> Would it make sense to extend the existing test with additional launcher 
> checks instead of creating another one? Packaging of a full JDK with signing 
> probably takes a while

yes - that would be simpler - will do.

-

PR: https://git.openjdk.java.net/jdk/pull/6636

RFR: JDK-8276837: [macos]: Error when signing the additional launcher

[Andy Herrick]

Before signing, unsign all executables and libraries (not just those in 
runtime).
Also, run individual file sign and unsign commands in quiet mode.
Also, add test case to SigningAppImageTest to test that signing app that has 
additional launcher works, and results in validly signed launcher and 
additional launcher (original reported problem).

-

Commit messages:
 - JDK-8276837: [macos]: Errorwhen signing the additional launcher

Changes: https://git.openjdk.java.net/jdk/pull/6636/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6636=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276837
  Stats: 64 lines in 3 files changed: 33 ins; 5 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6636/head:pull/6636

PR: https://git.openjdk.java.net/jdk/pull/6636

Re: RFR: 8277647: [REDO] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

[Andy Herrick]

never mind my previous  email, addArgument("--java-option ...") , would 
be for argument to the java launching the app.


you are right to use -J-Djlink.debug=true .  It must be interpreted in 
the standard launcher used for jpackage, because the -J-D arg never gets 
to the jpackage java code and the System Property "jlink.debug" is 
already set to true by then.


/Andy

On 11/24/2021 8:35 AM, Andy Herrick wrote:
Wait - the original change, 'addArgument("-J-Djlink.debug=true");' 
adds "-D-J..." as a jpackage arg.  This is not a supported command 
line option, I'm not sure why it is not throwing an error all the 
time, but you need to use addArgument("--java-option 
-Djlink.debug=true" ); instead.


I'll look into why "-J..." is being silently ignored (at least on 
windows) and not throwing a invalid argument exception.


/Andy


On 11/24/2021 4:03 AM, Jaikiran Pai wrote:
Can I please get a review of this change which adds 
`jlink.debug=true` system property while launching `jpackage` tests?


The previous fix for this in https://github.com/openjdk/jdk/pull/6491 
didn't take into account the part where the `jpackage` tool gets 
launched as a `ToolProvider` from some of these tests. This resulted 
in a large number of tests failing (across different OS) in `tier2` 
with errors like:



Error: Invalid Option: [-J-Djlink.debug=true]


In this current PR, the changed code now takes into account the 
possibility of `jpackage` being launched as a `ToolProvider` and in 
such cases doesn't add this option. To achieve this, the adding of 
this argument is delayed till when the actual execution is about to 
happen and thus it's now done in the 
`adjustArgumentsBeforeExecution()` method of the jpackage test 
framework.


With this change, I have now run the `jdk:tier2` locally on a macos 
instance and the tests have all passed:



Test results: passed: 3,821; failed: 3
Report written to 
jdk/build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2/html/report.html
Results written to 
jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_jdk_tier2

Error: Some tests failed or other problems occurred.
Finished running test 'jtreg:test/jdk:tier2'
Test report is stored in 
build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2


==
Test summary
==
    TEST  TOTAL PASS  
FAIL ERROR

jtreg:test/jdk:tier2 3824  3821 3 0 <<

==

The 3 failing tests are unrelated to this change and belong to the 
`java/nio/channels/DatagramChannel/` test package.
Furthermore, I've looked into the generated logs of the following 
tests to verify that the `-J-Djlink.debug=true` does get passed in 
relevant tests and doesn't in those that failed previously in `tier2`:


test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java
test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java
test/jdk/tools/jpackage/share/ArgumentsTest.java

A sample from one of the logs where this system property is expected 
to be passed along:


TRACE: exec: Execute 
[jdk/build/macosx-x86_64-server-release/images/jdk/bin/jpackage 
--input ./test/input --dest ./test/output --name "Name With Space" 
--type pkg --main-jar hello.jar --main-class Hello 
-J-Djlink.debug=true --verbose](15); inherit I/O...


I would still like to request someone with access to CI or other OSes 
(like Windows and Linux) to help test `tier2` against this PR.


-

Commit messages:
  - 8277647: [REDO] JDK-8277507 Add jlink.debug system property while 
launching jpackage tests to help diagonize recent intermittent failures


Changes: https://git.openjdk.java.net/jdk/pull/6534/files
  Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6534=00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8277647
   Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
   Patch: https://git.openjdk.java.net/jdk/pull/6534.diff
   Fetch: git fetch https://git.openjdk.java.net/jdk 
pull/6534/head:pull/6534


PR: https://git.openjdk.java.net/jdk/pull/6534

Re: RFR: 8277647: [REDO] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

[Andy Herrick]

Wait - the original change, 'addArgument("-J-Djlink.debug=true");' adds 
"-D-J..." as a jpackage arg.  This is not a supported command line 
option, I'm not sure why it is not throwing an error all the time, but 
you need to use addArgument("--java-option -Djlink.debug=true" ); instead.


I'll look into why "-J..." is being silently ignored (at least on 
windows) and not throwing a invalid argument exception.


/Andy


On 11/24/2021 4:03 AM, Jaikiran Pai wrote:

Can I please get a review of this change which adds `jlink.debug=true` system 
property while launching `jpackage` tests?

The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't 
take into account the part where the `jpackage` tool gets launched as a 
`ToolProvider` from some of these tests. This resulted in a large number of 
tests failing (across different OS) in `tier2` with errors like:


Error: Invalid Option: [-J-Djlink.debug=true]


In this current PR, the changed code now takes into account the possibility of 
`jpackage` being launched as a `ToolProvider` and in such cases doesn't add 
this option. To achieve this, the adding of this argument is delayed till when 
the actual execution is about to happen and thus it's now done in the 
`adjustArgumentsBeforeExecution()` method of the jpackage test framework.

With this change, I have now run the `jdk:tier2` locally on a macos instance 
and the tests have all passed:


Test results: passed: 3,821; failed: 3
Report written to 
jdk/build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2/html/report.html
Results written to 
jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_jdk_tier2
Error: Some tests failed or other problems occurred.
Finished running test 'jtreg:test/jdk:tier2'
Test report is stored in 
build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2

==
Test summary
==
TEST  TOTAL  PASS  FAIL ERROR

jtreg:test/jdk:tier2   3824  3821 3 0 <<

==

The 3 failing tests are unrelated to this change and belong to the 
`java/nio/channels/DatagramChannel/` test package.
Furthermore, I've looked into the generated logs of the following tests to 
verify that the `-J-Djlink.debug=true` does get passed in relevant tests and 
doesn't in those that failed previously in `tier2`:

test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java
test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java
test/jdk/tools/jpackage/share/ArgumentsTest.java

A sample from one of the logs where this system property is expected to be 
passed along:


TRACE: exec: Execute [jdk/build/macosx-x86_64-server-release/images/jdk/bin/jpackage 
--input ./test/input --dest ./test/output --name "Name With Space" --type pkg 
--main-jar hello.jar --main-class Hello -J-Djlink.debug=true --verbose](15); inherit 
I/O...


I would still like to request someone with access to CI or other OSes (like 
Windows and Linux) to help test `tier2` against this PR.

-

Commit messages:
  - 8277647: [REDO] JDK-8277507 Add jlink.debug system property while launching 
jpackage tests to help diagonize recent intermittent failures

Changes: https://git.openjdk.java.net/jdk/pull/6534/files
  Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6534=00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8277647
   Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
   Patch: https://git.openjdk.java.net/jdk/pull/6534.diff
   Fetch: git fetch https://git.openjdk.java.net/jdk pull/6534/head:pull/6534

PR: https://git.openjdk.java.net/jdk/pull/6534

Re: RFR: 8277429: Conflicting jpackage static library name

[Andy Herrick]

On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk  wrote:

> 8277429: Conflicting jpackage static library name

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6485

Integrated: JDK-8276150: Quarantined jpackage apps are labeled as "damaged"

[Andy Herrick]

On Mon, 15 Nov 2021 19:56:28 GMT, Andy Herrick  wrote:

> JDK-8276150: Quarantined jpackage apps are labeled as "damaged"

This pull request has now been integrated.

Changeset: 936f7ff4
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0
Stats: 102 lines in 2 files changed: 69 ins; 22 del; 11 mod

8276150: Quarantined jpackage apps are labeled as "damaged"

Reviewed-by: almatvee

-

PR: https://git.openjdk.java.net/jdk/pull/6396

RFR: JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged"

[Andy Herrick]

JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged"

-

Commit messages:
 - JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged"

Changes: https://git.openjdk.java.net/jdk/pull/6396/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6396=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276150
  Stats: 102 lines in 2 files changed: 69 ins; 22 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6396.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6396/head:pull/6396

PR: https://git.openjdk.java.net/jdk/pull/6396

Re: RFR: 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional

[Andy Herrick]

On Thu, 11 Nov 2021 04:07:18 GMT, Alexey Semenyuk  wrote:

> 8276084: Linux DEB Bundler: release number in outputted .deb file should be 
> optional

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6345

Re: RFR: 8274856: Failing jpackage tests with fastdebug/release build

[Andy Herrick]

On Fri, 5 Nov 2021 19:58:01 GMT, Alexey Semenyuk  wrote:

> The fix is to isolate C++ calls in the separate forked child process on 
> Linux. 
> This change requires the passing of JLI command line arguments and values of 
> environment variables between two processes.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6283

Integrated: JDK-8276562: Fix to JDK-8263155 left out the help text changes

[Andy Herrick]

On Fri, 5 Nov 2021 17:21:01 GMT, Andy Herrick  wrote:

> JDK-8276562: Fix to JDK-8263155 left out the help text changes

This pull request has now been integrated.

Changeset: 71c4b195
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/71c4b195178029f5414fa45d2c5ac70a1d2536e5
Stats: 20 lines in 4 files changed: 18 ins; 0 del; 2 mod

8276562: Fix to JDK-8263155 left out the help text changes

Reviewed-by: asemenyuk, almatvee

-

PR: https://git.openjdk.java.net/jdk/pull/6281

RFR: JDK-8276562: Fix to JDK-8263155 left out the help text changes

[Andy Herrick]

JDK-8276562: Fix to JDK-8263155 left out the help text changes

-

Commit messages:
 - JDK-8276562: Fix to JDK-8263155 left out the help text changes

Changes: https://git.openjdk.java.net/jdk/pull/6281/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6281=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276562
  Stats: 20 lines in 4 files changed: 18 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6281/head:pull/6281

PR: https://git.openjdk.java.net/jdk/pull/6281

Integrated: JDK-8263155: Allow additional contents for DMG

[Andy Herrick]

On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick  wrote:

> JDK-8263155: Allow additional contents for DMG

This pull request has now been integrated.

Changeset: b2128a96
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/b2128a96670daeca93aca84ee7613b2b337ddfa4
Stats: 171 lines in 8 files changed: 154 ins; 1 del; 16 mod

8263155: Allow additional contents for DMG

Reviewed-by: asemenyuk, almatvee

-

PR: https://git.openjdk.java.net/jdk/pull/5912

Re: RFR: JDK-8263155: Allow additional contents for DMG [v2]

[Andy Herrick]

> JDK-8263155: Allow additional contents for DMG

Andy Herrick has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8263155
 - Merge branch 'master' into JDK-8263155
 - JDK-8263155: Allow additional contents for DMG
 - JDK-8263155: Allow additional contents for DMG
 - JDK-8263155: Allow additional contents for DMG

-

Changes: https://git.openjdk.java.net/jdk/pull/5912/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5912=01
  Stats: 171 lines in 8 files changed: 154 ins; 1 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5912.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5912/head:pull/5912

PR: https://git.openjdk.java.net/jdk/pull/5912

Integrated: 8274346: Support for additional content in an app-image.

[Andy Herrick]

On Thu, 30 Sep 2021 18:51:49 GMT, Andy Herrick  wrote:

> 8274346: Support for additional content in an app-image.

This pull request has now been integrated.

Changeset: d548f2fc
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/d548f2fc0dbc9e7864dd1701873bbf3d12a75ecb
Stats: 167 lines in 10 files changed: 157 ins; 0 del; 10 mod

8274346: Support for additional content in an app-image.

Reviewed-by: asemenyuk, almatvee

-

PR: https://git.openjdk.java.net/jdk/pull/5780

Re: RFR: JDK-8263155: Allow additional contents for DMG

[Andy Herrick]

On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick  wrote:

> JDK-8263155: Allow additional contents for DMG

This enhancement adds a command line option "--mac-dmg-content" that can be 
used to add any other content to a dmg image.  The default DMGsetup.scpt  is 
modified to show all the additional content on a second row in Finder (under 
the application or java runtime and it's install directory).
Changes only ap[ply to dmg type bundles

-

PR: https://git.openjdk.java.net/jdk/pull/5912

RFR: JDK-8263155: Allow additional contents for DMG

[Andy Herrick]

JDK-8263155: Allow additional contents for DMG

-

Commit messages:
 - JDK-8263155: Allow additional contents for DMG
 - JDK-8263155: Allow additional contents for DMG
 - JDK-8263155: Allow additional contents for DMG

Changes: https://git.openjdk.java.net/jdk/pull/5912/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5912=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263155
  Stats: 169 lines in 8 files changed: 153 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5912.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5912/head:pull/5912

PR: https://git.openjdk.java.net/jdk/pull/5912

Re: RFR: 8274346: Support for additional content in an app-image. [v2]

[Andy Herrick]

> 8274346: Support for additional content in an app-image.

Andy Herrick has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8274346: Support for additional content in an app-image.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5780/files
  - new: https://git.openjdk.java.net/jdk/pull/5780/files/d53b8647..bf2dd5e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5780=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5780=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5780.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5780/head:pull/5780

PR: https://git.openjdk.java.net/jdk/pull/5780

Re: RFR: 8274346: Support for additional content in an app-image.

[Andy Herrick]

On Thu, 30 Sep 2021 18:51:49 GMT, Andy Herrick  wrote:

> 8274346: Support for additional content in an app-image.

CSR is at: https://bugs.openjdk.java.net/browse/JDK-8274717

-

PR: https://git.openjdk.java.net/jdk/pull/5780

RFR: 8274346: Support for additional content in an app-image.

[Andy Herrick]

8274346: Support for additional content in an app-image.

-

Commit messages:
 - JDK-8274346: Support for additional content in an app-image.
 - JDK-8274346: Support for additional content in an app-image.
 - JDK-8274346: Support for additional content in an app-image.

Changes: https://git.openjdk.java.net/jdk/pull/5780/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5780=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274346
  Stats: 168 lines in 10 files changed: 158 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5780.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5780/head:pull/5780

PR: https://git.openjdk.java.net/jdk/pull/5780

Integrated: JDK-8274087: Windows DLL path not set correctly.

[Andy Herrick]

On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick  wrote:

> JDK-8274087: Windows DLL path not set correctly.

This pull request has now been integrated.

Changeset: f36a2bbd
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/f36a2bbd15d94d4371c2117ce08b7f04a0d59da4
Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod

8274087: Windows DLL path not set correctly.

Reviewed-by: almatvee, asemenyuk

-

PR: https://git.openjdk.java.net/jdk/pull/5663

RFR: JDK-8274087: Windows DLL path not set correctly.

[Andy Herrick]

JDK-8274087: Windows DLL path not set correctly.

-

Commit messages:
 - JDK-8274087: Windows DLL path not set correctly.

Changes: https://git.openjdk.java.net/jdk/pull/5663/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5663=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274087
  Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5663/head:pull/5663

PR: https://git.openjdk.java.net/jdk/pull/5663

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I also had a JDK16 bin dir on my path ...

I can get the error you show below (Error occurred during initialization 
of VM) if I clear my PATH, which is different from the error I get when 
running without moved runtime, so I can reproduce problem and test the fix.


I am using a script like:



./gradlew.bat clean build

cp -r build/application build/app2
mv build/app2/FetchURL/jre build/app2/FetchURL/runtime
cp FetchURLcfg.save build/app2/FetchURL/app/FetchURL.cfg

export PATH=

echo ""
echo "RUN as built:"
echo ""
build/application/FetchURL/FetchURL

echo ""
echo "RUN with default runtime:"
echo ""
build/app2/FetchURL/FetchURL

after fix both runs should have the same behavior and there should be no 
error like:



Error occurred during initialization of VM
Could not find agent library instrument on the library path, with 
error: Can't find dependent libraries

Module java.instrument may be missing from runtime image.


/Andy

On 9/22/2021 11:44 AM, Scott Palmer wrote:



On Sep 22, 2021, at 11:22 AM, Andy Herrick <mailto:andy.herr...@oracle.com>> wrote:


I still don't get the error your report.  Is there something else 
that needs to be set up for using instrumentation ?


Nothing that I’m aware of.  Maybe there is something to do with Visual 
C/C++ runtime libraries that I have installed globally? -just a wild 
guess.


Ohhh… here’s something…

I had JDK 17 ‘bin’ folder on my PATH (along with many other things)
If I clear the PATH env var with:
 set PATH=

Then I get an different error:

Error occurred during initialization of VM
Could not find agent library instrument on the library path, with 
error: Can’t find dependent libraries

Module java.instrument may be missing from runtime image.

All I have to do to et back to the original error is

set PATH=C:\Tools\jdk-17\bin

So this is definitely related to the DLL search path, and it was just 
lucky that some libraries were found via PATH in my environment.




I do get a different error when I have both runtime and jre 
directories after "cp -r jre runtime" (in 
FetchURL/build/application/FetchURL dir)


As built (before copy):


$ ./FetchURL
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" 
with message c

an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at 
JPLISAgent.c line: 400


FATAL ERROR in native method: processing of -javaagent failed


after copy:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassL

oaderUtils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas

sLoader.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl

assLoaders.java:182)
    at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg

ent(InstrumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre

main(InstrumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/p
remain call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstr

ument\JPLISAgent.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart f

ailed


but then with jre removed and line in cfg removed I get the same error:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassLoaderUt

ils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader

.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad

ers.java:182)
    at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins

trumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In

strumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/premain
call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge

nt.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart failed


note the "t:\workspace" ?  I don't have a t: drive, where is that 
coming from ?


Must be from how the JDK was built.  I don’t have a T: drive either.

jar -tvf build\application\FetchURL\app\libs\FetchURL-0.0.01.jar
     0 Wed Sep 22 11:16:40 EDT 2021 META-INF/
   248 Wed Sep 22 11:16:40 EDT 2021 META-INF/MANIFEST.MF
     0 Wed Sep 22 11:10:30 EDT 2021 io/
     0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/
     0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/
     0 Wed Sep 22 11:10:30 EDT 

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I still don't get the error your report.  Is there something else that 
needs to be set up for using instrumentation ?


I do get a different error when I have both runtime and jre directories 
after "cp -r jre runtime" (in FetchURL/build/application/FetchURL dir)


As built (before copy):


$ ./FetchURL
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" 
with message c

an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at 
JPLISAgent.c line: 400


FATAL ERROR in native method: processing of -javaagent failed


after copy:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassL

oaderUtils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas

sLoader.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl

assLoaders.java:182)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg

ent(InstrumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre

main(InstrumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/p
remain call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstr

ument\JPLISAgent.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart f

ailed


but then with jre removed and line in cfg removed I get the same error:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassLoaderUt

ils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader

.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad

ers.java:182)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins

trumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In

strumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/premain
call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge

nt.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart failed


note the "t:\workspace" ?  I don't have a t: drive, where is that coming 
from ?


/Andy


On 9/22/2021 10:25 AM, Scott Palmer wrote:

Sorry That last build with the Oracle OpenJDK needed the build file changed to 
have

vendor = JvmVendorSpec.ORACLE

as well as the command line property pointing to the path to the jdk,

Scott



On Sep 22, 2021, at 10:24 AM, Scott Palmer  wrote:

I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules 
bundled) and I just changed:

vendor = JvmVendorSpec.ADOPTOPENJDK

And get the same error with that build of OpenJDK as well.  “OpenJDK Runtime 
Environment Temurin-17+35 (build 17+35)”
You can try that, as Gradle should download the JDK for you.

I then downloaded the Oracle build of OpenJDK from 
https://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzZBwkTMGA$
 (build 17+35-2724)
unzipped it to C:\Tools
building with:

gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build

I still reproduce the error.

Though the assertion in native JVM code that you are getting looks like yet 
another bug!  So perhaps it is good that it is discovered as well.


Scott


On Sep 22, 2021, at 9:54 AM, Andy Herrick  wrote:

I can't seem to get your testcase to work with the Oracle JDK configured.

I can build, but then when I run

$ ./build/application/FetchURL/FetchURL.exe

I get:


*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message 
c
an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c line: 
400

FATAL ERROR in native method: processing of -javaagent failed

same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove 
app.runtime entry.

anyway I used your two source files to build the test app without gradle, and 
the test can download 
https://urldefense.com/v3/__https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzbGSGkGog$
  without any problems.

I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to cfg 
file and app still ran fine (downloaded the above)

So I still don't have any way to reproduce this problemwith the Or

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I can't seem to get your testcase to work with the Oracle JDK configured.

I can build, but then when I run

$ ./build/application/FetchURL/FetchURL.exe

I get:

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" 
with message c

an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at 
JPLISAgent.c line: 400


FATAL ERROR in native method: processing of -javaagent failed
same behavior if I restore "runtime" directory and fix FetchURL.cfg to 
remove app.runtime entry.


anyway I used your two source files to build the test app without 
gradle, and the test can download 
https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 
without any problems.


I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" 
to cfg file and app still ran fine (downloaded the above)


So I still don't have any way to reproduce this problemwith the Oracle jdk.

/Andy


PS:

Although something somewhere else may have changed to counter the 
problem, it's clear from your description, that since the only place in 
the code the default runtime path is used (instead of the actual runtime 
path, which may be different) is the line in WinLauncher.cpp to call 
SetDllDirectory().


This should be fixed - but would like a way to reproduce the problem it 
causes first.


/Andy

On 9/21/2021 12:12 PM, Andy Herrick wrote:
I thought I could create a reproduction scenario by using an app with 
"-splash:" arg then moving the jre as you did, but I have 
not yet been able make it fail.


/Andy

On 9/21/2021 11:43 AM, Scott Palmer wrote:
On Sep 21, 2021, at 11:40 AM, Alan Bateman  
wrote:


On 21/09/2021 15:54, Andy Herrick wrote:
I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp


we call SetDllDirectory() with the path to the bin dir in the 
default runtime directory, not the actual runtime directory.


since on Windows we never use other than the default runtime 
location - we had not seen a problem, but is bug I will file and fix.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM to 
blow up during early startup. Would you have cycles to dig into that 
a bit more in case something has been masked, like for example an 
exception being swallowed.  Running with -Xlog:exceptions might 
reveal something.


Do you have a case that reproduces the issue?

Scott

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

Thanks Scott

This will help a lot because I couldn't reproduce this using just a 
splash screen as I expected I could.


I will look at this example this morning.

/Andy

On 9/21/21 7:05 PM, Scott Palmer wrote:
I’ve uploaded a project that reproduces the problem to JDK-8274087 
<https://bugs.openjdk.java.net/browse/JDK-8274087>


Regards,

Scott

On Sep 21, 2021, at 3:49 PM, Scott Palmer <mailto:swpal...@gmail.com>> wrote:


I have discovered that I have to have my Java Agent configured  in 
the .cfg file for it to happen:


[JavaOptions]
java-option=-javaagent:$APPDIR\libs\MyAgent.jar


The agent is needed in my real app only to get an instance of the 
Instrumentation interface. In my test code, where I have reproduced 
this, it is never used.  My test app just takes a URL and fetches it 
via a HttpURLConnection with setInstanceFollowRedirects(false) so I 
can capture the new location.  If you are still having trouble 
reproducing I will have the code cleaned up for the bug report soon...



Regards,

Scott



On Sep 21, 2021, at 12:12 PM, Andy Herrick <mailto:andy.herr...@oracle.com>> wrote:


I thought I could create a reproduction scenario by using an app 
with "-splash:" arg then moving the jre as you did, but 
I have not yet been able make it fail.


/Andy

On 9/21/2021 11:43 AM, Scott Palmer wrote:
On Sep 21, 2021, at 11:40 AM, Alan Bateman 
mailto:alan.bate...@oracle.com>> wrote:


On 21/09/2021 15:54, Andy Herrick wrote:
I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp


we call SetDllDirectory() with the path to the bin dir in the 
default runtime directory, not the actual runtime directory.


since on Windows we never use other than the default runtime 
location - we had not seen a problem, but is bug I will file and fix.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM 
to blow up during early startup. Would you have cycles to dig into 
that a bit more in case something has been masked, like for 
example an exception being swallowed.  Running with 
-Xlog:exceptions might reveal something.


Do you have a case that reproduces the issue?

Scott

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I thought I could create a reproduction scenario by using an app with 
"-splash:" arg then moving the jre as you did, but I have 
not yet been able make it fail.


/Andy

On 9/21/2021 11:43 AM, Scott Palmer wrote:

On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:

On 21/09/2021 15:54, Andy Herrick wrote:

I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp

we call SetDllDirectory() with the path to the bin dir in the default runtime 
directory, not the actual runtime directory.

since on Windows we never use other than the default runtime location - we had 
not seen a problem, but is bug I will file and fix.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM to blow up 
during early startup. Would you have cycles to dig into that a bit more in case 
something has been masked, like for example an exception being swallowed.  
Running with -Xlog:exceptions might reveal something.


Do you have a case that reproduces the issue?

Scott

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I filed:     JDK-8274087: Windows DLL path not set correctly.

for this, and will work on a fix for JDK18 and backport to JDK17.0.2.

/Andy

On 9/21/2021 10:54 AM, Andy Herrick wrote:
I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp


we call SetDllDirectory() with the path to the bin dir in the default 
runtime directory, not the actual runtime directory.


since on Windows we never use other than the default runtime location 
- we had not seen a problem, but is bug I will file and fix.


Thanks.

/Andy

On 9/21/2021 10:17 AM, Scott Palmer wrote:
This is on Windows 10 Pro.  using JDK 17 for jpackage and I'm pretty 
sure for jimage  (though the image was made shortly after 17 GA and 
is being reused)..


There are no libraries directly in $APPDIR, though there are plenty 
in other sibling folders to the 'app' folder (in addition to those in 
app\libs)


I changed app.runtime to point to the (relative) path without the 
$APPDIR\.. - same problem. Tried a absolute path, same problem.


The exact same runtime folder that was failing for me was simply 
copied to the default location to make it work.  It works if I leave 
app.runtime out of the .cfg file, or if I point to $APPDIR\..\runtime


I did some more experiments and found that if I just rename the 
'runtime' folder to 'jre', but leave it at the same depth then the 
problem appears.


I suspected there must be some hardcoded reference to the 'runtime' 
folder in the app launcher.  However, if I have two copies of the 
runtime, one at the default location, and use app.runtime to point to 
the other copy it still fails. (i.e. if it is referencing some 
library from the default location it doesn't help.. I thought it 
might, being that it is all in the same process.)


The application is complex.  It has a plugin mechanism that uses an 
Agent and the Instrument class to augment the classpath at runtime.


(Older versions of the plugin mechanism used to hack the System 
classloader on JDK 8 and switching to an Agent was the fastest way to 
make it work on later versions in a supported manner. It likely 
should be using custom classloaders, but classloading issues got 
messy when I looked into that way back when we started.)


I will try to find time later this week to isolate a test case that 
can reproduce it.  For now I can work around the issue by putting the 
runtime back to the default location for this case. This is a special 
case of an application that actually includes the JRE itself as one 
of the plugins so we can upgrade the JRE after the initial deployment 
or run different jobs with different JREs.  I was trying to make a 
smaller tool/demo that used the JRE from where it would be in our 
"plugin" folder.


Regards,

Scott

On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick <mailto:andy.herr...@oracle.com>> wrote:


    I don't see anything wrong with this offhand. the runtime should
    be able
    to be anywhere if the cfg files "app.runtime" line points to it.

    Is this on windows ? Is the the released JDK17 used both for the
    jlinked
    runtime and the jpackage tool ?

    Are there any libraries in $APPDIR (which is added to the $PATH env
    variable on windows) which could be interfering with encoding
    initialization ?

    Can you try the following experiment:

    manually edit the cfg file line:

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

    to contain the canonical path to
    ...\my_own_folder\where_the_jre_is_deeper\jre

    and try again ?


    /Andy

    On 9/20/2021 5:37 PM, Scott Palmer wrote:
    > This is likely not the right place to ask this (sorry).. but I'm
    trying to
    > get info to write a bug report and want to make sure I'm not doing
    > something stupid first.
    >
    > I've created a JRE image from JDK 17 with jlink.  I've made an
    > application image with jpackage.  I've moved the default
    location of the
    > runtime in the application image and modified the launcher .cfg 
file

    > accordingly by adding a line to the [Application] section
    >
    > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
    >
    > My application launches.  It shows a JavaFX GUI.  It does a
    bunch of stuff
    > that "works", but then one thread fails with this exception:
    >
    > Exception in thread "Reader-BG-1" java.lang.InternalError: 
platform

    > encoding not initialized
    >          at java.base/java.net
<https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.Inet6AddressImpl.lookupAllHostAddr(Native
    > Method)
    >          at
    > java.base/java.net
<https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress$PlatformNameSer

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp


we call SetDllDirectory() with the path to the bin dir in the default 
runtime directory, not the actual runtime directory.


since on Windows we never use other than the default runtime location - 
we had not seen a problem, but is bug I will file and fix.


Thanks.

/Andy

On 9/21/2021 10:17 AM, Scott Palmer wrote:
This is on Windows 10 Pro.  using JDK 17 for jpackage and I'm pretty 
sure for jimage  (though the image was made shortly after 17 GA and is 
being reused)..


There are no libraries directly in $APPDIR, though there are plenty in 
other sibling folders to the 'app' folder (in addition to those in 
app\libs)


I changed app.runtime to point to the (relative) path without the 
$APPDIR\.. - same problem. Tried a absolute path, same problem.


The exact same runtime folder that was failing for me was simply 
copied to the default location to make it work.  It works if I leave 
app.runtime out of the .cfg file, or if I point to $APPDIR\..\runtime


I did some more experiments and found that if I just rename the 
'runtime' folder to 'jre', but leave it at the same depth then the 
problem appears.


I suspected there must be some hardcoded reference to the 'runtime' 
folder in the app launcher.  However, if I have two copies of the 
runtime, one at the default location, and use app.runtime to point to 
the other copy it still fails. (i.e. if it is referencing some library 
from the default location it doesn't help.. I thought it might, being 
that it is all in the same process.)


The application is complex.  It has a plugin mechanism that uses an 
Agent and the Instrument class to augment the classpath at runtime.


(Older versions of the plugin mechanism used to hack the System 
classloader on JDK 8 and switching to an Agent was the fastest way to 
make it work on later versions in a supported manner. It likely should 
be using custom classloaders, but classloading issues got messy when I 
looked into that way back when we started.)


I will try to find time later this week to isolate a test case that 
can reproduce it.  For now I can work around the issue by putting the 
runtime back to the default location for this case.  This is a special 
case of an application that actually includes the JRE itself as one of 
the plugins so we can upgrade the JRE after the initial deployment or 
run different jobs with different JREs.  I was trying to make a 
smaller tool/demo that used the JRE from where it would be in our 
"plugin" folder.


Regards,

Scott

On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick <mailto:andy.herr...@oracle.com>> wrote:


I don't see anything wrong with this offhand. the runtime should
be able
to be anywhere if the cfg files "app.runtime" line points to it.

Is this on windows ? Is the the released JDK17 used both for the
jlinked
runtime and the jpackage tool ?

Are there any libraries in $APPDIR (which is added to the $PATH env
variable on windows) which could be interfering with encoding
initialization ?

Can you try the following experiment:

manually edit the cfg file line:

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

to contain the canonical path to
...\my_own_folder\where_the_jre_is_deeper\jre

and try again ?


/Andy

On 9/20/2021 5:37 PM, Scott Palmer wrote:
> This is likely not the right place to ask this (sorry).. but I'm
trying to
> get info to write a bug report and want to make sure I'm not doing
> something stupid first.
>
> I've created a JRE image from JDK 17 with jlink.  I've made an
> application image with jpackage.  I've moved the default
location of the
> runtime in the application image and modified the launcher .cfg file
> accordingly by adding a line to the [Application] section
>
> app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
>
> My application launches.  It shows a JavaFX GUI.  It does a
bunch of stuff
> that "works", but then one thread fails with this exception:
>
> Exception in thread "Reader-BG-1" java.lang.InternalError: platform
> encoding not initialized
>          at java.base/java.net

<https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.Inet6AddressImpl.lookupAllHostAddr(Native
> Method)
>          at
> java.base/java.net

<https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
>          at
> java.base/java.net

<https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!

Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I don't see anything wrong with this offhand. the runtime should be able 
to be anywhere if the cfg files "app.runtime" line points to it.


Is this on windows ? Is the the released JDK17 used both for the jlinked 
runtime and the jpackage tool ?


Are there any libraries in $APPDIR (which is added to the $PATH env 
variable on windows) which could be interfering with encoding 
initialization ?


Can you try the following experiment:

manually edit the cfg file line:

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

to contain the canonical path to 
...\my_own_folder\where_the_jre_is_deeper\jre


and try again ?


/Andy

On 9/20/2021 5:37 PM, Scott Palmer wrote:

This is likely not the right place to ask this (sorry).. but I'm trying to
get info to write a bug report and want to make sure I'm not doing
something stupid first.

I've created a JRE image from JDK 17 with jlink.  I've made an
application image with jpackage.  I've moved the default location of the
runtime in the application image and modified the launcher .cfg file
accordingly by adding a line to the [Application] section

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

My application launches.  It shows a JavaFX GUI.  It does a bunch of stuff
that "works", but then one thread fails with this exception:

Exception in thread "Reader-BG-1" java.lang.InternalError: platform
encoding not initialized
 at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native
Method)
 at
java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
 at
java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519)
 at
java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:852)
 at
java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509)
 at
java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367)
 at
java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301)
 at java.base/java.net.InetAddress.getByName(InetAddress.java:1251)
 at
java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229)
 at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:178)
 at
java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498)
 at
java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603)
 at
java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266)
 at
java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380)
 at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189)
 at
java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242)
 at
java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128)
 at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175)
 at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665)
 at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589)
 at
java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:529)
 at
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308)

If I keep the runtime in $APPDIR\runtime, things don't fail in this way.

Smells like a bug in the app launcher to me.. but maybe it's in the runtime?

Any assistance would be appreciated (including telling me where I should go
to ask this, if this list isn't appropriate).

Thanks,

Scott

Re: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null]

[Andy Herrick]

On Tue, 14 Sep 2021 17:21:29 GMT, Alexey Semenyuk  wrote:

> Fix jpackage error output when "--type" CLI option is missing and jpackage 
> detects that it can't build native packages in the environment.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5512

Integrated: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)

[Andy Herrick]

On Tue, 14 Sep 2021 13:38:42 GMT, Andy Herrick  wrote:

> JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)

This pull request has now been integrated.

Changeset: 22a7191f
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/22a7191f700c6966c59dcd12476f01452243542b
Stats: 17 lines in 3 files changed: 7 ins; 5 del; 5 mod

8273040: Turning off JpAllowDowngrades (or Upgrades)

Reviewed-by: asemenyuk

-

PR: https://git.openjdk.java.net/jdk/pull/5509

RFR: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)

[Andy Herrick]

JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)

-

Commit messages:
 - JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)
 - JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)

Changes: https://git.openjdk.java.net/jdk/pull/5509/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5509=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273040
  Stats: 17 lines in 3 files changed: 7 ins; 5 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5509.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5509/head:pull/5509

PR: https://git.openjdk.java.net/jdk/pull/5509

Re: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian

[Andy Herrick]

On Fri, 10 Sep 2021 12:03:48 GMT, Ao Qi  wrote:

> A similar issue on Ubuntu has been fixed by 
> [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, 
> tools/jpackage tests do not work on Debian Linux or other apt-based Linux, 
> when rpm package is installed. This issue proposes a general fix for 
> apt-based Linux.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5462

[jdk17] Integrated: JDK-8273592: Backout JDK-8271868

[Andy Herrick]

On Fri, 10 Sep 2021 13:18:49 GMT, Andy Herrick  wrote:

> JDK-8271868 was pushed to JDK17 instead of jdk17u.
> This change is to back it out

This pull request has now been integrated.

Changeset: 4afbcaf5
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk17/commit/4afbcaf55383ec2f5da53282a1547bac3d099e9d
Stats: 65 lines in 9 files changed: 11 ins; 46 del; 8 mod

8273592: Backout JDK-8271868

Reviewed-by: kcr, asemenyuk

-

PR: https://git.openjdk.java.net/jdk17/pull/307

[jdk17] RFR: JDK-8273592: Backout JDK-8271868

[Andy Herrick]

JDK-8271868 was pushed to JDK17 instead of jdk17u.
This change is to back it out

-

Commit messages:
 - JDK-8273592: Backout JDK-8271868

Changes: https://git.openjdk.java.net/jdk17/pull/307/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=307=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273592
  Stats: 65 lines in 9 files changed: 11 ins; 46 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/307/head:pull/307

PR: https://git.openjdk.java.net/jdk17/pull/307

[jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac

[Andy Herrick]

backport from jdk-18

-

Commit messages:
 - JDK-8272639: jpackaged applications using microphone on mac

Changes: https://git.openjdk.java.net/jdk17/pull/306/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=306=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272639
  Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/306/head:pull/306

PR: https://git.openjdk.java.net/jdk17/pull/306

[jdk17] Integrated: 8271868: Warn user when using mac-sign option with unsigned app-image.

[Andy Herrick]

On Thu, 9 Sep 2021 16:36:44 GMT, Andy Herrick  wrote:

> This is a backport from JDK-18

This pull request has now been integrated.

Changeset: a37254c7
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk17/commit/a37254c79fa5973465d90f4b52ab88fe68016c9f
Stats: 65 lines in 9 files changed: 46 ins; 11 del; 8 mod

8271868: Warn user when using mac-sign option with unsigned app-image.

Reviewed-by: asemenyuk

-

PR: https://git.openjdk.java.net/jdk17/pull/305

[jdk17] RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

[Andy Herrick]

This is a backport from JDK-18

-

Commit messages:
 - JDK-8271868: Warn user when using mac-sign option with unsigned 
app-image.

Changes: https://git.openjdk.java.net/jdk17/pull/305/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=305=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271868
  Stats: 65 lines in 9 files changed: 46 ins; 11 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/305.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/305/head:pull/305

PR: https://git.openjdk.java.net/jdk17/pull/305

Re: [External] : Re: JPackage and ask for microphone permissions broken on OSX...

[Andy Herrick]

On 8/25/2021 9:40 AM, Alan Snyder wrote:



On Aug 24, 2021, at 6:52 AM, Andy Herrick <mailto:andy.herr...@oracle.com>> wrote:


One final thing to note, MacOS keeps track of what you have ever 
previously granted microphone permission to (and will never ask 
again) based on the mac package identifier (which defaults to the 
main class name), so I explicitly set this using a shell script with 
jpackage option "--mac-package-identifier audio-$1" option, so I can 
pass in different values and create a unique one each time.


I’ve been wondering what you mean here.

Are you saying that you routinely generate random package identifiers 
or is this a workaround that you use in special circumstances?


  Alan

no - I am just generating unique package identifiers to test this 
microphone permission dialog,


/Andy

Integrated: JDK-8272639: jpackaged applications using microphone on mac

[Andy Herrick]

On Thu, 19 Aug 2021 14:12:00 GMT, Andy Herrick  wrote:

> JDK-8272639: jpackaged applications using microphone on mac

This pull request has now been integrated.

Changeset: b17b821a
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/b17b821a570930e4188bcdfb396f0a7abe99caf6
Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod

8272639: jpackaged applications using microphone on mac

Reviewed-by: almatvee, serb

-

PR: https://git.openjdk.java.net/jdk/pull/5186

Re: JPackage and ask for microphone permissions broken on OSX...

[Andy Herrick]

On 8/24/2021 6:08 AM, Filteredaccount1 wrote:

Hi Andy,

During the wait for JDK 18, would it be possible to describe on the bug ticket 
what manual workaround steps are required to apply to an existing jPackaged app 
for distribution both inside and outside the app store?


The instructions for working around this bug as described are in public 
comment in https://bugs.openjdk.java.net/browse/


The related app-store specific change is in the default entitlements 
file.  I will add comment to JDK-8272639. explaining how to work around 
that issue by using the --entitlements option.


There is one Info.plist for the app (.app/Contents/Info.plist) and 
another for the runtime (.app/Contents/runtime/Contents/Info.plist).


Only the first one is relevant here.  The key 
NSMicrophoneUsageDescription belongs in the entitlements file 
(not the Info.plist).


The default entitlements file for an app-store targeted app is 
src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/sandbox.plist 
, 
<https://github.com/openjdk/jdk/pull/5186/files#diff-064af7746a071efb64f850693ba0a83822ce96219333055600fdd9e42f878fc9>but 
that can be overridden using the --mac-entitlements option.


One final thing to note, MacOS keeps track of what you have ever 
previously granted microphone permission to (and will never ask again) 
based on the mac package identifier (which defaults to the main class 
name), so I explicitly set this using a shell script with jpackage 
option "--mac-package-identifier audio-$1" option, so I can pass in 
different values and create a unique one each time.


Hope this helps.

/Andy



There are two info.plist files inside a jPackaged app. In my experience adding 
keys to both didn’t turn the ask microphone permissions on.

com.apple.security.device.audio-input


The application is requesting access to the microphone.

Also, I raised at http://bugreport.java.com/ 9071230. So developer time isn’t 
wasted, could this be cancelled? (seems setup so the general public cannot).


I can't see this issue, so it must already have been removed.

/Andy



Thank You,

Ben S.



Date: Wed, 18 Aug 2021 08:43:08 -0400
From: Andy Herrick 
To: core-libs-dev@openjdk.java.net
Subject: Re: JPackage and ask for microphone permissions broken on
OSX...
Message-ID: <1534b02b-262a-f338-aae5-d1693d007...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

OK - I have reproduced this problem, filed an issue, and found the fix.

You can see the issue in https://bugs.openjdk.java.net/browse/JDK-8272639.

Basically another key is needed in application plist to cause
application to ask for microphone access.

It is far to late to get any fix into JDK17, but I will fix in JDK18 and
you can work around this issue in JDK17 (or JDK16) by using the
--resource-dir option:

Re: RFR: JDK-8272639: jpackaged applications using microphone on mac [v2]

[Andy Herrick]

> JDK-8272639: jpackaged applications using microphone on mac

Andy Herrick has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8272639: jpackaged applications using microphone on mac

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5186/files
  - new: https://git.openjdk.java.net/jdk/pull/5186/files/e1f460e1..337e1fa1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5186=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5186=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5186.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5186/head:pull/5186

PR: https://git.openjdk.java.net/jdk/pull/5186

Re: RFR: JDK-8272639: jpackaged applications using microphone on mac

[Andy Herrick]

On Thu, 19 Aug 2021 22:46:18 GMT, Sergey Bylokhov  wrote:

>> JDK-8272639: jpackaged applications using microphone on mac
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template
>  line 37:
> 
>> 35:   true
>> 36:   NSMicrophoneUsageDescription
>> 37:   The application is requesting access to the 
>> microphone.
> 
> Should not it include the "application name" here? This is different from the 
> java tool, where we do not know that info in advance.

Yes - I will revise with name substituted here.
I also considered localizing this string, but we only support localization of 
the tool, which would put string in the local that jpackage was run in, not the 
local the generated artifact was run in.

-

PR: https://git.openjdk.java.net/jdk/pull/5186

RFR: JDK-8272639: jpackaged applications using microphone on mac

[Andy Herrick]

JDK-8272639: jpackaged applications using microphone on mac

-

Commit messages:
 - JDK-8272639: jpackaged applications using microphone on mac

Changes: https://git.openjdk.java.net/jdk/pull/5186/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5186=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272639
  Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5186.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5186/head:pull/5186

PR: https://git.openjdk.java.net/jdk/pull/5186

Re: JPackage and ask for microphone permissions broken on OSX...

[Andy Herrick]

OK - I have reproduced this problem, filed an issue, and found the fix.

You can see the issue in https://bugs.openjdk.java.net/browse/JDK-8272639.

Basically another key is needed in application plist to cause 
application to ask for microphone access.


It is far to late to get any fix into JDK17, but I will fix in JDK18 and 
you can work around this issue in JDK17 (or JDK16) by using the 
--resource-dir option:


/Andy



1.) create an empty directory test-resources
2.) copy from the openjdk sources the file 
src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template 
to test-resources/Info.plist.

3.) edit test-resources/info.plist to include the key:
   NSMicrophoneUsageDescription
The application is requesting access to the 
microphone.
4.) now add "--resource-dir test-resources" option to your jpackage 
command, and it will use this plist template instead of the default one. 


On 8/16/21 7:41 PM, Filteredaccount1 wrote:

Hi Core-libs-dev,

I’m trying to report an issue with JPackage on recent versions of OSX.

Problem is, the microphone permissions aren’t granted to applications created 
by jpackage. The resulting recorded 16 bit PCM line in samples files are the 
correct duration, but don’t have any sound (samples all set to 0).

System Preferences -> Security & Privacy -> Privacy -> Microphone
(application never asks for permissions)

Otherwise, the only workaround I can figure out is to have the app launch then 
bootstrap itself using Runtime and grant applications to the Terminal.app (when 
it calls itself from `java Application.app/MacOS/Resources/Application`)

There are various reports of this on the Internet - but I’m wondering if the 
JPackage team is aware of the issue.

https://stackoverflow.com/questions/55727488/application-doesnt-ask-for-permission-to-access-microphone-in-macos-10-14-mojav

This pretty much shows the solution - needs a bit of Objective C though.

Reproducing the problem: JPackage any java sound recording app on latest OSX, 
run it... will be unable to capture sound. Run the same code from the command 
line, via classpath or modules... it will record audio after asking the user to 
grant microphone permissions to Terminal.app.

It would be great if this is fixed in JDK 17.


Many Thanks,


Ben S

Re: RFR: 8272328: java.library.path is not set properly by Windows jpackage app launcher

[Andy Herrick]

On Wed, 11 Aug 2021 17:52:57 GMT, Alexey Semenyuk  wrote:

> Restart window app launcher to make changes made to `PATH` env variable 
> visible to JLI code in 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L347

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5090

Re: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v2]

[Andy Herrick]

On Mon, 9 Aug 2021 18:19:03 GMT, Alexey Semenyuk  wrote:

>> Added jtreg test to verify jpackage launcher adds app dir to 
>> `java.library.path` system property.
>> Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java.
>> Moved test/jdk/tools/jpackage/apps/image/Hello.java to 
>> test/jdk/tools/jpackage/apps/Hello.java.
>
> Alexey Semenyuk has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Handle duplicate elements in `java.library.path` system property value.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5056

Integrated: 8271868: Warn user when using mac-sign option with unsigned app-image.

[Andy Herrick]

On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick  wrote:

> 8271868: Warn user when using mac-sign option with unsigned app-image.

This pull request has now been integrated.

Changeset: 0aca4f72
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/0aca4f72ce48bc75f2c466d1cba4ad70d3c7b875
Stats: 65 lines in 9 files changed: 46 ins; 11 del; 8 mod

8271868: Warn user when using mac-sign option with unsigned app-image.

Reviewed-by: almatvee, asemenyuk

-

PR: https://git.openjdk.java.net/jdk/pull/5004

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2]

[Andy Herrick]

On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick  wrote:

>> 8271868: Warn user when using mac-sign option with unsigned app-image.
>
> Andy Herrick has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   JDK-8271868: Warn user when using mac-sign option with unsigned app-image.

will fix this spelling error

-

PR: https://git.openjdk.java.net/jdk/pull/5004

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2]

[Andy Herrick]

On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick  wrote:

>> 8271868: Warn user when using mac-sign option with unsigned app-image.
>
> Andy Herrick has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   JDK-8271868: Warn user when using mac-sign option with unsigned app-image.

now recording in AppImageFile if signing used to create the app-image, and 
showing warning only if signing an app using an app-image that is not so 
recorded as signed.

-

PR: https://git.openjdk.java.net/jdk/pull/5004

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2]

[Andy Herrick]

> 8271868: Warn user when using mac-sign option with unsigned app-image.

Andy Herrick has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8271868: Warn user when using mac-sign option with unsigned app-image.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5004/files
  - new: https://git.openjdk.java.net/jdk/pull/5004/files/153e75ea..afc0f197

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5004=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5004=00-01

  Stats: 72 lines in 6 files changed: 30 ins; 27 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5004/head:pull/5004

PR: https://git.openjdk.java.net/jdk/pull/5004

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

[Andy Herrick]

On Wed, 4 Aug 2021 20:56:46 GMT, Alexander Matveev  wrote:

>> 8271868: Warn user when using mac-sign option with unsigned app-image.
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java
>  line 142:
> 
>> 140: // is not allready signed.
>> 141: Path launcher = 
>> applicationImage.resolve("Contents/MacOS")
>> 142: .resolve(APP_NAME.fetchFrom(params));
> 
> As far as I remember launcher can be signed, but entire app image might not 
> be signed. So, in this case check will pass, but notarization will fail. I 
> think we should run check on app image itself.

jpackage will either copy the launcher from resource unmodified and unsigned, 
or sign all the sign-able elements in the app-image (including the launcher).

-

PR: https://git.openjdk.java.net/jdk/pull/5004

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

[Andy Herrick]

On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick  wrote:

> 8271868: Warn user when using mac-sign option with unsigned app-image.

The purpose of this change is to catch the case (and emit a warning) when user 
creates an app-image w/o using --mac-sign, and then uses that app image to 
build a pkg or dmg bundle using --mac-sign.  For this purpose, checking if the 
main launcher is signed is sufficient.  There is no reason to check all the 
executables, libraries, and/or Frameworks in the app image., and there is no 
such thing as signing the app-image itself, also using --deep arg to codesigner 
is specifically recommended against in all codesigner documentation I have read.
The user can modify the app-image in any way he chooses, possibly invalidating 
the signing, before using it to create dmg or pkg (or he may create the 
app-image unsigned, and manually sign all or any part of it.  This really has 
nothing to do with this change.  The app-image can still be used to create a 
dmg or pkg using --mac-sign or not.

The alternative of recording if the app-image was created with --app-sign in 
the AppImageFile is a reasonable alternative to verifying the signing of the 
main launchers

-

PR: https://git.openjdk.java.net/jdk/pull/5004

RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

[Andy Herrick]

8271868: Warn user when using mac-sign option with unsigned app-image.

-

Commit messages:
 - JDK-8271868: Warn user when using mac-sign option with unsigned app-image.
 - JDK-8271868: Warn user when using mac-sign option with unsigned app-image.
 - JDK-8271868: Warn user when using mac-sign option with unsigned app-image.
 - JDK-8271868: Warn user when using mac-sign option with unsigned app-image.

Changes: https://git.openjdk.java.net/jdk/pull/5004/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5004=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271868
  Stats: 34 lines in 5 files changed: 32 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5004/head:pull/5004

PR: https://git.openjdk.java.net/jdk/pull/5004

Integrated: JDK-8271344: Windows product version issue

[Andy Herrick]

On Mon, 2 Aug 2021 13:45:17 GMT, Andy Herrick  wrote:

> JDK-8271344: Windows product version issue

This pull request has now been integrated.

Changeset: 0199b03e
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/0199b03eb3bd9ffe79b5193ff1792144b5c488f1
Stats: 21 lines in 5 files changed: 5 ins; 2 del; 14 mod

8271344: Windows product version issue

Reviewed-by: asemenyuk, almatvee

-

PR: https://git.openjdk.java.net/jdk/pull/4958

Re: [External] : Re: jpackage MacOS Notarization

[Andy Herrick]

OK - took me a while to see what you are doing.

The problem is you are signing the pkg but building it from an unsigned 
app-image.


If you are building in two phases (app-image, then installer package) 
you need the --mac-sign option on both phases.


/Andy

On 8/3/2021 10:37 AM, Andy Herrick wrote:


I was having problems notarizing anything yesterday, but fixed them today.

I can notarize my own test - but get failure when trying to notarize 
your app as built from non-modular branch of 
https://github.com/danielpeintner/Java11Test/


am looking into it ...

/Andy


On 8/2/2021 9:57 AM, Daniel Peintner wrote:

Hi Andy,

sorry - code looks for certificate key starting with: "Developer
ID Application: " +  in order
to not have to put full user name in.  I missed that that with
null user name that causes it to look for anything starting with
"Developer ID Application: " (same thing with "Developer ID
Installer: " for .pkg signing).  And macos  looks at the
non-default keychains as well as the default ones when no
keychain is specified.

Thanks for your feedback and yes in the simple case (with one 
certificate installed) it works without any further information.


May I ask you whether you were able to reproduce the issue?

Is there anything I can do to help?

Thanks,

-- Daniel

/Andy

On 7/29/2021 10:00 AM, Daniel Peintner wrote:

Hi Andy,

Since I don't know your setup I did not put anything there.

'--mac-sign' is enough to use the defaults in my setup.

It looks for the signing keys installed on my machine that start
with "Developer ID Application " similar to
'--mac-signing-key-user-name', 'Developer ID Application: '
etc.

If you want to test it you need to add your credentials which I
do not know.

Hope this clarifies things,

-- Daniel



    On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick
mailto:andy.herr...@oracle.com>> wrote:

The 'build.gradle' in this branch has
--mac-signing-key-user-name commented out.


installerOptions += [
    '--mac-sign',
    //
'--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name',
System.getenv('SIGNING_KEY_USER_NAME'),
    // '--mac-signing-keychain',
System.getenv('SIGNING_KEYCHAIN_PATH')
    ]


clearly this cannot work, I assume you were just trying
things ...

What is the full name of the certificate you intended to
use, what keychain is it shown in "Keychain Access", and
what are you normal values for your environment variables:
'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ?

/Andy

On 7/29/2021 4:36 AM, Daniel Peintner wrote:

Kevin, Andy,

Thanks for your quick response.

Full support for notarization in jpackage was added in
JDK 17. Can you
try an early access build of JDK 17 [1] and see if that
works for you?


I did try JDK17-ea-32 also with the same result.

Since I do understand it is difficult reproduce the problem
I put together a *very* simple test application which you
can find in the "non-modular" branch here:
https://github.com/danielpeintner/Java11Test/tree/non-modular

<https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>

It is a gradle project. It uses Java 11 to run but in
build.gradle on line#83[1] one can set the
jpackage location (JDK17-ea-32 in this case).

The process is as follows
* ./gradlew build
* ./gradlew jpackage    // creates the dmg/pkg in folder
build/jpackage
* afterwards Apple notarization process can be started

Note: notarization of dmg or pkg lead to the same failure.
See [2] for the full log w.r.t. pkg.

I hope this helps you to be able to reproduce the issue.

Thanks for your investigations!

-- Daniel

[1]

https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83

<https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$>
[2]

https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D
   

Re: [External] : Re: jpackage MacOS Notarization

[Andy Herrick]

I was having problems notarizing anything yesterday, but fixed them today.

I can notarize my own test - but get failure when trying to notarize 
your app as built from non-modular branch of 
https://github.com/danielpeintner/Java11Test/


am looking into it ...

/Andy


On 8/2/2021 9:57 AM, Daniel Peintner wrote:

Hi Andy,

sorry - code looks for certificate key starting with: "Developer
ID Application: " +  in order
to not have to put full user name in.  I missed that that with
null user name that causes it to look for anything starting with
"Developer ID Application: " (same thing with "Developer ID
Installer: " for .pkg signing).  And macos  looks at the
non-default keychains as well as the default ones when no keychain
is specified.

Thanks for your feedback and yes in the simple case (with one 
certificate installed) it works without any further information.


May I ask you whether you were able to reproduce the issue?

Is there anything I can do to help?

Thanks,

-- Daniel

/Andy

On 7/29/2021 10:00 AM, Daniel Peintner wrote:

Hi Andy,

Since I don't know your setup I did not put anything there.

'--mac-sign' is enough to use the defaults in my setup.

It looks for the signing keys installed on my machine that start
with "Developer ID Application " similar to
'--mac-signing-key-user-name', 'Developer ID Application: '
etc.

If you want to test it you need to add your credentials which I
do not know.

Hope this clarifies things,

-- Daniel



    On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick
mailto:andy.herr...@oracle.com>> wrote:

The 'build.gradle' in this branch has
--mac-signing-key-user-name commented out.


installerOptions += [
    '--mac-sign',
    //
'--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name',
System.getenv('SIGNING_KEY_USER_NAME'),
    // '--mac-signing-keychain',
System.getenv('SIGNING_KEYCHAIN_PATH')
    ]


clearly this cannot work, I assume you were just trying
things ...

What is the full name of the certificate you intended to use,
what keychain is it shown in "Keychain Access", and what are
you normal values for your environment variables:
'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ?

/Andy

On 7/29/2021 4:36 AM, Daniel Peintner wrote:

Kevin, Andy,

Thanks for your quick response.

Full support for notarization in jpackage was added in
JDK 17. Can you
try an early access build of JDK 17 [1] and see if that
works for you?


I did try JDK17-ea-32 also with the same result.

Since I do understand it is difficult reproduce the problem
I put together a *very* simple test application which you
can find in the "non-modular" branch here:
https://github.com/danielpeintner/Java11Test/tree/non-modular

<https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>

It is a gradle project. It uses Java 11 to run but in
build.gradle on line#83[1] one can set the jpackage location
(JDK17-ea-32 in this case).

The process is as follows
* ./gradlew build
* ./gradlew jpackage    // creates the dmg/pkg in folder
build/jpackage
* afterwards Apple notarization process can be started

Note: notarization of dmg or pkg lead to the same failure.
See [2] for the full log w.r.t. pkg.

I hope this helps you to be able to reproduce the issue.

Thanks for your investigations!

-- Daniel

[1]

https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83

<https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$>
[2]

https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D

<https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZ

RFR: JDK-8271344: Windows product version issue

[Andy Herrick]

JDK-8271344: Windows product version issue

-

Commit messages:
 - JDK-8271344: Windows product version issue

Changes: https://git.openjdk.java.net/jdk/pull/4958/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4958=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271344
  Stats: 21 lines in 5 files changed: 5 ins; 2 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4958/head:pull/4958

PR: https://git.openjdk.java.net/jdk/pull/4958

Re: [External] : Re: jpackage MacOS Notarization

[Andy Herrick]

sorry - code looks for certificate key starting with: "Developer ID 
Application: " +  in order to not 
have to put full user name in.  I missed that that with null user name 
that causes it to look for anything starting with "Developer ID 
Application: " (same thing with "Developer ID Installer: " for .pkg 
signing).  And macos  looks at the non-default keychains as well as the 
default ones when no keychain is specified.


/Andy

On 7/29/2021 10:00 AM, Daniel Peintner wrote:

Hi Andy,

Since I don't know your setup I did not put anything there.

'--mac-sign' is enough to use the defaults in my setup.

It looks for the signing keys installed on my machine that start with 
"Developer ID Application " similar to

'--mac-signing-key-user-name', 'Developer ID Application: '
etc.

If you want to test it you need to add your credentials which I do not 
know.


Hope this clarifies things,

-- Daniel



On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <mailto:andy.herr...@oracle.com>> wrote:


The 'build.gradle' in this branch has --mac-signing-key-user-name
commented out.


    installerOptions += [
    '--mac-sign',
    //
'--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name',
System.getenv('SIGNING_KEY_USER_NAME'),
    // '--mac-signing-keychain',
System.getenv('SIGNING_KEYCHAIN_PATH')
    ]


clearly this cannot work, I assume you were just trying things ...

What is the full name of the certificate you intended to use, what
keychain is it shown in "Keychain Access", and what are you normal
values for your environment variables: 'SIGNING_KEY_USER_NAME' and
'SIGNING_KEYCHAIN_PATH' ?

/Andy

On 7/29/2021 4:36 AM, Daniel Peintner wrote:

Kevin, Andy,

Thanks for your quick response.

Full support for notarization in jpackage was added in JDK
17. Can you
try an early access build of JDK 17 [1] and see if that works
for you?


I did try JDK17-ea-32 also with the same result.

Since I do understand it is difficult reproduce the problem I put
together a *very* simple test application which you can find in
the "non-modular" branch here:
https://github.com/danielpeintner/Java11Test/tree/non-modular

<https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>

It is a gradle project. It uses Java 11 to run but in
build.gradle on line#83[1] one can set the jpackage location
(JDK17-ea-32 in this case).

The process is as follows
* ./gradlew build
* ./gradlew jpackage    // creates the dmg/pkg in folder
build/jpackage
* afterwards Apple notarization process can be started

Note: notarization of dmg or pkg lead to the same failure.
See [2] for the full log w.r.t. pkg.

I hope this helps you to be able to reproduce the issue.

Thanks for your investigations!

-- Daniel

[1]

https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83

<https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$>
[2]

https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D

<https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>


-- Kevin

[1] https://jdk.java.net/17

<https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>

On 7/28/2021 8:27 AM, Daniel Peintner wrote:
> All,
>
> I am trying to notarize an app (built with jpackage) for MacOS.
>
> jpackage at first *seems* to properly sign all resources
with the available
> --mac-sign options et cetera.
>
> Having said that, there are still remaining issues
> 1. The app cann

Re: [External] : Re: jpackage MacOS Notarization

[Andy Herrick]

The 'build.gradle' in this branch has --mac-signing-key-user-name 
commented out.



    installerOptions += [
    '--mac-sign',
    // 
'--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', 
System.getenv('SIGNING_KEY_USER_NAME'),
    // '--mac-signing-keychain', 
System.getenv('SIGNING_KEYCHAIN_PATH')

    ]


clearly this cannot work, I assume you were just trying things ...

What is the full name of the certificate you intended to use, what 
keychain is it shown in "Keychain Access", and what are you normal 
values for your environment variables: 'SIGNING_KEY_USER_NAME' and 
'SIGNING_KEYCHAIN_PATH' ?


/Andy

On 7/29/2021 4:36 AM, Daniel Peintner wrote:

Kevin, Andy,

Thanks for your quick response.

Full support for notarization in jpackage was added in JDK 17. Can
you
try an early access build of JDK 17 [1] and see if that works for you?


I did try JDK17-ea-32 also with the same result.

Since I do understand it is difficult reproduce the problem I put 
together a *very* simple test application which you can find in the 
"non-modular" branch here:
https://github.com/danielpeintner/Java11Test/tree/non-modular 



It is a gradle project. It uses Java 11 to run but in build.gradle on 
line#83[1] one can set the jpackage location (JDK17-ea-32 in this case).


The process is as follows
* ./gradlew build
* ./gradlew jpackage    // creates the dmg/pkg in folder build/jpackage
* afterwards Apple notarization process can be started

Note: notarization of dmg or pkg lead to the same failure.
See [2] for the full log w.r.t. pkg.

I hope this helps you to be able to reproduce the issue.

Thanks for your investigations!

-- Daniel

[1] 
https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83 

[2] 
https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D 




-- Kevin

[1] https://jdk.java.net/17



On 7/28/2021 8:27 AM, Daniel Peintner wrote:
> All,
>
> I am trying to notarize an app (built with jpackage) for MacOS.
>
> jpackage at first *seems* to properly sign all resources with
the available
> --mac-sign options et cetera.
>
> Having said that, there are still remaining issues
> 1. The app cannot be properly installed
>     (without hacks like xattr -d com.apple.quarantine
/Applications/myAPP.app
> ).
> 2. I am also not able to properly notarize the app.
>
> According to online resources there seem to exist issues in
*past* about
> notarization but according to [1, 2] the issues are fixed.
>
> As mentioned, I still have issues :-(
> Am I really the only one still having problems?
>
> Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also
without success)
>
> The issue seems to boil down to 2 errors (attached the error log
from Apple
> notarization process).
> * app Folder
> * libjli.dylib
>
> I thought I better ask first on the mailing list before creating
an actual
> bug report.
>
> Note1: I used to use the *old* javapackager that worked with the
same
> signature/credentials.
> Note2: running jpackage without --mac-sign options causes many
more errors
> in notarization (Hence, jpackage signs most resources but fails
with some)
>
> Any help / hint appreciated.
>
> Thanks,
>
> -- Daniel
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8257488

> [2] https://bugs.openjdk.java.net/browse/JDK-8251892

Re: jpackage MacOS Notarization

[Andy Herrick]

Not really enough info given here to act on.  Exactly what java 
version/build are you using?   As Kevin suggested it best to try JDK17 
EA first, but I can notarize simple test app with JDK16 , staple the 
notarization, and then download it and run it on other machines without 
the quarantine hacks.


While implementing support for the Mac App Store in JDK17, we had to 
change the way signing works (we now unsign the java runtime and then 
re-sign it's components together with the app's components, where we 
previously used the signing already present in the released jdk.)  For 
this reason I think  it is better to look only at problem that persist 
in JDK17 at this time.


/Andy

On 7/28/2021 11:27 AM, Daniel Peintner wrote:

All,

I am trying to notarize an app (built with jpackage) for MacOS.

jpackage at first *seems* to properly sign all resources with the available
--mac-sign options et cetera.

Having said that, there are still remaining issues
1. The app cannot be properly installed
(without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app
).
This indicates the app is not notarized or the notarization is not 
properly stapled.

2. I am also not able to properly notarize the app.

According to online resources there seem to exist issues in *past* about
notarization but according to [1, 2] the issues are fixed.

As mentioned, I still have issues :-(
Am I really the only one still having problems?

Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)

The issue seems to boil down to 2 errors (attached the error log from Apple
notarization process).
* app Folder
* libjli.dylib


From below it looks like you are trying to sign a dmg.

Notarization or a jpackage artifact requires either a signed pkg or a 
zipped signed app image.


It looks like notarizing a signed dmg is now supported by Apple, but 
this is not something that was available when we initially implemented 
this in jpackage.


Can you try the same thing with a "pkg" instead of a "dmg".

We will have to look into what is needed to sign "dmg" artifacts now.

/Andy

Re: [jdk17] RFR: 8271155: Wrong path separator in env variable

[Andy Herrick]

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk  wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' 
> dir to env variable in jpackage app launcher.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/271

Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found

[Andy Herrick]

Looks like an instance of: JDK-8260335 
 : [macos] Running app 
using relative path causes problems (fixed in jdk17 build b09)


you can try builds from https://jdk.java.net/17/ to confirm fix.

/Andy

On 7/21/2021 4:46 PM, Bruno Borges wrote:

Hi all,

Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and 
the generated app-image comes with a binary launcher that tries to load the 
.cfg file from the wrong directory.

Anyone seen this problem?

fx2048.app/Contents/MacOS  master -> origin/master ✔
   
   1h59m  java:16.0.1
$ tree ../../../ -L 4
../../../
└── fx2048.app
 └── Contents
 ├── Info.plist
 ├── MacOS
 │   └── fx2048
 ├── PkgInfo
 ├── Resources
 │   └── fx2048.icns
 ├── app
 │   └── fx2048.cfg
 └── runtime
 └── Contents

7 directories, 5 files

$ ./fx2048
Error opening 
"/Users/bruno/myprojects/fx2048/build/installers/fx2048.app/Contents/Contents/app/fx2048.cfg"
 file: No such file or directory

[1] http://github.com/brunoborges/fx2048

Integrated: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

[Andy Herrick]

On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick  wrote:

> JDK-8269387: jpackage --add-launcher should have option to not create 
> shortcuts for additional launchers

This pull request has now been integrated.

Changeset: 057992f2
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/057992f206d48d0f6152f6fdece229e2ff56e375
Stats: 341 lines in 11 files changed: 258 ins; 13 del; 70 mod

8269387: jpackage --add-launcher should have option to not create shortcuts for 
additional launchers

Reviewed-by: asemenyuk, almatvee

-

PR: https://git.openjdk.java.net/jdk/pull/4730

Re: RFR: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers [v4]

[Andy Herrick]

> JDK-8269387: jpackage --add-launcher should have option to not create 
> shortcuts for additional launchers

Andy Herrick has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8269387: jpackage --add-launcher should have option to not create 
shortcuts for additional launchers

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4730/files
  - new: https://git.openjdk.java.net/jdk/pull/4730/files/d88b1dc7..96758fe8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4730=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4730=02-03

  Stats: 18 lines in 1 file changed: 12 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4730.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4730/head:pull/4730

PR: https://git.openjdk.java.net/jdk/pull/4730

Re: RFR: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers [v3]

[Andy Herrick]

> JDK-8269387: jpackage --add-launcher should have option to not create 
> shortcuts for additional launchers

Andy Herrick has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8269387: jpackage --add-launcher should have option to not create 
shortcuts for additional launchers

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4730/files
  - new: https://git.openjdk.java.net/jdk/pull/4730/files/3fe30059..d88b1dc7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4730=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4730=01-02

  Stats: 45 lines in 2 files changed: 22 ins; 0 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4730.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4730/head:pull/4730

PR: https://git.openjdk.java.net/jdk/pull/4730

Re: RFR: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers [v2]

[Andy Herrick]

> JDK-8269387: jpackage --add-launcher should have option to not create 
> shortcuts for additional launchers

Andy Herrick has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8269387: jpackage --add-launcher should have option to not create 
shortcuts for additional launchers

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4730/files
  - new: https://git.openjdk.java.net/jdk/pull/4730/files/8b6402c6..3fe30059

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4730=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4730=00-01

  Stats: 62 lines in 7 files changed: 12 ins; 30 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4730.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4730/head:pull/4730

PR: https://git.openjdk.java.net/jdk/pull/4730

RFR: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

[Andy Herrick]

JDK-8269387: jpackage --add-launcher should have option to not create shortcuts 
for additional launchers

-

Commit messages:
 - JDK-8269387: jpackage --add-launcher should have option to not create 
shortcuts for additional launchers
 - JDK-8269387: jpackage --add-launcher should have option to not create 
shortcuts for additional launchers
 - JDK-8269387: jpackage --add-launcher should have option to not create 
shortcuts for additional launchers
 - JDK-8269387: jpackage --add-launcher should have option to not create 
shortcuts for additional launchers

Changes: https://git.openjdk.java.net/jdk/pull/4730/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4730=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269387
  Stats: 298 lines in 11 files changed: 240 ins; 5 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4730.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4730/head:pull/4730

PR: https://git.openjdk.java.net/jdk/pull/4730

Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used [v3]

[Andy Herrick]

On Wed, 7 Jul 2021 18:54:23 GMT, Alexey Semenyuk  wrote:

>> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" 
>> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() 
>> looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" 
>> string and then it looks for "/lib/". But this is wrong order as it should 
>> look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then 
>> for "/lib/" if called from GetApplicationHome() and for "/lib/" first and 
>> then for "/bin/" if called from GetApplicationHomeFromDll().
>
> Alexey Semenyuk has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Test added

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4534

Re: [jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different

[Andy Herrick]

On Fri, 2 Jul 2021 22:17:09 GMT, Alexey Semenyuk  wrote:

> Disable stripping to prevent rpmbuild from modifying executables

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/207

Re: [jdk17] RFR: 8269403: Fix jpackage tests to gracefully handle jpackage app launcher crashes

[Andy Herrick]

On Fri, 25 Jun 2021 22:41:10 GMT, Alexey Semenyuk  wrote:

> jpackage app launcher randomly crashes JVM at termination in EMS enabled JDK 
> builds.
> Until the root cause of the issue is understood and fixed let's add a 
> workaround to jpackage tests to run test app few more times if the first 
> attempt resulted in app crash.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/153

Re: [jdk17] RFR: 8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"

[Andy Herrick]

On Tue, 22 Jun 2021 21:59:43 GMT, Alexander Matveev  
wrote:

> Looks like another "Resource busy" issue similar to recent fixes for "hdiutil 
> convert" and "hdiutil detach". Workaround in same way by repeating "create" 
> command. Modified RetryExecutor to pass write to file flag, otherwise 
> "hdiutil create" might deadlock.
> Also, repeat is done only for creating DMG using size instead of creating 
> from app image. In some cases create DMG from app image might run for very 
> long time and eventually fail, this is why fallback to create DMG from size 
> was added.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/122

[jdk17] Integrated: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

[Andy Herrick]

On Mon, 21 Jun 2021 20:21:58 GMT, Andy Herrick  wrote:

> …t.java failed "AssertionError: Failed: Check icon"

This pull request has now been integrated.

Changeset: 35e4c272
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk17/commit/35e4c2720df64ea6cb68ba8fb62aeeb0562c2907
Stats: 79 lines in 2 files changed: 0 ins; 59 del; 20 mod

8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed 
"AssertionError: Failed: Check icon"

Reviewed-by: asemenyuk

-

PR: https://git.openjdk.java.net/jdk17/pull/111

Re: [jdk17] RFR: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon" [v2]

[Andy Herrick]

On Mon, 21 Jun 2021 22:56:32 GMT, Andy Herrick  wrote:

>> test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 75:
>> 
>>> 73: 
>>> 74: // Create another installer with custom icon.
>>> 75: long size3 = createInstaller(customIcon, "WithCustom3Icon");
>> 
>> The test should produce WinInstallerIconTest-1.0.exe artifact referenced in 
>> SQE test spec. But this patch will not produce it. It will produce 
>> WinInstallerIconTestWithDefaultIcon-1.0.exe, 
>> WinInstallerIconTestWithCustom2Icon-1.0.exe and 
>> WinInstallerIconTestWithCustom3Icon-1.0.exe artifacts and all of them will 
>> be deleted.
>
> yes - I was changing the names to be the same length in attempt to create 
> repeatable exe size - but that doesn't matter, so will restore the suffix's 
> to what they were so WinInstallerIconTest-1.0.exe  will be left for 
> JPKG001-024 in Test Spec.

done - name change and test reverted so remaining artifact is 
WinInstallerIconTest-1.0.exe (and it contains the custom icon)

-

PR: https://git.openjdk.java.net/jdk17/pull/111

Re: [jdk17] RFR: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon" [v2]

[Andy Herrick]

> …t.java failed "AssertionError: Failed: Check icon"

Andy Herrick has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java 
failed "AssertionError: Failed: Check icon"

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/111/files
  - new: https://git.openjdk.java.net/jdk17/pull/111/files/cf5b0242..f8714c8a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17=111=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=111=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/111.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/111/head:pull/111

PR: https://git.openjdk.java.net/jdk17/pull/111

Re: [jdk17] RFR: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

[Andy Herrick]

On Mon, 21 Jun 2021 20:42:54 GMT, Alexey Semenyuk  wrote:

>> …t.java failed "AssertionError: Failed: Check icon"
>
> test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 75:
> 
>> 73: 
>> 74: // Create another installer with custom icon.
>> 75: long size3 = createInstaller(customIcon, "WithCustom3Icon");
> 
> The test should produce WinInstallerIconTest-1.0.exe artifact referenced in 
> SQE test spec. But this patch will not produce it. It will produce 
> WinInstallerIconTestWithDefaultIcon-1.0.exe, 
> WinInstallerIconTestWithCustom2Icon-1.0.exe and 
> WinInstallerIconTestWithCustom3Icon-1.0.exe artifacts and all of them will be 
> deleted.

yes - I was changing the names to be the same length in attempt to create 
repeatable exe size - but that doesn't matter, so will restore the suffix's to 
what they were so WinInstallerIconTest-1.0.exe  will be left for JPKG001-024 in 
Test Spec.

-

PR: https://git.openjdk.java.net/jdk17/pull/111

[jdk17] RFR: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

[Andy Herrick]

…t.java failed "AssertionError: Failed: Check icon"

-

Commit messages:
 - JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java 
failed "AssertionError: Failed: Check icon"

Changes: https://git.openjdk.java.net/jdk17/pull/111/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=111=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268404
  Stats: 79 lines in 2 files changed: 0 ins; 59 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/111.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/111/head:pull/111

PR: https://git.openjdk.java.net/jdk17/pull/111

Re: RFR: 8268974: jpackage fails to handle --dest option containing "bin" folder

[Andy Herrick]

On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk  wrote:

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" 
> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() 
> looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" 
> string and then it looks for "/lib/". But this is wrong order as it should 
> look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then 
> for "/lib/" if called from GetApplicationHome() and for "/lib/" first and 
> then for "/bin/" if called from GetApplicationHomeFromDll().

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4534

Re: [jdk17] RFR: 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64

[Andy Herrick]

On Thu, 17 Jun 2021 16:32:52 GMT, Daniel D. Daugherty  
wrote:

> A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java 
> on win-x64.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/90

Integrated: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR

[Andy Herrick]

On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick  wrote:

> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed 
> as SCR

This pull request has now been integrated.

Changeset: 51e8201e
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/51e8201eb5a66a8fbbff21194fd35389343baee1
Stats: 69 lines in 2 files changed: 67 ins; 0 del; 2 mod

8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR

Reviewed-by: asemenyuk, almatvee

-

PR: https://git.openjdk.java.net/jdk/pull/4306

Re: RFR: 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages [v2]

[Andy Herrick]

On Tue, 8 Jun 2021 17:25:46 GMT, Alexey Semenyuk  wrote:

>> …ages
>
> Alexey Semenyuk has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains two additional 
> commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8264144
>  - 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4415

Re: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR [v2]

[Andy Herrick]

> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed 
> as SCR

Andy Herrick has updated the pull request with a new target base due to a merge 
or a rebase. The incremental webrev excludes the unrelated changes brought in 
by the merge/rebase. The pull request contains 122 additional commits since the 
last revision:

 - JDK-8267764: jpackage cannot handle window screensaver files when EXE 
renamed as SCR
 - Merge branch 'master' into JDK-8267764
 - Merge branch 'master' into JDK-8267764
 - 8191441: (Process) add Readers and Writer access to java.lang.Process streams
   
   Reviewed-by: naoto, alanb
 - 8261549: Adjust memory size in MTLTexurePool.m
   
   Reviewed-by: prr
 - 8268299: jvms tag produces incorrect URL
   
   Reviewed-by: iris, erikj, jjg
 - 8254129: IR Test Framework to support regex-based matching on the IR in 
JTreg compiler tests
   
   Co-authored-by: Christian Hagedorn 
   Co-authored-by: Tobias Hartmann 
   Reviewed-by: iignatyev
 - 8268331: Fix crash in humongous object eager reclaim logging
   
   Reviewed-by: sjohanss
 - 8267875: Shenandoah: Duplicated code in ShenandoahBarrierSetC2::ideal_node()
   
   Reviewed-by: rkennke, roland
 - 8268267: Remove -Djavatest.security.noSecurityManager=true from jtreg runs
   
   Reviewed-by: lancea, jjg, erikj
 - ... and 112 more: 
https://git.openjdk.java.net/jdk/compare/583e2df7...7ad71791

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4306/files
  - new: https://git.openjdk.java.net/jdk/pull/4306/files/cfd8ce4d..7ad71791

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4306=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4306=00-01

  Stats: 484800 lines in 1905 files changed: 468469 ins; 10878 del; 5453 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4306/head:pull/4306

PR: https://git.openjdk.java.net/jdk/pull/4306

Re: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR

[Andy Herrick]

On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick  wrote:

> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed 
> as SCR

as suggested added a simple test to verify an app on windows can continue to 
run after ".exe" is renamed to any other extension

-

PR: https://git.openjdk.java.net/jdk/pull/4306

Integrated: JDK-8267598: jpackage removes system libraries from java.library.path

[Andy Herrick]

On Wed, 26 May 2021 11:26:24 GMT, Andy Herrick  wrote:

> JDK-8267598: jpackage removes system libraries from java.library.path

This pull request has now been integrated.

Changeset: af3df630
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/af3df6300efddc8ba12f095b87205cc2fea1f1e8
Stats: 38 lines in 9 files changed: 26 ins; 5 del; 7 mod

8267598: jpackage removes system libraries from java.library.path

Reviewed-by: almatvee, asemenyuk

-

PR: https://git.openjdk.java.net/jdk/pull/4203

Re: RFR: JDK-8267598: jpackage removes system libraries from java.library.path [v2]

[Andy Herrick]

> JDK-8267598: jpackage removes system libraries from java.library.path

Andy Herrick has updated the pull request with a new target base due to a merge 
or a rebase. The incremental webrev excludes the unrelated changes brought in 
by the merge/rebase. The pull request contains eight additional commits since 
the last revision:

 - JDK-8267598: jpackage removes system libraries from java.library.path
 - Merge branch 'master' into JDK-8267598
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4203/files
  - new: https://git.openjdk.java.net/jdk/pull/4203/files/a0b5c0e8..3639dde4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4203=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4203=00-01

  Stats: 60464 lines in 2313 files changed: 10695 ins; 45162 del; 4607 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4203.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4203/head:pull/4203

PR: https://git.openjdk.java.net/jdk/pull/4203

Re: RFR: JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6

[Andy Herrick]

On Thu, 3 Jun 2021 00:47:45 GMT, Jonathan Gibbons  wrote:

> Please review a small test fix, to include hamcrest.jar, as required by the 
> latest version of JUnit  in jtreg 6.

looks fine

-

PR: https://git.openjdk.java.net/jdk/pull/4328

RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR

[Andy Herrick]

JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed 
as SCR

-

Commit messages:
 - JDK-8267764: jpackage cannot handle window screensaver files when EXE 
renamed as SCR

Changes: https://git.openjdk.java.net/jdk/pull/4306/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4306=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267764
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4306/head:pull/4306

PR: https://git.openjdk.java.net/jdk/pull/4306

RFR: JDK-8267598: jpackage removes system libraries from java.library.path

[Andy Herrick]

JDK-8267598: jpackage removes system libraries from java.library.path

-

Commit messages:
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path
 - JDK-8267598: jpackage removes system libraries from java.library.path

Changes: https://git.openjdk.java.net/jdk/pull/4203/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4203=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267598
  Stats: 49 lines in 5 files changed: 45 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4203.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4203/head:pull/4203

PR: https://git.openjdk.java.net/jdk/pull/4203

Re: RFR: 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package"

[Andy Herrick]

On Fri, 21 May 2021 04:34:22 GMT, Alexander Matveev  
wrote:

> Looks like another issue similar to hdiutil (JDK-8249395) when process is 
> gone, but we still waiting for it. I was not able to reproduce this issue by 
> running test or pkgbuild separately and conclusion was made based on logs. 
> Fixed in same way as hdiutil issue. Also, I added logging PID for external 
> commands to simplify log analysis. Log will have multiple hdiutil and/or 
> pkgbuild processes, since we running multiple tests in parallel and matching 
> external process to test failure requires looking at command line for 
> particular process, so PID should simplify this.

Please update the bug report to contain the evaluation you have here in the PR

-

Marked as reviewed by herrick (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4139

Integrated: JDK-8267423: Fix copyrights in jpackage tests

[Andy Herrick]

On Fri, 21 May 2021 12:22:16 GMT, Andy Herrick  wrote:

> JDK-8267423: Fix copyrights in jpackage tests

This pull request has now been integrated.

Changeset: a5467ae7
Author:    Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/a5467ae7bb5780f34728ad073c5c4158894c7c4b
Stats: 96 lines in 10 files changed: 69 ins; 14 del; 13 mod

8267423: Fix copyrights in jpackage tests

Reviewed-by: kcr, asemenyuk

-

PR: https://git.openjdk.java.net/jdk/pull/4144

RFR: JDK-8267423: Fix copyrights in jpackage tests

[Andy Herrick]

JDK-8267423: Fix copyrights in jpackage tests

-

Commit messages:
 - JDK-8267423: Fix copyrights in jpackage tests
 - JDK-8267423: Fix copyrights in jpackage tests
 - JDK-8267423: Fix copyrights in jpackage tests
 - JDK-8267423: Fix copyrights in jpackage tests

Changes: https://git.openjdk.java.net/jdk/pull/4144/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4144=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267423
  Stats: 96 lines in 10 files changed: 69 ins; 14 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4144.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4144/head:pull/4144

PR: https://git.openjdk.java.net/jdk/pull/4144

Re: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

[Andy Herrick]

On Thu, 20 May 2021 22:25:10 GMT, Alexander Matveev  
wrote:

>> For debug build on macOS, runtime which used for test fill be located in 
>> /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files 
>> except fastdebug and in this case our check to decide if we need to copy app 
>> or runtime will return /path/jdk-17 which is not correct. Fixed by skipping 
>> this check for runtime and only using it for app. Also, added ignoring 
>> .DS_Store to test which is needed if user used Finder to look inside runtime 
>> folder which will cause .DS_Store to be created and will cause test to fail, 
>> since this file is not being packaged.
>
> Alexander Matveev has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8267056: tools/jpackage/share/RuntimePackageTest.java fails with 
> NoSuchFileException [v2]

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4120