Re: jpackage signing fails with Mac jdk-14.0.1+7

Redirecting to core-libs-dev (with a Bcc to code-tools-dev) Code signing for macOS, along with the addition of notarization, has been improved for JDK 15. You might want to try the EA builds of JDK 15, which are available here: https://jdk.java.net/15/ -- Kevin On 5/1/2020 8:13 AM, Adam Ca

Re: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

Is there a way you can link the launcher (e.g., something similar to RPATH on Unix systems) to look in the right place relative to the launcher? Otherwise, the solution with adding to the PATH seems OK to me. -- Kevin On 5/12/2020 5:22 AM, Andy Herrick wrote: Is the problem that by removing t

Re: RFR: 8225251: Minimise import statements in jpackage sources

That a reasonably common pattern in JUnit tests, but expanding them to individual static imports is, of course, fine as well. -- Kevin On 6/19/2020 9:08 AM, Alexey Semenyuk wrote: Alexander, There is still --- import static org.junit.Assert.*; --- in unit tests. Is this intended? - Alexey

Re: RFR: 8252999: replace all String.equals("") usages with String.isEmpty()

On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy wrote: >> @doom369 jcheck requires an associated issue > > @mrserb hello. Thanks for the review. Any further actions required from me? Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working wit

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 >> (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining >> usages make sense although I see that

Re: RFR: 8223187: Investigate setLocale() call in jpackage native launcher

On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev wrote: > setlocale() affects several C functions. We do not use most of these > functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing > it I retested jpackage by chan

Re: RFR: 8223187: Investigate setLocale() call in jpackage native launcher

On Sat, 12 Sep 2020 12:41:50 GMT, Kevin Rushforth wrote: >> setlocale() affects several C functions. We do not use most of these >> functions. We only using isspace() and toLower(). >> Based on how we use it I do not see any needs for setlocale(). After >> removing i

Re: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode

I see this in DecimalFormatSymbols: /**   * Override hashCode.   */ >>>    private volatile int hashCode; @Override public int hashCode() { Although, I'm not sure why the intervening private field would prevent javadoc from generating at least a method with an empty doc.

Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]

On Tue, 13 Oct 2020 21:30:05 GMT, Alexander Matveev wrote: >> Andy Herrick has updated the pull request incrementally with one additional >> commit since the last revision: >> >> JDK-8252870: Finalize (remove "incubator" from) jpackage >> - reverting two auto-generated files, and changin

Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]

On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage >

Re: RFR: JDK-8254843: Exception launching app on windows in some cases

On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick wrote: > JDK-8254843: Exception launching app on windows in some cases > loading splashscreen.dll in WinLaunchercpp would load java.dll from path > instead of runtime/bin causing jni launcher to > crash. instead we just use what used to be the fallb

Re: RFR: 8248122: java.base should not handle JavaFX application in a specific way

On Sat, 31 Oct 2020 15:25:13 GMT, Kartik Ohri wrote: > JavaFX is no longer a part of OpenJDK. It makes sense to not treat it > specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX > specific code. > > Further investigation reveals that some JavaFX specific code is also

Re: RFR: 8248122: java.base should not handle JavaFX application in a specific way

On Sat, 31 Oct 2020 16:09:18 GMT, Kevin Rushforth wrote: >> JavaFX is no longer a part of OpenJDK. It makes sense to not treat it >> specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX >> specific code. >> >> Further investigation rev

Re: 8248122: java.base should not handle JavaFX application in a specific way

As mentioned in the pull request, this cannot be done as proposed without causing a behavioral regression and breaking JavaFX applications. If done, it should be done carefully using a similar process to the deprecate-for-removal in one release (to give applications time to react and adapt) and

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs @andyherrick can you enter the `/csr needed` command? I would, but it needs to be done by either the author of the PR or a Reviewer. - PR: https://git.openjdk.java.net/jdk/pu

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]

On Fri, 13 Nov 2020 09:31:53 GMT, Alan Bateman wrote: >> 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 six additional >> commits

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3]

