I guess a good place to start would be to eliminate usage of private APIs
from scene builder.
Agreed. I noted the needed to fix SceneBuilder in a comment in
https://javafx-jira.kenai.com/browse/RT-40184 (wherein I said I would
file a new JIRA, but hadn't done that yet). Jonathan has already
generated the list of internal APIs from SceneBuilder, and can add it to
the new JIRA I just filed:
https://javafx-jira.kenai.com/browse/RT-40486
-- Kevin
Mike Hearn wrote:
I guess a good place to start would be to eliminate usage of private APIs
from scene builder. I understand that it doesn't seem to be supported any
more but it'd be extremely weird and embarrassing for Oracle if the UI
builder tool broke on Java 9 given all the work that went into it.
On 9 Apr 2015 9:54 am, "Jonathan Giles" <jonathan.gi...@oracle.com> wrote:
For what it is worth, investigations are underway in relation to UI
control skins and behaviors. It's too early for anything definitive to
announce, but it is not inconceivable that com.sun.javafx.scene.control.skin
may become javafx.scene.control.skin, more or less (with a lot of work
cleaning up, etc).
In terms of behaviors, some investigations are already underway in
RT-21598, but these too are only early, and fall under the bigger project
of getting UI controls and CSS APIs into a jigsaw-friendly form for JDK 9
(which is a huge undertaking, and community support will be useful and
sought at the appropriate time).
Thanks,
-- Jonathan
On 9/04/2015 5:39 p.m., Tom Schindl wrote:
Hi,
in SWT on JavaFX (most likely NOT a common useage of JavaFX):
-------------------------------------------------------------
I had to reside to private-API when it comes to:
* text calculations where there is no public API for things like
FontMetrics, TextLayout, ...
* For some of the direct drawing code I had to use com.sun.javafx.geom.*
* For some operations I had to access the com.sun.glass.ui.Robot &
com.sun.glass.ui.Application
* I had to get access to the VirtualFlow
To implement custom controls e.g. CodeEditor:
---------------------------------------------
* com.sun.javafx.scene.control.skin.BehaviorSkinBase
* com.sun.javafx.scene.control.behavior.KeyBinding
* com.sun.javafx.css.converters.InsetsConverter
* com.sun.javafx.css.converters.PaintConverter
* com.sun.javafx.scene.text.HitInfo
So to summerize the most lacking API is in the font/text rendering space
and to get public access to VirtualFlow would be a nice to have!
Tom
On 08.04.15 18:44, Phil Race wrote:
it's not strictly JFX-only.
Its not remotely FX only, in fact I could argue FX is not so affected,
as being relatively new it does not have 20 years of accumulation
of people using internal APIs that the larger JDK does, often dating from
when there were no suitable public APIs. There still remains some
of that with sun.misc.Unsafe as pointed out which will indeed be
inaccessible in modular mode. But the FX list isn't really the place
for that discussion. The jigsaw-dev is the appropriate list. FX
is simply bound by the rules that are set there.
There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
transition.
Also remember FX is open source. You can propose patches !
If there are specific APIs that are missing from FX that are suitable
to be *supported* public APIs then those could be considered here (this
list).
-phil.
On 4/8/2015 9:28 AM, Mike Hearn wrote:
sed -i 's/private/public/g' ;)
The whole notion of a strongly enforced private keyword is IMHO dumb
when
not using sandboxing. The number of gross hacks that occur in an
attempt to
work around overly strict enforcement of this stuff is crazy. The D
compiler has a special flag that disables visibility enforcement when
compiling unit tests, and that's a good idea, but why not go all the way
and just make accessing of private state a compiler warning a la
deprecated?
I also need to use private JFX APIs. I think any real JFX app does,
way too
much basic stuff relies on it. Heck, the number of popular Java
libraries
that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back
in
this regard then I will just write a simple tool that flips
private->public
either at the source level or via bytecode editing, and see what
happens :-)
On Wed, Apr 8, 2015 at 6:14 PM, Robert Krüger <krue...@lesspain.de>
wrote:
Hi,
I hope this is not too off-topic, because although it came up in a JFX
context it's not strictly JFX-only.
Someone from our team recently had a chat with a high-ranking regional
Oracle representative who gave a talk on the state of JFX. Our guy
explained our situation (evaluating JFX to migrate our swing-based
product,
feeling it's in principle the right technology but still having
show-stopping limitations like RT-36215) and the Oracle guy offered to
relay our concrete questions to the right people, which he did.
The answer we got contained one thing that really was a bit of a
shock and
I would like someone to either confirm this or clear up a
misunderstanding.
The statement was that private APIs will not be available in JDK 9
due to
modularity restrictions. If that is the case and we no longer have the
ability to build temporary workarounds using private APIs (which in our
case is controllable as we ship the JRE with our product), I would
probably
have to stop any development going into the direction of JFX as we will
probably have to use 9 at some point because many things now
scheduled for
9 will not get fixed in 8 and we will most likely still need
workarounds
using private API, at least that's what my current experience with JFX
tells me.
Please tell me that this was a misunderstanding (maybe meant for the
general case where one does not ship the JRE) or a non-engineering
source
that simply made mistake.
Best regards and thanks in advance,
Robert
