On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote:
>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback.
Marked as reviewed by kcr (Author).
-
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote:
> Time to start getting ready for JDK 20...
You also need to change the JBS version from 19 to 20 in
[`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4):
-
PR:
On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev
wrote:
>> - It is not possible to support native JDK commands such as "java" inside
>> Mac App Store bundles due to embedded info.plist. Workarounds suggested in
>> JDK-8286122 does not seems to be visible.
>> - With proposed fix we will
On Wed, 6 Apr 2022 14:12:49 GMT, Daniel Jeliński wrote:
>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties
>> line 63:
>>
>>> 61: message.creating-association-with-null-extension=Creating association
>>> with null extension.
>>> 62:
On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeliński wrote:
>> This patch adds missing `r` in `string`s
>
> Daniel Jeliński has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - revert xalan changes
> - revert icu changes
The `jpackage` part of
On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeliński wrote:
> This patch adds missing `r` in `string`s
This PR cuts across many areas, so will need multiple reviewers. Regarding the
LCMS file, we typically don't make these kind of changes in third-party code,
since it will cause our code to
On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung wrote:
> redo of 8280400
Since this is identical to the original fix, I would expect the same Tier2 test
failure as reported in
[JDK-8283804](https://bugs.openjdk.java.net/browse/JDK-8283804).
-
PR:
On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote:
> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.
I confirm that this is an exact backout of
[JDK-8280400](https://bugs.openjdk.java.net/browse/JDK-8280400).
-
Marked as reviewed by kcr (Author).
PR:
On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote:
> What problem are you having editing the PR header? You should be able to do
> so as the author of the PR
Exactly. You should see an "Edit" button near the right edge of the PR title.
See the attached image:
On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie wrote:
> TheShermanTanker is not the author of this PR, he's just assisting the author
> by creating the JBS issue.
Ah, that explains it then.
-
PR: https://git.openjdk.java.net/jdk/pull/7268
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
But as the JBS title and PR title now match, this is a moot point.
-
PR:
On Wed, 2 Mar 2022 15:26:35 GMT, Devin Smith wrote:
> Thanks for the help. I signed the OCA on Jan 17, 2022 and got confirmation it
> was approved on Jan 20, 2022.
Correct. Reviewers may know that this has been recorded if the PR has no `oca`
label (you can see above that the `oca` label was
On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote:
> Added ability to override description for additional launchers via
> "description" property.
This will need a CSR.
-
PR: https://git.openjdk.java.net/jdk/pull/7399
On Thu, 13 Jan 2022 15:23:25 GMT, Claes Redestad wrote:
> I've taken up the (bad?) habit of creating it manually to keep a tab on my
> current tasks and intents.
I do that too in some cases, and for the same reason. The only potential
downside is if you create a concrete version for a
On Thu, 13 Jan 2022 15:05:42 GMT, Claes Redestad wrote:
> > (This a backport but is using the mainline bug number; already resolved).
>
> I think that's intentional? I entered "Backport COMMITHASH" as the PR subject
> as per instructions and the bots have taken things from there.
Yes, it's
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from
> version 13 to version 14. Corresponding CSR has also been drafted.
The CSR is now approved. This comment should be sufficient to wake up the bot.
-
On Tue, 7 Dec 2021 13:27:44 GMT, Alan Bateman wrote:
>> @jddarcy hi Joe, what's the next step with the CSR now?
>> https://bugs.openjdk.java.net/browse/JDK-8277755
>> thanks
>
>> @jddarcy hi Joe, what's the next step with the CSR now?
>> https://bugs.openjdk.java.net/browse/JDK-8277755
>>
On Fri, 10 Dec 2021 17:01:41 GMT, Andrew Leonard wrote:
>> Looks like the CSR has been approved. I have a mach5 run that should
>> hopefully finish sooner rather than later and if that remains happy, I will
>> approve the PR
>
> @LanceAndersen let me know if mach5 looks good please, then I
On Tue, 7 Dec 2021 10:42:50 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get
On Wed, 24 Nov 2021 08:54:08 GMT, 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
project, build it yourself, and include it with
your application. Either way, this isn't a JDK problem.
-- Kevin
On 11/22/2021 11:56 AM, Michael Hall wrote:
On Nov 22, 2021, at 12:39 PM, Alan Snyder wrote:
On Nov 22, 2021, at 10:12 AM, Kevin Rushforth
wrote:
JNF was removed from
JNF was removed from the JDK if that's what you are asking.
-- Kevin
On 11/22/2021 10:11 AM, Alan Snyder wrote:
Well, if you look at the JNF part of the tree, the only include I see that
comes from the JDK is jni.h.
Isn’t that what you were questioning?
On Nov 22, 2021, at 10:06 AM,
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
I've made an
application image with jpackage. I've moved the default location of the
runtime in the application image
...
If I keep the runtime in $APPDIR\runtime, things don't fail in this way.
If it works when using the default location of the Java runtime and no
other changes, I'd guess
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
I fetched the PR commit and confirmed that it is a correct backout (revert) of
JDK-8271868.
-
Marked as reviewed by kcr (Author).
PR:
On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote:
> backport from jdk-18
This must _not_ be integrated into this repo.
See [JDK-8273592](https://bugs.openjdk.java.net/browse/JDK-8273592) for an
explanation as to why. There is no more content approved for JDK 17. This
should go into
On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote:
> backport from jdk-18
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk17/pull/306
On Mon, 30 Aug 2021 19:23:57 GMT, Сергей Цыпанов
wrote:
>> Just a very tiny clean-up.
>>
>> There are some places in JDK code base where we call
>> `Enum.class.getEnumConstants()` to get all the values of the referenced
>> `enum`. This is excessive, less-readable and slower than just calling
On Mon, 9 Aug 2021 12:28:23 GMT, CC007
wrote:
> create Streamable and ParallelStreamable interface and use them in Collection
> and Optional
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/5050
On Sun, 15 Aug 2021 02:45:17 GMT, CC007
wrote:
>> create Streamable and ParallelStreamable interface and use them in
>> Collection and Optional
>
> I read through [these
> posts](http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/thread.html#1910)
> and while I did see
On Thu, 29 Jul 2021 19:05:58 GMT, Roger Riggs wrote:
> Improve the clarity of comments in the ObjectInputFilter FilterInThread
> example.
Marked as reviewed by kcr (Author).
-
PR: https://git.openjdk.java.net/jdk17/pull/293
On Wed, 28 Jul 2021 17:08:01 GMT, Emmanuel Bourg
wrote:
>> I'm happy to sponsor this change, but could you please update the copyright
>> year where necessary, e.g. in
>> src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java:
>> `Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c)
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?
-- 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
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.
Alexey filed [JDK-8271170](https://bugs.openjdk.java.net/browse/JDK-8271170) to
cover this.
-
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.
Looks good. Is there a unit test associated with this? If not, do you think one
would be useful?
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 will need a CSR (so you or someone with a Reviewer role should indicate
this with the `/csr` command).
Also, can you
On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang wrote:
> Hi, can I have a review of this change that adds two new utility methods for
> java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of
> ByteOrder.nativeOrder() is to check if the underlying platform is
>
On Thu, 10 Jun 2021 08:11:42 GMT, Rafael Winterhalter
wrote:
>> Please add an overview to test before integrating; thanks.
>
>> Please add an overview to test before integrating; thanks.
>
> Sorry, I missed that one. Not sure what you mean by *overview*? I was not
> sure if there's an
On Mon, 24 May 2021 18:55:33 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/lang/Process.java line 771:
>>
>>> 769:
>>> 770: /**
>>> 771: * {@return Charset for the native encoding or {@link
>>> Charset#defaultCharset()}
>>
>> Need some edit here?
>
> Looks odd,
On Fri, 21 May 2021 12:22:16 GMT, Andy Herrick wrote:
> JDK-8267423: Fix copyrights in jpackage tests
Marked as reviewed by kcr (Author).
-
PR: https://git.openjdk.java.net/jdk/pull/4144
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
tion bundle
in either WAR or ZIP format.
On Mon, Apr 26, 2021 at 5:39 AM Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
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
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
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
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
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
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
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
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
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
>
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
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.
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
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
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
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
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:
>>
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
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
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
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
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
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
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
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/native/libjav
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
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
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
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
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
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:
>
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
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
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
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
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
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:
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)
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
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
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
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
>
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
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
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
>> removin
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
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
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
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
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
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
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
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 should work
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,
<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 lik
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
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
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
1 - 100 of 210 matches
Mail list logo