On Fri, 13 Nov 2020 15:05:15 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8189198: Add "forRemoval = true" to Applet APIs src/java.desk

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

On Tue, 17 Nov 2020 20:56:52 GMT, Jim Laskey wrote: > my local branch seems to have the right sources for doc Maybe, but your branch on GitHub does not. - PR: https://git.openjdk.java.net/jdk/pull/1273

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

On Tue, 17 Nov 2020 22:12:19 GMT, Jim Laskey wrote: >> @kevinrushforth What is the recommended approach to remove the doc >> edit/commit? > > javadoc can be found at > http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html Presuming your master branch

Re: JEP 343: Packaging Tool

Hi Mark, Thank you for your detailed review of jpackage. Given that RDP1 is only a week away, I agree that we don't have time to address your feedback. Either Andy or I will move it back to "Candidate" and then proceed as you recommend. -- Kevin On 6/5/2019 2:16 PM, mark.reinh...@oracle.co

Re: JEP 343: Packaging Tool

Andy is looking into a change which should satisfy the requirement to be able to produce an intermediate app-image (and later create a package from an app-image), while also getting rid of the two sub-commands, and making the building of the installer (package) the default. The idea would be t

Re: jpackage DMG creation trouble

This will likely change so that only a single package is created by jpackage. The current EA version creates all possible package types for a given platform by default, even when that doesn't make sense (as on a typical Linux machine which either has Debian or RPM tools, but typically not both)

Re: jpackage DMG creation trouble

Or if you only want the app in the dmg:     jpackage create-installer --installer-type dmg -- Kevin On 6/12/2019 6:02 AM, Kevin Rushforth wrote: This will likely change so that only a single package is created by jpackage. The current EA version creates all possible package types for a

Re: RFR: JDK-8225569: jpackage app-image layout

Looks good. Btw, there is a trailing whitespace you might want to fix (although that can be done later as a bulk update if you prefer). test/jdk/tools/jpackage/createappimage/JPackageCreateAppImageBase.java:50: Trailing whitespace -- Kevin On 6/14/2019 7:17 AM, Andy Herrick wrote: Please

Re: RFR: JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target

Looks good. I presume you will update the HelpResources.properties for other languages before you push? -- Kevin On 6/20/2019 9:54 AM, Andy Herrick wrote: On 6/19/2019 1:34 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch br

Re: RFR: JDK-8226532: cleanup is not called when jpackage command fails.

Looks good. -- Kevin On 6/21/2019 6:01 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). Trivial fix to clean up the temp directory created by jpackage. [1] https://bugs.open

Re: RFR: JDK-8226751: "Exception: ..." for missing file

The rest of the CommandLine class uses nio Paths/Files, so the following might be a better fit, and also checks whether the file can be read:     if (!Files.isReadable(Paths.of(name))) The rest looks fine. -- Kevin On 6/29/2019 6:27 AM, Andy Herrick wrote: Please review the jpackage fix for

Re: RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll

It looks fine. -- Kevin On 7/25/2019 6:20 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8227684 [2] http://cr.openjdk.java.

Re: RFR: JDK-8227312: Remove pkg bundle from DMG image.

Looks fine. -- Kevin On 7/25/2019 6:24 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8227312 [2] http://cr.openjdk.java.net/~

Re: RFR: JDK-8228744: file associations broken on linux.

Looks good. -- Kevin On 7/29/2019 12:19 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8228744 [2] http://cr.openjdk.java.net

Re: RFR: JDK-8227172: revert JDK-8225569 on windows

Looks good. -- Kevin On 8/10/2019 3:44 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This change will remove the "bin" directory on windows and revert to putting the exec

Re: RFR: JDK-8229795: Investigate registry key usage and need for --win-registry-name option.

The following will take the last in the list of extensions and use that: + entryName = ext.toUpperCase() + "File"; Also, did you mean to upper-case the extension? I note that "File" isn't upper-case, nor is the prefix when there isn't an extension. -- Kevin On 8/19/2019 12:33 PM, Andy Herr

