From: Dell Green<dell.gr...@ideaworks.co.uk>
To: "openjfx-dev@openjdk.java.net"<openjfx-dev@openjdk.java.net>
Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11
Message-ID:<9d740561-a52c-42d7-bf3b-716a431aa...@ideaworks.co.uk>
Content-Type: text/plain; charset="utf-8"
Hi Guys,
Is it correct that ?libjavafx_font_freetype.so? be linked against X
libraries? as our embedded guys who are running without X were surprised to see
this as they are running without X using monocle and frame buffer platforms on
raspberry pi and MX6? Do we meet to install X11 if running in frame buffer
modes?
libjavafx_font_freetype.so:
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000)
libgtk-x11-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000)
libgdk-x11-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000)
libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0
(0xb6b00000)
libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0
(0xb69c0000)
libpangoft2-1.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000)
libpangocairo-1.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000)
libgdk_pixbuf-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000)
libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2
(0xb6890000)
libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0
(0xb6844000)
libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6
(0xb67b8000)
libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1
(0xb6780000)
libgobject-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000)
libgthread-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000)
libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0
(0xb6620000)
libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
(0xb6540000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0
(0xb6484000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000)
/lib/ld-linux-armhf.so.3 (0xb6f94000)
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000)
libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1
(0xb6234000)
libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1
(0xb6228000)
libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3
(0xb6218000)
libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6200000)
libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1
(0xb61f0000)
libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1
(0xb61e4000)
libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000)
libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2
(0xb61c0000)
libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1
(0xb61b0000)
libgmodule-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000)
libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1
(0xb6160000)
libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000)
libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0
(0xb60f4000)
libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000)
libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0
(0xb6040000)
libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0
(0xb6034000)
libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0
(0xb6024000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000)
libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000)
libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000)
libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000)
libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000)
libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000)
libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6
(0xb5f3c000)
libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1
(0xb5f2c000)
Dell Green
R&D Software Manager
t: (+44)203 668 9870
206 Great Portland Street
London W1W 5QJ
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you are not the intended recipient or the person responsible for delivering the
email to the intended recipient, be advised that you have received this email
in error and that any use, dissemination, forwarding, printing, or copying of
this email is strictly prohibited. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Ideaworks
Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W
5QJ. Company Registration No. 3943726
------------------------------
Message: 2
Date: Tue, 8 Dec 2015 12:03:10 -0500
From: Morris Meyer<morris.me...@oracle.com>
To: vadim.pakhnus...@oracle.com, Kevin Rushforth
<kevin.rushfo...@oracle.com>, "openjfx-dev@openjdk.java.net"
<openjfx-dev@openjdk.java.net>
Subject: [9] Review request for JDK-8144789: Incorrect assertion fails
in the GlassCursor.m
Message-ID:<56670d4e.6080...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Vadim and Kevin,
Please review this fix for the GlassCursor.m assertion failure.
Thanks,
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8144780.01a
BUG - https://bugs.openjdk.java.net/browse/JDK-8144780
------------------------------
Message: 3
Date: Tue, 08 Dec 2015 12:26:08 -0500
From: David Hill<david.h...@oracle.com>
To: openjfx-dev@openjdk.java.net
Subject: Re: OpenJFX armv6hf libjavafx_font_freetype.so x11
Message-ID:<566712b0.4020...@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 12/8/15, 9:25 AM, Dell Green wrote:
Hi Guys,
Is it correct that ?libjavafx_font_freetype.so? be linked against X
libraries? as our embedded guys who are running without X were surprised to see
this as they are running without X using monocle and frame buffer platforms on
raspberry pi and MX6? Do we meet to install X11 if running in frame buffer
modes?
This is a false dependency that appears to have crept back in, and I did not notice
because I have both X11 and framebuffer setup for testing. The pkg_config files for a
number of these libs we use pack a few extra libs to be "helpful"
This will take me a day or so to resolve. I filed
https://bugs.openjdk.java.net/browse/JDK-8144942 against it.
Dave
libjavafx_font_freetype.so:
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000)
libgtk-x11-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000)
libgdk-x11-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000)
libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0
(0xb6b00000)
libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0
(0xb69c0000)
libpangoft2-1.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000)
libpangocairo-1.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000)
libgdk_pixbuf-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000)
libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2
(0xb6890000)
libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0
(0xb6844000)
libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6
(0xb67b8000)
libfontconfig.so.1 =>
/usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb6780000)
libgobject-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000)
libgthread-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000)
libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0
(0xb6620000)
libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6
(0xb6614000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
(0xb6540000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0
(0xb6484000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000)
/lib/ld-linux-armhf.so.3 (0xb6f94000)
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000)
libXcomposite.so.1 =>
/usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000)
libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1
(0xb6228000)
libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3
(0xb6218000)
libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6
(0xb6200000)
libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1
(0xb61f0000)
libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1
(0xb61e4000)
libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000)
libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2
(0xb61c0000)
libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1
(0xb61b0000)
libgmodule-2.0.so.0 =>
/usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000)
libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1
(0xb6160000)
libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2
(0xb614c000)
libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0
(0xb60f4000)
libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000)
libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0
(0xb6040000)
libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0
(0xb6034000)
libxcb-render.so.0 =>
/usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000)
libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0
(0xb5ff4000)
libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000)
libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000)
libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000)
libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000)
libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6
(0xb5f3c000)
libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1
(0xb5f2c000)
Dell Green
R&D Software Manager
t: (+44)203 668 9870
206 Great Portland Street
London W1W 5QJ
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you are not the intended recipient or the person responsible for delivering the
email to the intended recipient, be advised that you have received this email
in error and that any use, dissemination, forwarding, printing, or copying of
this email is strictly prohibited. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Ideaworks
Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W
5QJ. Company Registration No. 3943726
--
David Hill<david.h...@oracle.com>
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
------------------------------
Message: 4
Date: Tue, 8 Dec 2015 18:37:45 +0100
From: Tom Schindl<tom.schi...@bestsolution.at>
To: Rahman USTA<rahman.usta...@gmail.com>,
"openjfx-dev@openjdk.java.net"<openjfx-dev@openjdk.java.net>
Subject: Re: Why there is no WebWorker like mechanism for JavaFX
Message-ID:<56671569.3050...@bestsolution.at>
Content-Type: text/plain; charset=windows-1252
Let's bring this back on the list - i once more accidentally replied
just to you.
IMHO if you want to execute javascript which is not related to a
browser/html you should run that in a javascript vm like nashorn, ...
and not through the WebView.
Tom
On 08.12.15 15:39, Rahman USTA wrote:
I handled the issue by using WebWorker in WebView, my main suggestion is
about JavaFX's threading model, not for a workaround.
I can try j2v8 if it supports Java Scripting API
Thanks.
2015-12-08 16:24 GMT+02:00 Tom Schindl<tom.schi...@bestsolution.at
<mailto:tom.schi...@bestsolution.at>>:
Use j2v8 - it is insanely fast as long as you don't do a lot
java->js->java calls which you don't
https://github.com/eclipsesource/j2v8
Tom
Von meinem iPhone gesendet
> Am 08.12.2015 um 14:17 schrieb Rahman USTA
<rahman.usta...@gmail.com<mailto:rahman.usta...@gmail.com>>:
>
> Yes your suggestion is OK in theory but in practice, Nashorn is
too slow
> without Warmup. I can say Nashorn is 5x to 10x slower than
embedded webkit
> to run script.
>
> 2015-12-08 15:09 GMT+02:00 Benjamin Gudehus<hasteb...@gmail.com
<mailto:hasteb...@gmail.com>>:
>
>> The JavaFX API offers Worker class for long running tasks.
>>
>> If you want to execute JavaScript code without DOM and JavaFX you
can use
>> the Nashorn JS Virtual machine, which is included in Java 8. I
guess the
>> Nashorn documentation also has examples how it's used with the Java
>> scripting API.
>>> On Dec 8, 2015 1:50 PM, "Rahman USTA"<rahman.usta...@gmail.com
<mailto:rahman.usta...@gmail.com>> wrote:
>>>
>>> I'm really enjoying developing apps in JavaFX, but I think there
is a
>>> limitation point;
>>>
>>> When we think HTML5, there is WebWorker to run long-running tasks in
>>> another process. So, we know WebWorker has no DOM access, it is
generally
>>> used computational needs.
>>>
>>> Ok, We can run long-running tasks in JavaFX with many threading
services,
>>> but there is one exception;
>>>
>>> There are a lot of JavaScript libraries, and executing them in
WebView
>>> needs JavaFX Application Thread. But, what if your JS code takes
long time
>>> to execute ? Your UI will hang. Is it required to execute JS code in
>>> WebView if it is not accessing DOM API?
>>>
>>> Thanks.
>>>
>>> --
>>> Rahman USTA
>>> Istanbul JUG
>>> https://github.com/rahmanusta<http://www.kodcu.com/>
>
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta<http://www.kodcu.com/>
--
Rahman USTA
Istanbul JUG
https://github.com/rahmanusta<http://www.kodcu.com/>
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
------------------------------
Message: 5
Date: Tue, 8 Dec 2015 20:54:52 +0100
From: Mike Hearn<m...@plan99.net>
To: Markus KARG<mar...@headcrashing.eu>
Cc: "openjfx-dev@openjdk.java.net"<openjfx-dev@openjdk.java.net>
Subject: Re: Future of JavaFX
Message-ID:
<CANEZrP0if=ter_N5ZC3z=qwNOdSLRSZh057S=_nm4+pmadl...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
I'm pretty surprised by this thread.
Guys, JavaFX is a widget toolkit. That's it, that's all it is. GUIs haven't
changed that much in their general design and capabilities for decades now,
probably the last major 'innovations' being things like the MS Office
Ribbon.
JFX has all the capabilities I'd hope for in a widget toolkit, plus a lot
more. As a bonus it's open source and cross platform, with a full time team
of developers. Just take a moment to appreciate that for a second! What's
the competition? Qt and that's about it, right?
Software can always be better, but this hysteria over "zomg oracle is
abandoning us!" doesn't seem justified. Even if all Oracle did from now on
was fix bugs and keep it working as the underlying platforms evolve, OK,
it's an open source library with people paid to fix bugs. That's still
better than many of the open source libraries I depend on!
But they aren't just fixing bugs, they're also making enhancements. Yes,
Java 9 is going to be boring because Jigsaw is forcing Team FX to go pay
off some technical debt by making previously private-but-used APIs public.
OK, fine, that amounts to new features for all 3 of you that weren't
cheating previously ;)
Beyond that, the fact that "draggable tabs" is the most user visible
feature planned says to me what I already felt - JavaFX is pretty mature.
It'd be nice if Scene Builder was being officially distributed again, and I
find the decision not do so baffling (perhaps they're assuming IDE makers
will take it off their hands), but the app is still out there and still
works. I suspect once the Jigsaw changes are finished off further
enhancements will be things like better performance, maybe some new
effects, etc. Nice to haves but not essentials.
IMO the biggest pain-point now isn't even GUI related stuff, it's the lack
of a modern replacement for Java Web Start. I made UpdateFX to try and fill
this hole but it's not as good as something that a skilled full time dev
with 6 months on hand would make.
On Sat, Dec 5, 2015 at 9:56 AM, Markus KARG<mar...@headcrashing.eu> wrote:
JavaFX support for multi-resolution images is really a killer feature, as
it simply is ridiculous how small images render on HiDPI that are scaled
for LowDPI.
For JDK 10, I'd kindly ask to review the list of essentials that I sent
you some months back by personal mail.
-Markus
-----Original Message-----
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf
Of Kevin Rushforth
Sent: Mittwoch, 2. Dezember 2015 01:29
To: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX
Just to chime in on a couple of points that have been raised in this
discussion...
* We are interested in working with the OpenJFX community to improve
JavaFX. In particular: if you find a bug, file it (via bugs.java.com if
you don't have a JBS account); if you want to contribute a patch to fix the
bug, we'd love to review it; if you have an idea for an improvement, file
it as an RFE (enhancement) and start up a thread on the mailing list.
Larger features need a JEP, but smaller improvements do not.
Please be aware that as part of the OpenJDK community, we are bound by the
processes of the OpenJDK, including the need for a signed OCA in order to
contribute, and before you can get a JBS account. If you are dissatisfied
with those processes and policies, then I invite you to discuss it on the
disc...@openjdk.java.net alias, and not here.
* While we aren't planning a huge number of features in JDK 9, we are
delivering some interesting improvements. Jigsaw is the big release driver
and most of our effort on JavaFX is to align with that. For those of you
who weren't at JavaOne, here is a list of things that are currently planned
for JDK 9:
- A modularized JavaFX (into 6 core modules + deploy, swing interop, swt
interop)
- JEP 253 -- Control Skins& additional CSS APIs (proper support for
third-party controls)
- High DPI enhancements (full support on Windows; add support for Linux)
- Public API for commonly used methods from internal packages:
* Nested Event Loop
* Pulse Listener
* Platform Startup
* Text API (HitTest, etc)
* Static utility functions (under investigation)
- New versions of WebKit and GStreamer
And here is an incomplete list of things we are thinking about for after
JDK 9, possibly in an update release. In fact, the recently proposed JDK
9 slip [1] makes it possible to consider pulling a few of them into JDK 9,
so let us know which ones you consider most important:
- Provide a JavaFX equivalent for JEP 272 / AWT ?Desktop? API
- Make UI Control Behaviors public
- UI Control Actions API
- Public Focus Traversal API
- JavaFX support for multi-resolution images
- Draggable tabs
- Image IO
-- Kevin
[1]
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html
End of openjfx-dev Digest, Vol 49, Issue 17
*******************************************
