Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]

2022-05-26 Thread Kevin Rushforth
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

Re: RFR: JDK-8284858: Start of release updates for JDK 20

2022-05-26 Thread Kevin Rushforth
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

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

2022-05-17 Thread Kevin Rushforth
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

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

2022-03-07 Thread Kevin Rushforth
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

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

2022-03-07 Thread Kevin Rushforth
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

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

2022-03-07 Thread Kevin Rushforth
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

Re: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0

2022-01-12 Thread Kevin Rushforth
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

Re: RFR: 8279223: Define version in .jcheck/conf

2022-01-03 Thread Kevin Rushforth
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

Re: RFR: 8276905: Function frag_col has a deployment target which is incompatible with this OS [v3]

2021-11-15 Thread Kevin Rushforth
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

Re: RFR: 8276905: Function frag_col has a deployment target which is incompatible with this OS [v4]

2021-11-15 Thread Kevin Rushforth
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

Re: RFR: 8276905: Function frag_col has a deployment target which is incompatible with this OS [v2]

2021-11-15 Thread Kevin Rushforth
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

Re: RFR: JDK-8272374: doclint should report missing "body" comments

2021-08-13 Thread Kevin Rushforth
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

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

2021-05-20 Thread Kevin Rushforth
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

Re: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations

2021-03-30 Thread Kevin Rushforth
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

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

2021-03-24 Thread Kevin Rushforth
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: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v13]

2021-03-11 Thread Kevin Rushforth
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

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v12]

2021-03-10 Thread Kevin Rushforth
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

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]

2021-02-08 Thread Kevin Rushforth
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" (

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]

2021-02-08 Thread Kevin Rushforth
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 := $(

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline

2021-02-05 Thread Kevin Rushforth
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

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline

2021-02-05 Thread Kevin Rushforth
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

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline

2021-02-05 Thread Kevin Rushforth
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

Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2]

2021-02-02 Thread Kevin Rushforth
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

Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v3]

2021-02-02 Thread Kevin Rushforth
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

Re: RFR: 8253497: Core Libs Terminology Refresh

2020-12-14 Thread Kevin Rushforth
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: 8248862: Implement Enhanced Pseudo-Random Number Generators

2020-11-17 Thread Kevin Rushforth
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: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

2020-11-17 Thread Kevin Rushforth
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: 8251854: [macosx] Java forces the use of discrete GPU

2020-11-10 Thread Kevin Rushforth
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,

Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU

2020-11-10 Thread Kevin Rushforth
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

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

2020-10-13 Thread Kevin Rushforth
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]

2020-10-13 Thread Kevin Rushforth
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-8252870: Finalize (remove "incubator" from) jpackage

2020-10-13 Thread Kevin Rushforth
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

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

2020-10-13 Thread Kevin Rushforth
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

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

2020-10-13 Thread Kevin Rushforth
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: #

Integrated: 8253206: Enforce whitespace checking for additional source files

2020-09-16 Thread Kevin Rushforth
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

RFR: 8253206: Enforce whitespace checking for additional source files

2020-09-15 Thread Kevin Rushforth
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

Integrated: 8253031: git jcheck complains about invalid tags in jdk repo after fix for JDK-8252844

2020-09-11 Thread Kevin Rushforth
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

RFR: 8253031: git jcheck complains about invalid tags in jdk repo after fix for JDK-8252844

2020-09-11 Thread Kevin Rushforth
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`

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

2020-09-10 Thread Kevin Rushforth
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: 8252999: replace all String.equals("") usages with String.isEmpty()

2020-09-10 Thread Kevin Rushforth
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: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

2020-08-25 Thread Kevin Rushforth
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

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

2020-08-25 Thread Kevin Rushforth
;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

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

2020-08-25 Thread Kevin Rushforth
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

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

2019-11-26 Thread Kevin Rushforth
://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

2019-04-30 Thread Kevin Rushforth
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

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

2018-11-28 Thread Kevin Rushforth
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

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

2018-11-28 Thread Kevin Rushforth
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

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

2018-11-28 Thread Kevin Rushforth
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

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

2018-10-30 Thread Kevin Rushforth
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

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

2018-10-25 Thread Kevin Rushforth
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

Re: RFR: JDK-8062810: Examine src.zip in JDK image and decide if source classes should be organized by module

2016-10-26 Thread Kevin Rushforth
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

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

2016-06-14 Thread Kevin Rushforth
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.

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

2016-06-13 Thread Kevin Rushforth
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

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

2016-06-09 Thread Kevin Rushforth
, 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

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

2016-06-08 Thread Kevin Rushforth
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

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

2016-06-08 Thread Kevin Rushforth
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

Re: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module

2016-03-07 Thread Kevin Rushforth
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

Re: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module

2016-03-05 Thread Kevin Rushforth
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

Re: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module

2016-03-04 Thread Kevin Rushforth
$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

Re: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module

2016-03-03 Thread Kevin Rushforth
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/