Re: RFR: JDK-8229795: Investigate registry key usage and need for --win-registry-name option.

OK. Looks good. -- Kevin On 8/19/2019 2:09 PM, Andy Herrick wrote: On 8/19/19 4:53 PM, Kevin Rushforth wrote: The following will take the last in the list of extensions and use that: + entryName = ext.toUpperCase() + "File"; entryName is both set and used within the "

Re: RFR: JDK-8215381: Investigate if current implementation of --license-file is correct for Debian packages

Looks good. I do have one question. I see that you changed the resource name from "resource.deb-copyright" to "resource.copyright-file". Will this property be used for the RPM copyright / license file, too? If not, would it be better to keep "deb" in the name? -- Kevin On 8/19/2019 9:25 AM,

Re: RFR: JDK-8225447: Revise Debian packaging

Looks good. -- Kevin On 8/19/2019 9:56 AM, Alexey Semenyuk wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - fix all permission related issues reported by lintian - cleanup control files to

Re: jdk-14-jpackage+1-33 on jdk.java.net

We believe that we have addressed most of the issues, especially those affecting the generated Linux packages, both .deb and .rpm. There is one open issue around the naming of the Debian packages that we will address in the next EA release. See JDK-8228660 [1] for more information. We would lo

Re: RFR: JDK-8228660: .deb files generated by jpackage don't follow naming convention

Looks good to me, too. -- Kevin On 8/27/2019 1:29 PM, Andy Herrick wrote: looks good. /Andy On 8/27/2019 4:13 PM, Alexey Semenyuk wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - fix imp

Re: RFR: JDK-8229979: jpackage cleanup src files, help text, and javadoc

Looks good. -- Kevin On 8/28/2019 6:36 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] https://bugs.openjdk.java.net/browse/JDK-8229979 [2] http://cr.openjdk.java.net/~

Re: jdk-14-jpackage+1-33 on jdk.java.net

resolved. I reckon it will make it into the next build. /Sverre tor. 22. aug. 2019 kl. 02:03 skrev Kevin Rushforth mailto:kevin.rushfo...@oracle.com>>: We believe that we have addressed most of the issues, especially those affecting the generated Linux packages, both .d

Re: RFR: JDK-8230519: jpackage "--package-type" values and default

Looks good with one question: In Arguments.java: + if (bundler.isDefault()) { + return bundler; + } else { + savedBundler = bundler; + } When would there be a valid case where you loop th

Re: RFR: JDK-8230649: Make jpackage tool an experimental feature

In that case, it may be better to issue any warnings about it being experimental directly from jpackage instead of relying on the incubating modules. -- Kevin On 9/15/2019 1:05 PM, Andy Herrick wrote: yes - result of this change is as you suggest, everything shows this warning, so we will ne

Re: RFR: JDK-8230649: Make jpackage tool an experimental feature

On 9/16/2019 6:06 AM, Alan Bateman wrote: On 16/09/2019 13:56, Kevin Rushforth wrote: In that case, it may be better to issue any warnings about it being experimental directly from jpackage instead of relying on the incubating modules. Incubating modules are incubating non-final APIs so I

Re: Comments on jpackage (JEP 343)

Hi Phil, In the app-image case it always creates a new directory with the name of the application underneath the dest/output directory for holding all of the files. So you either have:    /appname.ext or    /appname/ So I think "." is a reasonable default if not specified. As to whether t

Re: Comments on jpackage (JEP 343)

As to why it has this Requires, perhaps I need to address it at the JavaFX mailinglist. Yes, that would be best, as this is no longer related to jpackage. -- Kevin On 9/19/2019 12:43 AM, Sverre Moe wrote: Yes it would seem so. I am still perplexed to why it has an RPM Requires libavcodec

Re: Comments on jpackage (JEP 343)

