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