[9] Code Review Request JDK-8154509: Remove the word impl_ in the name of private methods and members

[Chien Yang]

Hi Kevin,

Please review this simple name change cleanup fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8154509
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8154509/webrev.00/

Thanks,
- Chien

Changes for April 2016 CPU release (8u91/8u92) synced into FX 8u-dev and 9-dev

[Kevin Rushforth]

I have synced the OpenJFX changes from the just-released April 2016 CPU 
release (8u91/8u92) into 8u and into 9.


Here is a webrev of the FX 8u92 changes for those who are interested in 
the changes, but don't want to wade through the 52 separate changesets I 
just pushed (most of which are tag or merge changesets).


http://cr.openjdk.java.net/~kcr/8u92-8u-sync/webrev/

The webrev for 9 is almost identical, but here it is if anyone is 
interested:


http://cr.openjdk.java.net/~kcr/9-cpu-1602-sync/webrev/

-- Kevin

[8u] review request: 8139326: [TEST] Unit tests for JFXPanel with security manager don't detect errors

[Kevin Rushforth]

Hi Chien,

Can you do a quick sanity test review of the backport to 8u-dev of the 
following:


https://bugs.openjdk.java.net/browse/JDK-8139326
http://cr.openjdk.java.net/~kcr/8139326/webrev.00/

This was earlier reviewed (by you) for 9-dev with the intent to backport 
to 8u-dev, but the backport wasn't completed at that time. Since enough 
time has past, I would like a sanity check before pushing to 8u-dev. The 
patch that was pushed to 9-dev imports cleanly into 8u-dev and works as 
expected.


-- Kevin

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

[Kevin Rushforth]

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 JDK-8153754.

-- Kevin

[8u] review request: 8139326: [TEST] Unit tests for JFXPanel with security manager don't detect errors

[Kevin Rushforth]

Hi Chien,

Can you do a quick sanity test review of the backport to 8u-dev of the 
following:


https://bugs.openjdk.java.net/browse/JDK-8139326
http://cr.openjdk.java.net/~kcr/8139326/webrev.00/

This was earlier reviewed (by you) for 9-dev with the intent to backport 
to 8u-dev, but the backport wasn't completed at that time. Since enough 
time has past, I would like a sanity check before pushing to 8u-dev. The 
patch that was pushed to 9-dev imports cleanly into 8u-dev and works as 
expected.


-- Kevin

[9] Review request: 8152355: IllegalAccessError: javafx.media cannot access jdk.internal.ref

[Kevin Rushforth]

Dave D or Alexander,

Please review the following simple fix to add a qualified export for a 
class that is used by javafx.media that has moved as part of JEP-260.


https://bugs.openjdk.java.net/browse/JDK-8152355
http://cr.openjdk.java.net/~kcr/8152355/webrev.00/

I verified that the IllegalAccessException happens before the fix and 
does not happen after the fix.


-- Kevin

Re: What does this mean for the future of JavaFX on iOS?

[Felix Bembrick]

I agree with you on the point that desktops are here to stay, but my point was 
that if JavaFX is only ever going to viable on such desktops then it is not 
cross platform because by far the biggest focus for commercial software 
development companies currently is "post PC" devices like mobiles, tablets and 
IoT.

As someone who runs a software development business, I don't want to have to 
rewrite my applications on every platform, using perhaps completely different 
languages and tools.

Such an approach may result in having the best quality of app on each platform 
but it also is dependent on your business having considerably more staff and 
capital than I have or indeed that most small businesses have.

Forget about Xamarin or any other supposed alternative, unless you are willing 
to walk away from Java itself.

I say lets wait and see what Johan and Gluon can deliver in the next 6 months 
or so, without any dependency on RoboVM. Perhaps one the new forks will be 
suitable but, regardless, I don't believe that someone like Johan who is 
working with some of the best Java, JavaFX and other technicians on the planet 
has not been planning and working on a viable way to enable JavaFX to run and 
run well on mobiles that is entirely independent of whatever happens to RoboVM.