OK, that makes sense. Andy has already implemented this change (pushed it to the sandbox), so it will be in the next EA build. -- Kevin On 9/19/2019 10:25 AM, mark.reinh...@oracle.com wrote: jlink’s -o/--output option names exactly the thing being output, rather than a container for the thing

Re: RFR: JDK-8230649 : Make jpackage tool an experimental feature

On 9/25/2019 7:44 AM, Alan Bateman wrote: On 25/09/2019 15:33, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). These are the code changes to make jpackage an experimental feat

Re: RFR: JDK-8230649 : Make jpackage tool an experimental feature

detailed message in Help text we can either show the more detailed message in addition to the message shown in all cases, or specifically exclude the generic message in the Help case. /Andy On 9/25/19 11:18 AM, Kevin Rushforth wrote: On 9/25/2019 7:44 AM, Alan Bateman wrote: On 25/09/2019 15:33

Re: RFR: JDK-8230649 : Make jpackage tool an experimental feature

Looks good. -- Kevin On 9/26/2019 3:57 AM, Andy Herrick wrote: Revised [3] to remove the change to CreateJmods.gmk since it is not needed as the module will be resolved because it provides an implementation of ToolProvider. [3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/ /Andy

Re: RFR: JDK-8231912: Use https for URLs in help and error messages

Looks good. -- Kevin On 10/15/2019 9:12 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This change modifies an number of urls used, mostly just changing http to https.

Re: fx:deploy is not available in this JDK

> Error:Java FX Packager: fx:deploy task has failed. The 'fx:deploy' task was part of the ant plugin that was formerly distributed in ant-javafx.jar as part of javapackager. This ant plugin is not included in jpacakge, so you will need to find some other way to integrate jpacakge into IntelliJ

Re: RFR: JDK-8233265: jpackage --add-modules cannot find additional modules with non-modular app

Looks good. -- Kevin On 10/31/2019 2:02 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This is a fixes a regression from the fix to JDK-8231882

Re: RFR: JDK-8233592: change --package-type option name to --type and allow -t short form

+1 On 11/5/2019 9:47 PM, Alexey Semenyuk wrote: Looks good. - Alexey On 11/5/2019 3:39 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This changes the --package-type opti

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

Yes, this is a good change. +1 -- Kevin On 11/6/2019 2:02 AM, Philip Race wrote: I noticed this problem when creating various demo scenarios so +1 to the change, but +\  Pass on --bind-seervices option to jlink (which will link in \n\ typo here -phil On 11/5/19, 3:36 PM, Andy He

Re: RFR: JDK-823359: Reorder jpackage help text to focus on package

It seems fine, but it might be even better to have both the non-modular and modular application examples be for the default package case and have a single example of --app-image. Also, I presume `--package-type` will be replaced with `--type` (or `-t`) to match the change in command line option

Re: RFR: JDK-8233591: Reorder jpackage help text to focus on package

I disagree with a couple of these changes, but they can be fixed in a subsequent pass, since you've already pushed the changes. By convention, class names are camel case with leading upper-case letter, so ClassName expresses that better than className. Similarly, MyJar.jar seems better to me t

Re: RFR: JDK-8233591: Reorder jpackage help text to focus on package

ral about myJar.jar and MyJar.jar. - Alexey On 11/9/2019 12:37 AM, Kevin Rushforth wrote: I disagree with a couple of these changes, but they can be fixed in a subsequent pass, since you've already pushed the changes. By convention, class names are camel case with leading upper-case lette

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I took the "git diff" patch [5] that you uploaded yesterday, applied it, and verified that it is the same as what is in the JDK-8200758-branch branch of the sandbox. It builds and runs fine for me. I ran jcheck and it found the following three files with whitespace errors that will need to be

Re: RFR: JDK-8234402: revert change that stopped providing JPackageToolProvider

Good point. Looks good to me once this is fixed. -- Kevin On 11/19/2019 6:00 PM, Alexey Semenyuk wrote: Andy, I guess http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html can be reverted to its initial state now: -

Re: RFR: JDK-8234402: revert change that stopped providing JPackageToolProvider

Looks good. -- Kevin On 11/20/2019 6:36 AM, Andy Herrick wrote: webrev revised in place at [2]. /Andy On 11/19/2019 9:00 PM, Alexey Semenyuk wrote: Andy, I guess http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.htm

Re: jpackage ROOTDIR variable in a Windows bat file

$ROOTDIR is not a supported interface. You should use "$APPDIR" instead. Having said that, the real problem is likely your use of backslashes. I recommend using forward slashes and also enclosing it in single quotes, like this:     -Djava.security.policy='$APPDIR/all.policy' If you need to us

Re: jpackage ROOTDIR variable in a Windows bat file

I just tried this and it worked fine for me: jpackage --java-options '-Djava.security.policy=$APPDIR/all.policy' ... (note that there should not be an extra "/app" since $APPDIR points to the app directory). It generated this in the ApplicationName/app/ApplicationName.cfg file: [JavaOptions]

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch /Andy On 11/19/2019 3:13 PM, Kevin Rushforth wrote: I took the "git diff" patch [5] that you uploaded yesterday, applied it, and verified that it is the same as what is in the J

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Updated version (with the one change mentioned in reply to Phil) looks good. +1 -- Kevin On 12/3/2019 11:35 AM, Andy Herrick wrote: Please review the revised cumulative jpackage webrev at [3] /Andy [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11D/ On 11/18/2019 12:01 PM, Andy

Re: RFR: JDK-8237607: [macos] Signing app bundle with jpackage fails if runtime is already signed

Looks good to me. +1 -- Kevin On 1/22/2020 8:37 PM, Alexander Matveev wrote: Please review the jpackage fix for bug [1] at [2]. - Fixed by forcing signing even if runtime already signed. - Original implementation was not taken in consideration that runtime can be signed (JDK itself is signe

Re: RFR: JDK-8238168: Remove Copyright from WinLauncher.template

Looks good. +1 -- Kevin On 1/29/2020 10:34 AM, Andy Herrick wrote: Please review trivial jpackage fix to [1] at [2] [1] https://bugs.openjdk.java.net/browse/JDK-8238168 [2] http://cr.openjdk.java.net/~herrick/8238168/webrev.01/ /Andy

Re: jpackage current status

I doubt this has anything to do with jpackage being in incubator or not. Fundamentally, just copying binary launchers into another JDK image like you are doing is only going to work by accident, if it works at all. If you need jpackage (or javac or jar or ...) to be in a JDK image, then you sho

Re: jpackage current status

<mailto:mik3h...@gmail.com>> wrote: On Feb 21, 2020, at 11:12 AM, Kevin Rushforth mailto:kevin.rushfo...@oracle.com>> wrote: I doubt this has anything to do with jpackage being in incubator or not. Fundamentally, just copying binary launchers into another JDK image like y

Re: jpackage current status

Since your ToolProvider-based program doesn't explicitly require jdk.incubator.jpackage, it won't be in the module graph. It should work fine if you run with: $ java --add-modules jdk.incubator.jpackage ... -- Kevin On 2/24/2020 8:23 AM, Michael Hall wrote: On Feb 22, 2020, at 7:02 PM, Mi

Re: jpackage current status

On 2/24/2020 12:31 PM, Michael Hall wrote: On Feb 24, 2020, at 1:48 PM, Michael Hall wrote: On Feb 24, 2020, at 1:15 PM, Kevin Rushforth wrote: Since your ToolProvider-based program doesn't explicitly require jdk.incubator.jpackage, it won't be in the module graph. It s

Re: jpackage with a single java property

No, I doubt this is a bug. If the following worked: --java-options -Dfoo="bar 2" meaning if the entire string `-Dfoo=bar 2` was treated as a single argument, then the following would fail: --java-options "--ea -Dfoo=bar" since it would also be treated as a single argument rather than two se

Re: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo`

On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to > avoid keeping a referent strongly reachable that could cause unnecessary > delay in collecting such object. I only made change in some but not all > classes i

Re: RFR: 8253497: Core Libs Terminology Refresh

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words > with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were > changed as follows: > 1

Re: RFR: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources

On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote: > Remove needless `#ifdef __cplusplus` from .cpp sources @alexeysemenyukoracle FYI, there was no need to force-push (or even push at all) to your branch. It doesn't matter at all what the commit message(s) of the commit(s) in the source b

Re: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0

On Thu, 11 Feb 2021 17:14:35 GMT, Roger Riggs wrote: > On Mac Os X, the OSVersionTest detected a difference in the version number > reported in the os.version property > and the version number provided by `sw_vers -productVersion`. > > When the java runtime is built with XCode 11.3, the os.vers

Re: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0

On Thu, 11 Feb 2021 17:46:06 GMT, Roger Riggs wrote: >> @kevinrushforth I think you are correct. This is actually mea culpa I think >> as I had provided in a Slack thread a failed attempt at a patch for this >> which contained this comment. > > So the words "other than" are too subtle? It's a

Re: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0

On Thu, 11 Feb 2021 17:50:20 GMT, Brian Burkhalter wrote: >> It's a double negative, unless I'm reading it incorrectly: "other than >> pre-10.16" I interpret as "not pre-10.16" or "10.16". > > `// Copy out the char* if running on version 10.x[.y], where x < 16` ? It will also do it if running o

Re: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v2]

On Thu, 11 Feb 2021 18:34:54 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number >> reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os

Re: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0

On Thu, 11 Feb 2021 17:14:35 GMT, Roger Riggs wrote: > On Mac Os X, the OSVersionTest detected a difference in the version number > reported in the os.version property > and the version number provided by `sw_vers -productVersion`. > > When the java runtime is built with XCode 11.3, the os.vers

Re: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v2]

On Thu, 11 Feb 2021 18:53:08 GMT, Kevin Rushforth wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Correct double-negative in 'other than 10.16' > > src/java.base/macosx/nat

Re: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v3]

On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number >> reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os

Re: RFR: JDK-8248904: Add support to jpackage for the Mac App Store

On Wed, 24 Feb 2021 21:59:22 GMT, Andy Herrick wrote: > Implementation of Mac App Support including three new mac specific CLI > options. Looks good with a couple questions. Is `JavaApp.icns` intended to be an empty file (I see that the file it was renamed from was empty, so probably OK)? The

Re: RFR: 8263480: ProblemList two jpackage tests on Windows

On Thu, 11 Mar 2021 23:41:53 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList two new tests on Windows. Marked as reviewed by kcr (Author). - PR: https://git.openjdk.java.net/jdk/pull/2952

Re: RFR: 8263480: ProblemList two jpackage tests on Windows

On Thu, 11 Mar 2021 23:44:18 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList two new tests on Windows. > > @alexeysemenyukoracle or @kevinrushforth - can either of you folks review > this ProblemListing? Sure, although I a not a Reviewer in the jdk project, so it will need one

Re: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]

