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

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 present in the `javadoc` tool. For instance, https://github.com/

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

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

Hi! JavaFX is no longer a part of OpenJDK. It does not make sense to treat it specially in the JDK. Hence, as suggested in JDK- 8248122 , the Launcher class should be refactored to remove the JavaFX

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 reveals that some JavaFX specific code

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: 8202471: Make type annotations on owner type parameters available [v3]

> A method's or constructor's owner type might carry annotations on its > potential type parameters but is never represented as parameterized type what > makes these parameters inaccessible at runtime, despite the presence of > parameter type annotations. Rafael Winterhalter has updated the pul

Re: RFR: 8186085: (opt) add filter(), flatMap(), and map() methods to OptionalDouble/Int/Long

On Sun, 25 Oct 2020 10:49:01 GMT, Kartik Ohri wrote: > Hi all, > This PR intends to add filter, map and flatMap methods to the Optional > classes for primitives. The rationale is consistency with the Optional class > for objects and user convenience. > Thanks. > Regards, > Kartik Kindly revie

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

> JDK-8252870: Finalize (remove "incubator" from) jpackage Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into JDK-8252870 - Merge branch master into JDK-8252870 - Merge branch 'ma

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

On Sat, 31 Oct 2020 16:10:23 GMT, Kevin Rushforth wrote: >> This will cause a regression in behavior. It will break existing JavaFX >> applications that do not have a main program. It could also break >> applications that create or use certain JavaFX objects in the class >> initializer of thei

Re: RFR: 8202471: Make type annotations on owner type parameters available [v4]

> A method's or constructor's owner type might carry annotations on its > potential type parameters but is never represented as parameterized type what > makes these parameters inaccessible at runtime, despite the presence of > parameter type annotations. Rafael Winterhalter has refreshed the c

Re: RFR: 8202471: Make type annotations on owner type parameters available

On Tue, 27 Oct 2020 19:09:33 GMT, Aleksey Shipilev wrote: >> A method's or constructor's owner type might carry annotations on its >> potential type parameters but is never represented as parameterized type >> what makes these parameters inaccessible at runtime, despite the presence of >> para