> On 19 Apr 2016, at 21:14, Scott Palmer  wrote:
> 
> 
>>> On Apr 19, 2016, at 4:18 AM, Felix Bembrick  
>>> wrote:
>> 
>> 
>> Let's face it, without highly optimised AOT, Java and/or JavaFX on mobiles 
>> is simply not viable which in turn implies that JavaFX itself is not even 
>> worth looking at... RIP.
> 
> Let's not go crazy. JavaFX is still the best bet for desktop apps. Despite 
> all the hype desktop apps aren't going away. Browser-based apps and 
> JavaScript are still garbage in comparison to what JavaFX offers.
> 
> 
> Scott

[webkit] [9] Review request for 8089842: JavaScript2Java Bridge: A char value cannot be set from JavaScript

[Arunprasad Rajkumar]

Hi Kevin, Alexander, Guru,

Please review the below patch.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8089842

Webrev: http://cr.openjdk.java.net/~arajkumar/8089842/webrev.00/

Issue: There is no way to JS character as a Java Char type.

Fix: There is no Char type in JavaScript, but we can convert JavaScript 
string with length 1 as a Char type.


Regards,
Arun

Re: What does this mean for the future of JavaFX on iOS?

[Tobi]

The question is: How does perform JavaFX in comparison to e.g. Xamarian? 

> Am 19.04.2016 um 13:14 schrieb Scott Palmer :
> 
> 
>> On Apr 19, 2016, at 4:18 AM, Felix Bembrick  wrote:
> 
>> 
>> Let's face it, without highly optimised AOT, Java and/or JavaFX on mobiles 
>> is simply not viable which in turn implies that JavaFX itself is not even 
>> worth looking at... RIP.
> 
> Let's not go crazy. JavaFX is still the best bet for desktop apps. Despite 
> all the hype desktop apps aren't going away. Browser-based apps and 
> JavaScript are still garbage in comparison to what JavaFX offers.
> 
> 
> Scott

Re: What does this mean for the future of JavaFX on iOS?

[Scott Palmer]

> On Apr 19, 2016, at 4:18 AM, Felix Bembrick  wrote:

> 
> Let's face it, without highly optimised AOT, Java and/or JavaFX on mobiles is 
> simply not viable which in turn implies that JavaFX itself is not even worth 
> looking at... RIP.

Let's not go crazy. JavaFX is still the best bet for desktop apps. Despite all 
the hype desktop apps aren't going away. Browser-based apps and JavaScript are 
still garbage in comparison to what JavaFX offers.


Scott

Re: [9] Review request for 8150076: Print jobs are not finished when used a page range

[mikhail cherkasov]

Hi Phil,

Please see my update in jbs:
https://bugs.openjdk.java.net/browse/JDK-8150076

Thanks,
Mikhail.

On 4/14/2016 12:28 AM, Phil Race wrote:

I have an old PageRange printing test where I set
settings.setPageRanges(new 
PageRange(1,3));

and it prints fine on JDK 9 on Win 7 x64.
In fact it also prints fine with 8u74

Also a thread dump doesn't show any problem with the print thread not 
terminating.


So I assume the test that shows the bug must be doing something I am not.

You say [9] above but I see your webrev suggests 8u !
"/cygdrive/c/ws/javafx/8u-dev/rt"

Can you please
(a)  prepare a webrev against 9 instead of 8u.
(b) include (and therefore share) the test you are using that 
illustrates the problem.


-phil.

On 04/12/2016 09:21 AM, mikhail cherkasov wrote:

Hi all,

Could you please review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8150076
webrev:
http://cr.openjdk.java.net/~mcherkas/8150076/webrev.00/

J2DPrinterJob waits when page printing is done, but doesn't check that
the whole job is done or that it is failed due error, as result we can
never quit from while cycle in method " implPrintPage".
The fix adds this checks.

Thanks,
Mikhail.

Re: What does this mean for the future of JavaFX on iOS?

[Felix Bembrick]

Well I did ask Johan what AOT they are going to use instead of RoboVM but there 
has not be a response yet.

Let's face it, without highly optimised AOT, Java and/or JavaFX on mobiles is 
simply not viable which in turn implies that JavaFX itself is not even worth 
looking at... RIP.