On Sat, 13 Mar 2021 00:42:13 GMT, Alexander Matveev wrote: >> 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 one additional >>

Re: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException [v5]

On Mon, 15 Mar 2021 16:19:20 GMT, Craig Andrews wrote: >> Marked as reviewed by psadhukhan (Reviewer). > > What's the next step in the process for this PR? You need to fix this error: > Title mismatch between PR and JBS for issue JDK-8262277 by changing the title of this PR to match the JBS

Re: RFR: JDK-8262277: URLClassLoader.getResource throws undocumented IllegalArgumentException [v5]

On Mon, 15 Mar 2021 16:29:54 GMT, Craig Andrews wrote: >> You need to fix this error: >> >>> Title mismatch between PR and JBS for issue JDK-8262277 >> >> by changing the title of this PR to match the JBS title. Then you should be >> able to integrate it. > >> You need to fix this error: >>

Re: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]

On Mon, 15 Mar 2021 19:43:12 GMT, Alexey Semenyuk wrote: >> Changes requested by iklam (Reviewer). > > @kevinrushforth I plan to resolve JDK-8263474 manually as "Delivered". Would > this work? Yes, that should work. - PR: https://git.openjdk.java.net/jdk/pull/2975

Re: RFR: JDK-8263545: Convert jpackage to use Stream.toList()

