Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

Great! Thanks Prasanta. Mandy On 6/15/18 5:42 AM, Prasanta Sadhukhan wrote: I confirm jdk.unsupported.desktop is not present in doc build. Regards Prasanta

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

it has been verified that it is excluded from the docs build .. right Prasanta ? -phil On 06/14/2018 01:26 PM, mandy chung wrote: I reviewed the module-info.java change. @since 12 is missing in jdk.unsupported.desktop module-info.java Otherwise it's fine. Does the docs build exclude

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

On 6/14/18 1:29 PM, Phil Race wrote: you surely mean @since 11 Oops typo. Yes @since 11 Mandy

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

I reviewed the module-info.java change. @since 12 is missing in jdk.unsupported.desktop module-info.java Otherwise it's fine. Does the docs build exclude jdk.unsupported.desktop? You might have confirmed that that I missed. Mandy On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: Hi Phil,

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

On 5/9/18 7:48 AM, Alan Bateman wrote: On 09/05/2018 15:42, Philip Race wrote: : Qn. to Mandy & Alan : it seems there is no need to mention this module in make/common/Modules.gmk in order to get it built, but is there any advantage in doing so ? I mean without it, there is no conscious

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

On 5/7/18 2:26 AM, Prasanta Sadhukhan wrote: Modified webrev to use InteropProvider http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ This version looks good.   InteropProviderImpl name is okay with me. Mandy

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

I skimmed through the sources.  It's good to see that this patch is straight forward.  A couple of comments: jdk.unsupported.desktop is defined to the application class loader which I think it's fine as FX modules are defined to the same class loader. I expect

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

. This seems better to leave for the follow-on JBS issue (JDK-8200236) unless there something I am missing. -- Kevin mandy chung wrote: You don't need the loggers map and getLogger method can simply return return new PlatformLogger(System.getLogger(name)); Other than this, looks fine

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

-Original Message- From: Kevin Rushforth Sent: Saturday, March 24, 2018 3:27 AM To: Ajit Ghaisas Cc: Mandy Chung; Daniel Fuchs; openjfx-dev@openjdk.java.net Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules The only additional

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

On 3/23/18 9:34 AM, Ajit Ghaisas wrote: Hi Kevin, Mandy and Daniel, Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 Fix :

Re: [11] RFR : JDK-8195800 : Eliminate dependency on sun.reflect.misc in javafx modules

On 3/19/18 7:10 AM, Ambarish Rapte wrote: Hi Kevin, Alan & Mandy,     Request you to review this fix:     Webrev: http://cr.openjdk.java.net/~arapte/fx/8195800/webrev.00/     JBS:

Re: [9] Review request: 8180040: Exclude jdk.packager module from unified JDK 9 docs

’d be good. > I can add the the missing copyright headers at the same time. > OK. No need for an updated webrev. Mandy > -- Kevin > > > Mandy Chung wrote: >> >>> On May 9, 2017, at 6:08 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> >>> <mai

Re: [9] Review request: 8180040: Exclude jdk.packager module from unified JDK 9 docs

> On May 9, 2017, at 6:08 PM, Kevin Rushforth > wrote: > > Please review the following to exclude jdk.packager module from the JDK docs > bundle: > > https://bugs.openjdk.java.net/browse/JDK-8180040 > http://cr.openjdk.java.net/~kcr/8180040/webrev.00/ > > I also

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Looks good. "Deploying an Application as a Module” section is duplicated in several JavaBean*Property classes. One alternative is to move it to the package summary. I have no objection to leave it as is. Mandy > On May 3, 2017, at 4:30 PM, Kevin Rushforth >

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

> On May 2, 2017, at 2:22 PM, Kevin Rushforth > wrote: > > Here is the message: > > IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot > access class com.foo (in module foo.app) because module foo.app does not open > com.foo to javafx.base

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Hi Kevin, > On May 1, 2017, at 5:21 PM, Kevin Rushforth > wrote: > > This review is being cross-posted to both openjfx-dev and jigsaw-dev. > > Please review the proposed fix for: > > https://bugs.openjdk.java.net/browse/JDK-8177566 >

Re: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules

> "accessible to"). > > http://cr.openjdk.java.net/~kcr/8178015/webrev.02/ > > Additionally, I removed the example in the FXML annotation showing the use of > "opens to" in module-info.java (but left the example in Application). > > -- Kevin > > > Kevin Rus

Re: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules

> On Apr 18, 2017, at 12:48 PM, Kevin Rushforth > wrote: > > > > Alan Bateman wrote: >> >> >> On 18/04/2017 19:19, Kevin Rushforth wrote: >>> Good suggestion. Here is an updated webrev with Mandy's suggestion and >>> yours: >>> >>>

Re: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules

> On Apr 17, 2017, at 5:00 PM, Kevin Rushforth > wrote: > > Please review the following javadoc change: > > https://bugs.openjdk.java.net/browse/JDK-8178015 > http://cr.openjdk.java.net/~kcr/8178015/webrev.00/ > + * Applications in a Module : + * {@link