But I take Johan on his word that the demise of RoboVM will not negatively 
affect Gluon or its products and he has done absolutely amazing things 
throughout his career. So I am assuming he as a plan B.

I really wish Gluon somehow took complete ownership of the entire OpenJFX 
project as JavaFX could not be in safer hands.

> On 19 Apr 2016, at 17:43, Tobi  wrote:
> 
> Hi,
> 
> in my opinion the abandonment of RoboVM is a very big step back for Java on 
> Mobile because there is NO real alternative to RoboVM. So it has definitely a 
> big impact on Gluon and JavaFX on Mobile. Gluon uses RoboVM 1.8 - and old 
> version of RoboVM which will be not developed anymore. So no serious company 
> will decide to use a technology which is winding down! 
> 
> So ok, what could Gluon do now? Using OpenJDK9 for iOS and Android? Currently 
> definitely not! OpenJDK9 for Mobile is in an experimental state and uses the 
> Zero interpreter! So the performance will be not acceptable until the OpenJDK 
> 9 provides the same level of AOT like RoboVM - or even better! 
> 
> What can we do now to reach the goal to develop modern mobile applications 
> with Java - instead of with Xamarian…?
> 
> We need as soon as possible one or more companies to continue the development 
> of one of the RoboVM 1.8 forks (like BugVM) or merge the know how of RoboVM 
> with the current OpenJDK9 efforts… We need commitments of big companies to 
> Java like Oracle, Intel, IBM, SAP! We need the RoboVM team which breaks out 
> of Microsofts Xamarian world! In my dreams Niklas, Henric and their team take 
> the money of Xamarian and Microsoft and revive their baby „RoboVM“ in the 
> context of a fork based on open sourced RoboVM 1.8… Maybe with in a join 
> venture with Intel (concerning Intel’s Multi-OS engine)
> 
> What do you think about it guys? What are your plans Niklas…?
> 
> Best regards,
> Tobi
> 
> //
> follow me on twitter: https://twitter.com/tobibley 
> 
> 
> 
> 
> 
>> Am 18.04.2016 um 19:15 schrieb Johan Vos :
>> 
>> Indeed, this doesn't have any impact on JavaFX.
>> The Gluon tools are currently using the RoboVM AOT 1.8, which was the last
>> open-source version.
>> 
>> RoboVM delivered a whole set of products, including an AOT, but also a
>> system that provides some JNI functionality, a set of bindings that create
>> Java classes that have a 1-1 mapping to native iOS classes, and a whole
>> "Studio" allowing developers to create applications.
>> 
>> Only the AOT is relevant to us. We don't use the bindings, as we happen to
>> have a great set of UI classes: the JavaFX platform. We don't need the
>> studio, as we directly provide plugins for NetBeans, IntelliJ and Eclipse.
>> 
>> The idea of JavaFX is to deliver a cross-platform UI for all devices.
>> RoboVM took a different approach, as they mainly promoted creating an iOS
>> specific UI (using the Java bindings to the native iOS UI components) and
>> an Android specific UI.
>> 
>> We had different views on a cross-platform UI (JavaFX) versus a
>> platform-specific UI, but here is no doubt the RoboVM team consist of great
>> developers and it is a real pity and shame they won't be able to continue
>> working on their product.
>> 
>> But for JavaFX and Gluon, it doesn't make a difference.
>> 
>> - Johan
>> 
>> 
>>> On Mon, Apr 18, 2016 at 6:52 PM, Steve Hannah  wrote:
>>> 
>>> According to Gluon, they're not impacted by this.
>>> https://twitter.com/GluonHQ/status/721784161728471041
>>> 
>>> 
>>> 
>>> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick 
>>> wrote:
>>> 
 I just read this article which states that RoboVM is effectively
 "shutting down".
 
 https://www.voxxed.com/blog/2016/04/robovm/
 
 Given that they seem to be a critical part of the puzzle that is making
 JavaFX viable on mobile platforms, what does this actually mean for that
 goal?
 
 Is there an alternative technology or product that can fill this void? Or
 is the final nail in the coffin for JavaFX to ever be a truly viable cross
 platform technology?
 
 Thanks,
 
 Felix
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Steve Hannah
>>> Web Lite Solutions Corp.
> 