On Sun, 14 Mar 2021 18:22:50 GMT, Ian Graves wrote: > This converts jpackage to use `Stream.toList()` instead of > `Stream.collect(Collectors.toList())`. One piece of code was modified to not > mutate a list in addition to one test that used a mutating sort on a list. > The rest of the changes

Re: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

On Tue, 23 Mar 2021 17:09:20 GMT, Andy Herrick wrote: > We are backing out the fix to "JDK-8248904 Add support to jpackage for the > Mac App Store " in order to resubmit with added contributor attribution for > Erwin Morrhey > This is the backout. Looks good, although i see the following wasn'

Re: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

On Tue, 23 Mar 2021 18:17:00 GMT, Andy Herrick wrote: >> Looks good, although i see the following wasn't backed out: >> >> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns >> >> If this is intentional, then no need to worry about it. > >> Looks good, although i see t

Re: RFR: JDK-8264057: [redo] JDK-8248904: Add support to jpackage for the Mac App Store.

On Wed, 24 Mar 2021 11:00:53 GMT, Andy Herrick wrote: > Restoring fix to JDK-8248904: Add support to jpackage for the Mac App Store. I can confirm that this restores the fix for JDK-8248904. There are no diffs in any jpackage file between the commit prior to the backout and this PR. --

Re: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick wrote: > implementation of > JDK-8256145: JEP 398: Deprecate the Applet API for Removal src/java.desktop/share/classes/java/applet/package-info.java line 39: > 37: * applet development environment. > 38: * > 39: * @deprecated. This package has