Re: [9] Review request: 8173080: Add licenses for non-distributed third-party source code in repo

> On Apr 5, 2017, at 3:51 PM, Kevin Rushforth > wrote: > > Dave, > > Please review the following fix to add missing .md license files for > non-distributed third-party source code in our repo: > > https://bugs.openjdk.java.net/browse/JDK-8173080 >

Re: [9] Review request: 8170701: Update FXML documentation for setAccessible

> On Mar 6, 2017, at 7:11 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > > > Mandy Chung wrote: >> >>> On Mar 4, 2017, at 5:14 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> >>> <mailto:kevin.rushfo...@oracle.com

Re: [9] Review request: 8170701: Update FXML documentation for setAccessible

> On Mar 4, 2017, at 5:14 PM, Kevin Rushforth > wrote: > > http://cr.openjdk.java.net/~kcr/8170701/webrev.01/ > 40 * object {@link Module#isOpen opens} the containing package to the Nit: s/@link/@linkplain 41 * {@code javafx.fxml} module, either in its

Re: [9] Review request: 8170702: Document that javafx.graphics needs explicit access to application main class

> On Mar 4, 2017, at 1:04 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > > > Mandy Chung wrote: >> >>> On Mar 3, 2017, at 10:36 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> >>> <mailto:kevin.rushfo...@oracle.com>

Re: [9] Review request: 8170702: Document that javafx.graphics needs explicit access to application main class

> On Mar 3, 2017, at 10:36 PM, Kevin Rushforth > wrote: > > [fixed subject line] > > Please review the following to document that javafx.graphics needs explicit > access to the Application class. > > https://bugs.openjdk.java.net/browse/JDK-8170702 >

Re: [9] Review request: 8170701: Update FXML documentation for setAccessible

> On Mar 3, 2017, at 10:29 PM, Kevin Rushforth > wrote: > > Please review the following to update the FXML docs to document the > requirement for a module that annotates non-public members with @FXML to > "open" the containing package to the javafx.fxml module. >

Re: [9] Review request: 8172526: Third-party licenses for javafx.* modules are missing

+1 Mandy > On Feb 13, 2017, at 5:30 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > Fixed. Thanks. > > http://cr.openjdk.java.net/~kcr/8172526/webrev.01/ > <http://cr.openjdk.java.net/~kcr/8172526/webrev.01/> > > -- Kevin > >

Re: [9] Review request: 8172526: Third-party licenses for javafx.* modules are missing

> On Feb 13, 2017, at 1:50 PM, Kevin Rushforth > wrote: > > Dave & Mandy, > > Please review the following fix to deliver the JavaFX third-party license > content into the JDK build. > > https://bugs.openjdk.java.net/browse/JDK-8172526 >

Re: [9] Review request: JDK-8170485: Switch to building JavaFX with new module-info syntax

> On Dec 6, 2016, at 8:10 AM, Kevin Rushforth > wrote: > > Chien & Dave, > > Please review the preliminary webrev to allow building JavaFX with jdk-9+148 > and later: > > https://bugs.openjdk.java.net/browse/JDK-8170485 >

Re: [9] Review request: DK-8169417: JavaFX to include jake-compatible versions of module-info.java with import bundles

Looks good to me. Mandy > On Nov 8, 2016, at 4:11 PM, Kevin Rushforth > wrote: > > Hi, > > Please review the following fix to include jake-compatible versions of > module-info.java with our input bundles: > > https://bugs.openjdk.java.net/browse/JDK-8169417 >

Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9

> On May 27, 2016, at 1:30 AM, Tom Schindl wrote: > > Do you have an example how to construct such a Layer? // path is the path to javafx-swt.jar ModuleFinder finder = ModuleFinder.of(path); Configuration cf = Layer.boot() .configuration()

Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9

gt;>> >>> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) >>> use case for SWT useage. >>> >>> The SWT jar is not on the application classpath so how should a module >>> (named or unnamed) find the SWT classes? >>>

Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9

> On May 25, 2016, at 3:38 PM, Kevin Rushforth > wrote: > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8131888 > http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ > > This adds support for the javafx.embed.swt package back into the

Re: [9] Review request: 8153872: Nashorn no longer needs access to com.sun.javafx.application

> On Apr 19, 2016, at 8:25 AM, Kevin Rushforth > wrote: > > Jim, > > Please review the following fix: > > https://bugs.openjdk.java.net/browse/JDK-8153872 > http://cr.openjdk.java.net/~kcr/8153872/webrev.00/ > > This is a simple backout of the earlier fix for

Re: [9] Review request: 8154203: Use StackWalker instead of the now-deprecated sun.reflect.Reflection class

> On Apr 14, 2016, at 3:27 PM, Kevin Rushforth > wrote: > > Hi Vadim, > > Please review: > > https://bugs.openjdk.java.net/browse/JDK-8154203 > http://cr.openjdk.java.net/~kcr/8154203/webrev.00/ > > It's a straight-forward fix to replace