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 >>> > -- 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