Re: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations [v2]

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick wrote: >> implementation of >> JDK-8256145: JEP 398: Deprecate the Applet API for Removal > > 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 > bro

Re: RFR: JDK-8265078: jpackage tests on Windows leave large temp files [v2]

On Tue, 13 Apr 2021 21:05:26 GMT, Andy Herrick wrote: >> two changes: >> One to jpackage, when recursively removing directory, when IOException >> occurs, record it and continue (deleting as much as possible) before >> throwing the exception. >> The other to tests, when running jpackage via Pro

Re: RFR: JDK-8265078: jpackage tests on Windows leave large temp files [v3]

On Tue, 13 Apr 2021 22:50:12 GMT, Andy Herrick wrote: >> two changes: >> One to jpackage, when recursively removing directory, when IOException >> occurs, record it and continue (deleting as much as possible) before >> throwing the exception. >> The other to tests, when running jpackage via Pro

Re: RFR: JDK-8265078: jpackage tests on Windows leave large temp files [v2]

On Wed, 14 Apr 2021 17:36:21 GMT, Alexey Semenyuk wrote: > postVisitDirectory() and visitFile() methods can be potentially called > concurrently by walkFileTree() I don't think they can. > Javadoc ... doesn't say anything about synchronization, so I think it is fair > to assume it is not guar

Re: Proposal to add JavaScript platform to jpackage

Without commenting on the value proposition of what you propose to do, I am fairly certain that jpackage is not the way to do it. The job of jpackage is to take an application, bundle it with a Java Runtime, and create a native package / installer from it. What you are describing goes far beyon

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files

On Fri, 30 Apr 2021 04:22:37 GMT, Alexander Matveev wrote: > jpackage should specify architecture for produced PKG files via > hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable > on x64 without specifying hostArchitectures which is not correct and if > install on arm

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4]

On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via >> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable >> on x64 without specifying hostArchitectures which is not correct and if >> install on a

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4]

On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via >> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable >> on x64 without specifying hostArchitectures which is not correct and if >> install on a

  1   2   3   >