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).
-
P
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: https://git
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 enf
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:
![PR-title](https://user-imag
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: https://git.openjdk.java.net/jdk/pull/726
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.
-
P
On Thu, 23 Dec 2021 14:16:37 GMT, Erik Joelsson wrote:
> This patch adds the version field to .jcheck/conf. By doing this we can
> remove the corresponding configuration from the Skara bots, which in turn
> reduces the need for timing and general complexity of starting a new JDK
> release.
Ma
On Mon, 15 Nov 2021 13:44:11 GMT, Jayathirth D V wrote:
>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in
>> macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set
>> any deployment target when when we use xcrun to create .air file and this
>> iss
On Mon, 15 Nov 2021 13:57:25 GMT, Jayathirth D V wrote:
>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in
>> macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set
>> any deployment target when when we use xcrun to create .air file and this
>> iss
On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V wrote:
>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in
>> macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set
>> any deployment target when when we use xcrun to create .air file and this
>> iss
On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons wrote:
> Please review a relatively simple update to have doclnt check for empty
> "descriptions" -- the body of a doc comment, before the block tags.
>
> It is already the case that doclint checks for missing/empty descriptions in
> block tag
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.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
On Tue, 30 Mar 2021 12:34:50 GMT, Erik Joelsson wrote:
>> As I understand it, the intention is to bump the Xcode version for x64 as
>> well, though I must say I would prefer that change to go in separately.
>
> To answer Magnus, on line 1133, we define a different dependency, called
> "lldb". T
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 Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API
On Wed, 10 Mar 2021 10:51:08 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API
On Mon, 8 Feb 2021 17:15:25 GMT, Gerard Ziemski wrote:
> General comment - I am not sure I like the `MTL` prefix acronym in names (ex.
> `sun.java2d.metal.MTLVolatileSurfaceManager`).
>
> I think you tried to match the `CGL`, but that is a real acronym that stands
> for "Core Graphics Layer" (
On Mon, 8 Feb 2021 13:40:22 GMT, Ajit Ghaisas wrote:
>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 894:
>>
>>> 892: SHADERS_SUPPORT_DIR :=
>>> $(SUPPORT_OUTPUTDIR)/native/java.desktop/libosxui
>>> 893: SHADERS_AIR := $(SHADERS_SUPPORT_DIR)/shaders.air
>>> 894: SHADERS_LIB := $(
On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote:
> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering
> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple
> Metal API.
> Th
On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote:
> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering
> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple
> Metal API.
> Th
On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote:
> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering
> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple
> Metal API.
> Th
On Mon, 1 Feb 2021 18:33:32 GMT, Gerard Ziemski wrote:
>> Marked as reviewed by gziemski (Committer).
>
> The changes look good to me, but please see my comment from my review about
> documenting `NormalizedPathNSStringFromJavaString()` API.
The following commit was integrated to jdk master sin
On Tue, 2 Feb 2021 00:30:07 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 53:
>>
>>> 51: @implementation ThreadUtilities
>>> 52:
>>> 53: + (void)initialize {
>>
>> I think we need to check how this new modes will work when the AWT is
>> embedded insi
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
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 Tue, 10 Nov 2020 13:24:21 GMT, Erik Joelsson wrote:
>> This is a review request for the bug particularly fixed some time ago:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>>
>> In that review request it was found that the old fix does not work well in
>> all cases,
On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote:
> This is a review request for the bug particularly fixed some time ago:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>
> In that review request it was found that the old fix does not work well in
> all cases, see
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
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 13:51:27 GMT, Kevin Rushforth wrote:
>> I spot checked it and left a couple comments. The rest looks good. I'll
>> review it in more detail later this week.
>
> @andyherrick the "reviewer credit" command should not be used in this manner.
&g
On Tue, 13 Oct 2020 13:49:13 GMT, Kevin Rushforth wrote:
>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> I spot checked it and left a couple comments. The rest looks good. I'll
> review it in more detail later this week.
@andyherrick the "rev
On Tue, 13 Oct 2020 12:51:54 GMT, Andy Herrick wrote:
> JDK-8252870: Finalize (remove "incubator" from) jpackage
I spot checked it and left a couple comments. The rest looks good. I'll review
it in more detail later this week.
make/data/symbols/jdk.jpackage-E.sym.txt line 29:
> 27: #
On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote:
> This adds the following extensions to the list of source files that git
> jcheck will check for whitespace errors:
>
> .cc, .hh, .m, .mm
>
> All files with the above extensions are now white-space clean after the
This adds the following extensions to the list of source files that git jcheck
will check for whitespace errors:
.cc, .hh, .m, .mm
All files with the above extensions are now white-space clean after the fix for
[JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help
the
On Fri, 11 Sep 2020 14:28:41 GMT, Kevin Rushforth wrote:
> In the fix for
> [JDK-8252844](https://bugs.openjdk.java.net/browse/JDK-8252844) the tags
> entry in `.jcheck/conf` was
> copied from the Skara Java code. The `` chars were escaped as `\` in the Java
> String so that i
In the fix for [JDK-8252844](https://bugs.openjdk.java.net/browse/JDK-8252844)
the tags entry in `.jcheck/conf` was
copied from the Skara Java code. The `` chars were escaped as `\` in the Java
String so that it would contain ``. This
additional level of escape is not needed in the `.jcheck/conf`
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
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
On 8/25/2020 4:17 PM, Sergey Bylokhov wrote:
On 25.08.2020 16:08, Kevin Rushforth wrote:
I haven't tested an FX app yet, but since this changes the plist
properties, I want to see whether or not FX apps are impacted.
It should be affected because the first variation of the fix was
p
;t tested an FX app yet, but since this changes the plist
properties, I want to see whether or not FX apps are impacted.
-- Kevin
On 8/25/2020 4:01 PM, Sergey Bylokhov wrote:
On 25.08.2020 15:40, Philip Race wrote:
On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
On 25.08.2020 05:43, Kevin Rushfo
Does this only apply when the MacBook is running on battery, or will
this affect performance even when the laptop is plugged in? If the
latter, I wonder what Apple's rationale is for including a discrete
graphics card that isn't used most of the time.
-- Kevin
On 8/24/2020 11:27 PM, Sergey B
://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
I have a couple nit-picky comments:
1. The change to src/jdk.jlink/share/classes/module-info.java is
unrelated to jpackage and should be reverted (there is only a
white-space change and a copyright date change to that file)
2. The following files have whitespace errors that will cause jcheck
On 11/28/2018 5:19 AM, Alan Bateman wrote:
On 28/11/2018 13:13, Kevin Rushforth wrote:
The jpackage tool calls JLI_Launch.
I remember that from Andy's webrev but it's not integrated yet. Does
the JavaFX packager tool do the same?
Yes, the javapackager tool (delivered via JavaFX
The jpackage tool calls JLI_Launch.
-- Kevin
On 11/28/2018 5:05 AM, Alan Bateman wrote:
On 28/11/2018 13:03, Kevin Rushforth wrote:
This is related to a bug I filed back in October, JDK-8211959 [1], in
which JLI_Launch is failing for the same reason. The fix to
java_md_macosx.m is the same
This is related to a bug I filed back in October, JDK-8211959 [1], in
which JLI_Launch is failing for the same reason. The fix to
java_md_macosx.m is the same one I identified in that bug. You might
consider adding a test that calls JLI_Launch, but either way,
JDK-8211959 can be closed as a dup
inline
On 10/30/2018 9:09 AM, Alan Bateman wrote:
On 30/10/2018 14:11, Andy Herrick wrote:
:
If I read the webrev correctly then it adds two modules, one with
the jpackager tool and the other with an API. It would be useful to
get a bit more information on the split. Also I think the name
Andy added the a comment [1] to the JEP with the command line options.
I'll format it and add it to the JEP itself soon, but until then you can
see it in the comments to help you review it.
The tests will come shortly (Andy can comment on the state of this).
They will be a mix of automated tes
Looks good to me.
-- Kevin
Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8062810/webrev.02/
Slightly simplified due to less need for closed customizations.
/Erik
On 2016-10-11 11:26, Magnus Ihse Bursie wrote:
On 2016-10-10 15:55, Erik Joelsson wrote:
Hello,
Please r
David DeHaven wrote:
David had said,
it seems safer to leave it false for now and revisit marking for removal in 10
I think this means, "set forRemoval=false in 9, set forRemoval=true in 10, and
actually remove it in 11".
I said that in reference to Applet, not JSObject.
r.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
Thank you!
Best regards,
Daniil
-Original Message-
From: Mandy Chung
Sent: Wednesday, June 08, 2016 3:09 PM
To: Daniil Titov
Cc: David
,
Daniil
-Original Message-
From: Mandy Chung
Sent: Thursday, June 09, 2016 9:23 AM
To: Daniil Titov
Cc: Erik Joelsson; David Dehaven; Stuart Marks; build-dev;
build-infa-...@openjdk.java.net; awt-dev; Kevin Rushforth
Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow
Yes, exactly.
-- Kevin
David DeHaven wrote:
Clarification: in a future *as of yet unspecified* release :)
-DrD-
On Jun 8, 2016, at 1:13 PM, Kevin Rushforth wrote:
Yes, the plan is to deprecate it in 9 and remove it in a future release.
-- Kevin
Mandy Chung wrote:
The client
Yes, the plan is to deprecate it in 9 and remove it in a future release.
-- Kevin
Mandy Chung wrote:
The client team owns jdk.jsobject module and so I add awt-dev to this thread.
And bcc jdk9-dev.
It is not Java SE API and it should not add to CORE-PKGS.gmk. As for
@Deprecated, I believe
Dave,
Just to tie up the loose end about the default JSObject constructor: No
it cannot be package private. JavaFX WebView extends this class.
-- Kevin
Alan Bateman wrote:
On 05/03/2016 18:54, David DeHaven wrote:
I've updated the webrev, hopefully one last time with feedback from
Joe Da
n the default JSObject ctor
A point was brought up that the default ctor could probably be package-private,
but there's no time to investigate what the impact would be so I will file a
follow-up issue to investigate doing that at a later date.
-DrD-
On Mar 4, 2016, at 7:44 AM, Kevin Rushfo
$ProviderLoader.class
/jdk.jsobject/netscape/javascript/JSObject.class
-DrD-
jdk9-dev is not the right mailing list. I bcc’ed it and add jigsaw-dev instead.
On Mar 3, 2016, at 3:57 PM, Kevin Rushforth wrote:
Looks OK to me. I did a quick test build and I can see the new package in
Looks OK to me. I did a quick test build and I can see the new package
in the exploded JDK, but not in the images. Maybe I did something wrong?
-- Kevin
David DeHaven wrote:
JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8132743
Code review:
http://cr.openjdk.java.net/~ddehaven/8132743/
60 matches
Mail list logo