Re: What does this mean for the future of JavaFX on iOS?

[Tobi]

Hi,

in my opinion the abandonment of RoboVM is a very big step back for Java on 
Mobile because there is NO real alternative to RoboVM. So it has definitely a 
big impact on Gluon and JavaFX on Mobile. Gluon uses RoboVM 1.8 - and old 
version of RoboVM which will be not developed anymore. So no serious company 
will decide to use a technology which is winding down! 

So ok, what could Gluon do now? Using OpenJDK9 for iOS and Android? Currently 
definitely not! OpenJDK9 for Mobile is in an experimental state and uses the 
Zero interpreter! So the performance will be not acceptable until the OpenJDK 9 
provides the same level of AOT like RoboVM - or even better! 

What can we do now to reach the goal to develop modern mobile applications with 
Java - instead of with Xamarian…?

We need as soon as possible one or more companies to continue the development 
of one of the RoboVM 1.8 forks (like BugVM) or merge the know how of RoboVM 
with the current OpenJDK9 efforts… We need commitments of big companies to Java 
like Oracle, Intel, IBM, SAP! We need the RoboVM team which breaks out of 
Microsofts Xamarian world! In my dreams Niklas, Henric and their team take the 
money of Xamarian and Microsoft and revive their baby „RoboVM“ in the context 
of a fork based on open sourced RoboVM 1.8… Maybe with in a join venture with 
Intel (concerning Intel’s Multi-OS engine)

What do you think about it guys? What are your plans Niklas…?

Best regards,
Tobi

//
follow me on twitter: https://twitter.com/tobibley 





> Am 18.04.2016 um 19:15 schrieb Johan Vos :
> 
> Indeed, this doesn't have any impact on JavaFX.
> The Gluon tools are currently using the RoboVM AOT 1.8, which was the last
> open-source version.
> 
> RoboVM delivered a whole set of products, including an AOT, but also a
> system that provides some JNI functionality, a set of bindings that create
> Java classes that have a 1-1 mapping to native iOS classes, and a whole
> "Studio" allowing developers to create applications.
> 
> Only the AOT is relevant to us. We don't use the bindings, as we happen to
> have a great set of UI classes: the JavaFX platform. We don't need the
> studio, as we directly provide plugins for NetBeans, IntelliJ and Eclipse.
> 
> The idea of JavaFX is to deliver a cross-platform UI for all devices.
> RoboVM took a different approach, as they mainly promoted creating an iOS
> specific UI (using the Java bindings to the native iOS UI components) and
> an Android specific UI.
> 
> We had different views on a cross-platform UI (JavaFX) versus a
> platform-specific UI, but here is no doubt the RoboVM team consist of great
> developers and it is a real pity and shame they won't be able to continue
> working on their product.
> 
> But for JavaFX and Gluon, it doesn't make a difference.
> 
> - Johan
> 
> 
> On Mon, Apr 18, 2016 at 6:52 PM, Steve Hannah  wrote:
> 
>> According to Gluon, they're not impacted by this.
>> https://twitter.com/GluonHQ/status/721784161728471041
>> 
>> 
>> 
>> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick 
>> wrote:
>> 
>>> I just read this article which states that RoboVM is effectively
>>> "shutting down".
>>> 
>>> https://www.voxxed.com/blog/2016/04/robovm/
>>> 
>>> Given that they seem to be a critical part of the puzzle that is making
>>> JavaFX viable on mobile platforms, what does this actually mean for that
>>> goal?
>>> 
>>> Is there an alternative technology or product that can fill this void? Or
>>> is the final nail in the coffin for JavaFX to ever be a truly viable cross
>>> platform technology?
>>> 
>>> Thanks,
>>> 
>>> Felix
>> 
>> 
>> 
>> 
>> --
>> Steve Hannah
>> Web Lite Solutions Corp.
>>