Re: Private APIs not usable in Java 9?
Right. The specific list of JavaFX internal packages is listed in the JIRA I filed, but if you just grep for 'com.sun' that will hit all of them. -- Kevin David DeHaven wrote: You can see any com.sun.* usage by running jdeps -v some.jar. You'll have to sort it all out manually, but it's all there. -DrD- I'll second the recommendation to run jdeps on your apps. I note that it doesn't currently flag internal FX packages as internal. I filed the following RFE to address this: https://bugs.openjdk.java.net/browse/JDK-8077349 -- Kevin Chris Newland wrote: I just asked about this on the adoption-disc...@openjdk.java.net list and the answer from Martijn Verburg is: --- Hi Chris, I think the strong advice for those using private APIs is to run the jdeps tool to see where they are using APIs that will go away / be moved. I'd then get them to post that list to jigsaw-dev, I guess the root cause of some of these issues should also be logged in JBS and fixed :-). Cheers, Martijn --- If you run $JAVA_HOME/bin/jdeps -jdkinternals class dir or jar then it will show all uses of JDK private APIs that will go away in JDK9. An example from one of my own projects: chris@chris:~$ /home/chris/jdk1.8.0_40/bin/jdeps -jdkinternals /home/chris/jitwatch/target/jitwatch-1.0.0-SNAPSHOT.jar jitwatch-1.0.0-SNAPSHOT.jar - /home/chris/jdk1.8.0_40/lib/tools.jar org.adoptopenjdk.jitwatch.loader.BytecodeLoader (jitwatch-1.0.0-SNAPSHOT.jar) - com.sun.tools.javap.JavapTask JDK internal API (tools.jar) - com.sun.tools.javap.JavapTask$BadArgs JDK internal API (tools.jar) Warning: JDK internal APIs are unsupported and private to JDK implementation that are subject to be removed or changed incompatibly and could break your application. Please modify your code to eliminate dependency on any JDK internal APIs. For the most recent update on JDK internal API replacements, please check: https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool I think sending these reports to jigsaw-...@openjdk.java.net is a worthwhile effort to help them direct resources for bug fixing and new public APIs. Cheers, Chris
Re: Private APIs not usable in Java 9?
On 08.04.2015 23:03, Stefan Fuchs wrote: Anyway I think especially for webstart applications, which have no control over the installed jre should have the possibility to access private apis. I would suggest reading http://openjdk.java.net/jeps/200 , http://openjdk.java.net/jeps/201 , http://openjdk.java.net/jeps/220 and then following the work of the JSR 376 expert group at http://openjdk.java.net/projects/jigsaw/spec/ , starting with http://openjdk.java.net/projects/jigsaw/spec/reqs/02 . As previously suggested, a better place to discuss general technical aspects of Project Jigsaw would be the jigsaw-dev mailing list. cheers, dalibor topic -- http://www.oracle.com Dalibor Topic | Principal Product Manager Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961 tel:+491737185961 ORACLE Deutschland B.V. Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment
Re: Private APIs not usable in Java 9? - behind the scene
Tom Schindl wrote:So to summerize the most lacking API is in the font/text rendering space What I find lacking too, coming from AWT/Swing, is some low-level (for JavaFX) features :- Something like WritableImage.getGraphicsContext() (as we have Image.getGraphics()).- Something like GraphicsContext.setXORMode(Color) (as we have Graphics.setXORMode(Color)) (for example for drawing a kind of cursor in a Canvas).- Easier reading of Canvas pixels. The only way I found to just read a pixel in a Canvas, is to call Canvas.snapshot(...) (which needs to be called in FX application thread) with parameters corresponding to that pixel, and then do getPixelReader().getArgb(0, 0) on the returned WritableImage. For simplicity of my code (minimalistic dependencies and cognitive load, easy-or-no bug),its adaptability (I might want to make it easy to do things JDK UI libraries have not been designed for),and its portability (I want it to run on top of AWT, JavaFX, OpenGL, or whatever widely supportedframework of the day), I don't want to commit myself to most of the JavaFX API, like the Scene Graphand Nodes, and just want to use Canvas, mouse/key events, and Stages and their events as windows,in some adaptation layer. There might be some minimalistic windowing frameworks etc. out there in C,but I like the write once run anywhere of Java so I try to stick to it for now. What I'm looking for surely exists behind the scene (accidental pun),but dispatched over internal layers (Glass, Quantum, etc.), and not regrouped into a consistent public API. -Jeff
Re: Private APIs not usable in Java 9?
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
Re: Private APIs not usable in Java 9?
You can see any com.sun.* usage by running jdeps -v some.jar. You'll have to sort it all out manually, but it's all there. -DrD- I'll second the recommendation to run jdeps on your apps. I note that it doesn't currently flag internal FX packages as internal. I filed the following RFE to address this: https://bugs.openjdk.java.net/browse/JDK-8077349 -- Kevin Chris Newland wrote: I just asked about this on the adoption-disc...@openjdk.java.net list and the answer from Martijn Verburg is: --- Hi Chris, I think the strong advice for those using private APIs is to run the jdeps tool to see where they are using APIs that will go away / be moved. I'd then get them to post that list to jigsaw-dev, I guess the root cause of some of these issues should also be logged in JBS and fixed :-). Cheers, Martijn --- If you run $JAVA_HOME/bin/jdeps -jdkinternals class dir or jar then it will show all uses of JDK private APIs that will go away in JDK9. An example from one of my own projects: chris@chris:~$ /home/chris/jdk1.8.0_40/bin/jdeps -jdkinternals /home/chris/jitwatch/target/jitwatch-1.0.0-SNAPSHOT.jar jitwatch-1.0.0-SNAPSHOT.jar - /home/chris/jdk1.8.0_40/lib/tools.jar org.adoptopenjdk.jitwatch.loader.BytecodeLoader (jitwatch-1.0.0-SNAPSHOT.jar) - com.sun.tools.javap.JavapTask JDK internal API (tools.jar) - com.sun.tools.javap.JavapTask$BadArgs JDK internal API (tools.jar) Warning: JDK internal APIs are unsupported and private to JDK implementation that are subject to be removed or changed incompatibly and could break your application. Please modify your code to eliminate dependency on any JDK internal APIs. For the most recent update on JDK internal API replacements, please check: https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool I think sending these reports to jigsaw-...@openjdk.java.net is a worthwhile effort to help them direct resources for bug fixing and new public APIs. Cheers, Chris
Re: Private APIs not usable in Java 9?
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
Re: Private APIs not usable in Java 9?
I'll second the recommendation to run jdeps on your apps. I note that it doesn't currently flag internal FX packages as internal. I filed the following RFE to address this: https://bugs.openjdk.java.net/browse/JDK-8077349 -- Kevin Chris Newland wrote: I just asked about this on the adoption-disc...@openjdk.java.net list and the answer from Martijn Verburg is: --- Hi Chris, I think the strong advice for those using private APIs is to run the jdeps tool to see where they are using APIs that will go away / be moved. I'd then get them to post that list to jigsaw-dev, I guess the root cause of some of these issues should also be logged in JBS and fixed :-). Cheers, Martijn --- If you run $JAVA_HOME/bin/jdeps -jdkinternals class dir or jar then it will show all uses of JDK private APIs that will go away in JDK9. An example from one of my own projects: chris@chris:~$ /home/chris/jdk1.8.0_40/bin/jdeps -jdkinternals /home/chris/jitwatch/target/jitwatch-1.0.0-SNAPSHOT.jar jitwatch-1.0.0-SNAPSHOT.jar - /home/chris/jdk1.8.0_40/lib/tools.jar org.adoptopenjdk.jitwatch.loader.BytecodeLoader (jitwatch-1.0.0-SNAPSHOT.jar) - com.sun.tools.javap.JavapTask JDK internal API (tools.jar) - com.sun.tools.javap.JavapTask$BadArgs JDK internal API (tools.jar) Warning: JDK internal APIs are unsupported and private to JDK implementation that are subject to be removed or changed incompatibly and could break your application. Please modify your code to eliminate dependency on any JDK internal APIs. For the most recent update on JDK internal API replacements, please check: https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool I think sending these reports to jigsaw-...@openjdk.java.net is a worthwhile effort to help them direct resources for bug fixing and new public APIs. Cheers, Chris
Re: Private APIs not usable in Java 9?
On Wed, Apr 8, 2015 at 11:03 PM, Stefan Fuchs snfu...@gmx.de wrote: But in all artificial restrictions to implement your own workarounds using private apis its another minus on our assessment of the risks involved, when investing in the javafx technology. Others are the diminishing plugin support by browser vendors and a lack of commitment from oracle for growing platforms like android or ios. On the other side of the equation is unrestricted access of the application to the local filesystem and cpu resources and the rich java apis. Currently the equation still holds in favor of javafx, but is constantly evaluated. *Exactly* the same situation here. I have been arguing against colleagues proposing an approach where we keep the non-UI code Java and make the UI using the native technologies similar to what robovm does for iOS APIs which works remarkably well but of course has its drawbacks compared to largely sharing the UI code across platforms but other obvious advantages. With each of these decisions making it harder to somehow get through the very long phase of JFX maturing, my case for porting to JFX falls apart more and more.
Re: Private APIs not usable in Java 9?
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
Re: Private APIs not usable in Java 9? - behind the scene
[Re-sending with more line breaks (hopefully - looked fine when sent but most were gone when I received it)] Tom Schindl wrote:So to summerize the most lacking API is in the font/text rendering space What I find lacking too, coming from AWT/Swing, is some low-level (for JavaFX) features : - Something like WritableImage.getGraphicsContext() (as we have Image.getGraphics()). - Something like GraphicsContext.setXORMode(Color) (as we have Graphics.setXORMode(Color)) (for example for drawing a kind of cursor in a Canvas). - Easier reading of Canvas pixels. The only way I found to just read a pixel in a Canvas, is to call Canvas.snapshot(...) (which needs to be called in FX application thread) with parameters corresponding to that pixel, and then do getPixelReader().getArgb(0, 0) on the returned WritableImage. For simplicity of my code (minimalistic dependencies and cognitive load, easy-or-no bug),its adaptability (I might want to make it easy to do things JDK UI libraries have not been designed for),and its portability (I want it to run on top of AWT, JavaFX, OpenGL, or whatever widely supportedframework of the day), I don't want to commit myself to most of the JavaFX API, like the Scene Graphand Nodes, and just want to use Canvas, mouse/key events, and Stages and their events as windows,in some adaptation layer. There might be some minimalistic windowing frameworks etc. out there in C,but I like the write once run anywhere of Java so I try to stick to it for now. What I'm looking for surely exists behind the scene (accidental pun),but dispatched over internal layers (Glass, Quantum, etc.),and not regrouped into a consistent public API. -Jeff
Re: Private APIs not usable in Java 9?
I' ll try to compile a list of the private apis we currently use in our application and why. Looking forward to using only public apis in java 9 then :-) - Stefan On Apr 8, 2015, at 1:52 PM, Robert Krüger krue...@lesspain.de wrote: our only workaround is to use private API For the benefit of the devs on the list, could you please point out what private APIs you currently need to use? That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems.
Re: Private APIs not usable in Java 9?
Hi, and one more thing, I don't care about Unsafe. It can die unless it is involved in a workaround for the StringIndexOutOfBoundsException in CertUtils.checkWildcardDomain we currently see in java 8u60-ea when opening an https connection to our servers. Hopefully this can be fixed till the final release. But in all artificial restrictions to implement your own workarounds using private apis its another minus on our assessment of the risks involved, when investing in the javafx technology. Others are the diminishing plugin support by browser vendors and a lack of commitment from oracle for growing platforms like android or ios. On the other side of the equation is unrestricted access of the application to the local filesystem and cpu resources and the rich java apis. Currently the equation still holds in favor of javafx, but is constantly evaluated. And as you can see at http://easyprint.com we currently use different technologies for the online editors of our print products. Still adobe flash for the simple products (Print products and Textile products) and an new JavaFX based editor in the same design as the flash editor for the more complex photo products. So an html5 editor could certainly become the successor of the javafx editor. Anyway I think especially for webstart applications, which have no control over the installed jre should have the possibility to access private apis. If a installed application can do it, why shouldn't the same be possible for a webstart application? evil grin Or perhaps, as it has full access to the filesystem, my application could start patching class files in the installed jre /evil grin No, I don't think that would be a good idea. - Stefan Hi, you are right, there are still years to the end of public updates to JDK 8 We can use them to migrate to other technologies. - Stefan Making any theoretical flag available to the deployment side would entirely miss the point. Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _*/now/*_. It is still years until the end of public updates to JDK 8, so we have /*years */to work this out properly. But sticking our heads in the collective sands and hoping for trivial work arounds to Unsafe is not going to work. If you're using Unsafe, this is the year to explain where the API is broken and get it straight Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone. - Don On 08/04/2015 2:56 PM, Stefan Fuchs wrote: Hi, then I can only hope, that this flag is available to webstart applications. Webstart applications have no control over the installed jre. In the past we encountered various bugs in the jre, which required using internal apis for workarounds. For example in some releases of Java 7 the swing gui thread did not start unless hacking internal apis (see https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an error occurs again in the future and we are no longer able to hack around the problem, our only choice to keep our business alive, is to discourage users from upgrading to newer versions of the jre, exposing them to security risks. - Stefan 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
Re: Private APIs not usable in Java 9?
On Wed, Apr 8, 2015 at 9:59 PM, Tomas Mikula tomas.mik...@gmail.com wrote: Should I rely now on all of those fixes to be backported to 8? Why do you need them to be backported to 8? Just having them fixed in 9 should be fine, no? (keeping the private workarounds for 8) It was a response to the point that I could live with Java 8 for a few more years if I needed private workarounds. Of course, in theory, if all of them get fixed in 9 I am fine, but if there is a period of time where half of them are fixed in 9 and the other half can only be worked around on 8, what do I do with my product?
Re: Private APIs not usable in Java 9?
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
Re: Private APIs not usable in Java 9?
For the benefit of the devs on the list, could you please point out what private APIs you currently need to use? That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems. e.g. handling a double click of a file on MacOS is impossible without using private APIs currently. I think a bug is filed already, but I don't know the number. Learning if you're on the software pipeline or GL/D3D pipelines also requires internal APIs. This is useful for winding back animations on hardware/pipelines that can't take it. Finding the current pixel scale of the screen, same. I don't know if it counts but I find myself relying on or overriding undocumented rules in modena.css somewhat frequently. For example the edge-to-edge rule for ScrollPane. Of course, jigsaw will not break that. I think AquaFX has to use internal APIs in various places though I don't remember why. Those are the examples from my (quite small) app.
Re: Private APIs not usable in Java 9?
- Getting access to the native window to let our video player render into a JFX screen, to have a video player with features and format support that can compete with other players on the market (RT-36215), basically following the example of Steve and Felipe's JavaOne presentation Integrating JavaFX with Native Technologies - Getting access to the currently displayed table rows by hacking into the skin, because not being able to do so, would significantly degrade the UX of our application (RT-39917). This will probably happen for other controls (list, tree) in the future, when we dive in deeper because, as I understand it, they share the same limitation. Those two definitely so far but we have only started evaluating the porting process and haven't had the time to check if things like RT-37372, RT-37501, RT-40409 or RT-40379 can be worked around by using private APIs, still hoping some of that will be fixed before we need to do something about it ourselves. On Wed, Apr 8, 2015 at 10:05 PM, Danno Ferrin danno.fer...@oracle.com wrote: On Apr 8, 2015, at 1:52 PM, Robert Krüger krue...@lesspain.de wrote: our only workaround is to use private API For the benefit of the devs on the list, could you please point out what private APIs you currently need to use? That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems. -- Robert Krüger Managing Partner Lesspain GmbH Co. KG www.lesspain-software.com
Re: Private APIs not usable in Java 9?
Hi Robert, No, this is not a misunderstanding. There will be no access to any classes in non-public packages in JDK 9 by applications for exactly the reasons the region rep mentioned. For JavaFX this means that no com.sun.javafx (or similar) packages will be accessible by applications in JDK 9. I note that this is not limited to JavaFX. It has already been discussed on the awt list, for example (the java.awt.peer package will not be exported). And you won't be able to use sun.* classes or internal classes on Swing, etc. Note that if you build your own JDK with FX you will be able to modify classes for your own use to workaround problems, but you will no longer be able to simply call into com.sun.javafx.SomeClass for a workaround. There is a good possibility that the JDK will provide a -XX compatibliity switch to relax module boundaries (when there is no security manager present) in JDK 9 to ease the pain of transition, but that will be a temporary stop-gap not a long-term solution. -- Kevin Robert Krüger 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
Re: Private APIs not usable in Java 9?
If there are FX APIs that are currently private that folks think should be public, or that are currently necessary to implement a work-around for another bug, please make sure there is a Jira issue filed for this. We’ll try to address this for JDK 9 to mitigate this, but everyone should understand that as part of Jigsaw it’s expected that ALL private APIs will become unavailable in Java. http://www.oracle.com/commitment http://www.oracle.com/commitment On Apr 8, 2015, at 9:28 AM, Mike Hearn m...@plan99.net 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
Re: Private APIs not usable in Java 9?
OK, while I wrote this, all the other replies came in. So I see that your recommendation for the cases I mentioned is then to patch OpenJDK and submit Jira issues. Fair enough. Regarding Jira issues, we are already doing that. Regarding code contribution, this is a different thing, because in many cases a hack to expose something that should be there is quick but designing a consistent API that exposes the missing things is often something that requires a different qualification.
Re: Private APIs not usable in Java 9?
My concern is that issues with existing workarounds were given lower priority. Now many workarounds will disappear, but I'm worried that the priorities will not be reconsidered. I think part of the problem is the fact that Java does not have a good way of marking an API as experimental. Anything public can never change, so JDK developers don't make things public if they are not quite happy with the API yet, even though some bits would be useful for others. As a consequence, they get no or very little feedback on a private API, thus slowing the progress towards the non-experimental API even more. Sure, experimental functionality could still be dropped at any time, but that is not happening here. The functionality remains, it is just going to be hidden. Robert makes a good point that designing a stable API for something that is currently private and possibly ugly is much more work than pulling ad-hoc hacks with the experimental API. I believe Jira issues are mostly there, I'm just skeptical that all of the issues currently targeted for 9 will actually be resolved in 9. On Wed, Apr 8, 2015 at 1:23 PM, Robert Krüger krue...@lesspain.de wrote: OK, while I wrote this, all the other replies came in. So I see that your recommendation for the cases I mentioned is then to patch OpenJDK and submit Jira issues. Fair enough. Regarding Jira issues, we are already doing that. Regarding code contribution, this is a different thing, because in many cases a hack to expose something that should be there is quick but designing a consistent API that exposes the missing things is often something that requires a different qualification.
Re: Private APIs not usable in Java 9?
I think that Oracle people are right. It's more a JDK 9 or jigsaw issue than a JavaFX issue. Sent from my iPhone On Apr 8, 2015, at 20:22, Tomas Mikula tomas.mik...@gmail.com wrote: My concern is that issues with existing workarounds were given lower priority. Now many workarounds will disappear, but I'm worried that the priorities will not be reconsidered. I think part of the problem is the fact that Java does not have a good way of marking an API as experimental. Anything public can never change, so JDK developers don't make things public if they are not quite happy with the API yet, even though some bits would be useful for others. As a consequence, they get no or very little feedback on a private API, thus slowing the progress towards the non-experimental API even more. Sure, experimental functionality could still be dropped at any time, but that is not happening here. The functionality remains, it is just going to be hidden. Robert makes a good point that designing a stable API for something that is currently private and possibly ugly is much more work than pulling ad-hoc hacks with the experimental API. I believe Jira issues are mostly there, I'm just skeptical that all of the issues currently targeted for 9 will actually be resolved in 9. On Wed, Apr 8, 2015 at 1:23 PM, Robert Krüger krue...@lesspain.de wrote: OK, while I wrote this, all the other replies came in. So I see that your recommendation for the cases I mentioned is then to patch OpenJDK and submit Jira issues. Fair enough. Regarding Jira issues, we are already doing that. Regarding code contribution, this is a different thing, because in many cases a hack to expose something that should be there is quick but designing a consistent API that exposes the missing things is often something that requires a different qualification.
Re: Private APIs not usable in Java 9?
Hi, then I can only hope, that this flag is available to webstart applications. Webstart applications have no control over the installed jre. In the past we encountered various bugs in the jre, which required using internal apis for workarounds. For example in some releases of Java 7 the swing gui thread did not start unless hacking internal apis (see https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an error occurs again in the future and we are no longer able to hack around the problem, our only choice to keep our business alive, is to discourage users from upgrading to newer versions of the jre, exposing them to security risks. - Stefan 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
Re: Private APIs not usable in Java 9?
Making any theoretical flag available to the deployment side would entirely miss the point. Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _*/now/*_. It is still years until the end of public updates to JDK 8, so we have /*years */to work this out properly. But sticking our heads in the collective sands and hoping for trivial work arounds to Unsafe is not going to work. If you're using Unsafe, this is the year to explain where the API is broken and get it straight Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone. - Don On 08/04/2015 2:56 PM, Stefan Fuchs wrote: Hi, then I can only hope, that this flag is available to webstart applications. Webstart applications have no control over the installed jre. In the past we encountered various bugs in the jre, which required using internal apis for workarounds. For example in some releases of Java 7 the swing gui thread did not start unless hacking internal apis (see https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an error occurs again in the future and we are no longer able to hack around the problem, our only choice to keep our business alive, is to discourage users from upgrading to newer versions of the jre, exposing them to security risks. - Stefan 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
Re: Private APIs not usable in Java 9?
Hi, you are right, there are still years to the end of public updates to JDK 8 We can use them to migrate to other technologies. - Stefan Making any theoretical flag available to the deployment side would entirely miss the point. Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _*/now/*_. It is still years until the end of public updates to JDK 8, so we have /*years */to work this out properly. But sticking our heads in the collective sands and hoping for trivial work arounds to Unsafe is not going to work. If you're using Unsafe, this is the year to explain where the API is broken and get it straight Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone. - Don On 08/04/2015 2:56 PM, Stefan Fuchs wrote: Hi, then I can only hope, that this flag is available to webstart applications. Webstart applications have no control over the installed jre. In the past we encountered various bugs in the jre, which required using internal apis for workarounds. For example in some releases of Java 7 the swing gui thread did not start unless hacking internal apis (see https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an error occurs again in the future and we are no longer able to hack around the problem, our only choice to keep our business alive, is to discourage users from upgrading to newer versions of the jre, exposing them to security risks. - Stefan 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
Re: Private APIs not usable in Java 9?
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
Re: Private APIs not usable in Java 9?
exactly. I don't give a about Unsafe but I have to deal with the realities of Java(FX) in its current state and as long as bugs or limitations that simply make it impossible to ship a product that can compete with others in our market sit there for months or years and our only workaround is to use private API and that is taken away then we only have the choice to move to another technology, which we do not really want to do. Luckily we are in a better position than Stefan still being able to modify the JRE in those emergencies but I absolutely see his point. Your point about Java 8 being available for a long time is moot in a JFX context as we all know that JFX is very much in motion and needs to be, because it is far from mature. _All_ of my 6 open issues in Jira plus some others I am watching because we have run tinto them as well haven been scheduled for Java 9. _All_ of them are either serious problems or even showstoppers for products of ours. Should I rely now on all of those fixes to be backported to 8? On Wed, Apr 8, 2015 at 9:21 PM, Stefan Fuchs snfu...@gmx.de wrote: Hi, you are right, there are still years to the end of public updates to JDK 8 We can use them to migrate to other technologies. - Stefan Making any theoretical flag available to the deployment side would entirely miss the point. Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _*/now/*_. It is still years until the end of public updates to JDK 8, so we have /*years */to work this out properly. But sticking our heads in the collective sands and hoping for trivial work arounds to Unsafe is not going to work. If you're using Unsafe, this is the year to explain where the API is broken and get it straight Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone. - Don On 08/04/2015 2:56 PM, Stefan Fuchs wrote: Hi, then I can only hope, that this flag is available to webstart applications. Webstart applications have no control over the installed jre. In the past we encountered various bugs in the jre, which required using internal apis for workarounds. For example in some releases of Java 7 the swing gui thread did not start unless hacking internal apis (see https://javafx-jira.kenai.com/ browse/RT-31205 for details). If such an error occurs again in the future and we are no longer able to hack around the problem, our only choice to keep our business alive, is to discourage users from upgrading to newer versions of the jre, exposing them to security risks. - Stefan 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
Re: Private APIs not usable in Java 9?
I do believe in making things right (like killing Unsafe, hiding private APIs). The transition will just be so much pain now that there is so much accumulated private APIs used in production. If there were no accessible private APIs to start with, there would be more pressure to fix bugs and expose functionality in public APIs. And no, in practice, there are not /*years*/ to transition. In practice, projects have dependencies. If I decide to move on to 9, but my dependency has not been ported yet, I have a problem. If I'm still stuck with 8, but my dependency has moved on to 9 and stopped backporting bugfixes and new features to 8 (which would be understandable, because it is quite a bit of maintanence cost to maintain two codebases), then I have a problem. Anyway, the transition is inevitable and good in the long term. I will just be happy if Oracle manages to flesh out their experimental private APIs that people are already using today, but I am somewhat skeptical that this will happen for JavaFX before 9, thus resulting in a period of temporarily lost functionality. Tomas On Wed, Apr 8, 2015 at 3:15 PM, Donald Smith donald.sm...@oracle.com wrote: Making any theoretical flag available to the deployment side would entirely miss the point. Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _*/now/*_. It is still years until the end of public updates to JDK 8, so we have /*years */to work this out properly. But sticking our heads in the collective sands and hoping for trivial work arounds to Unsafe is not going to work. If you're using Unsafe, this is the year to explain where the API is broken and get it straight Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone. - Don On 08/04/2015 2:56 PM, Stefan Fuchs wrote: Hi, then I can only hope, that this flag is available to webstart applications. Webstart applications have no control over the installed jre. In the past we encountered various bugs in the jre, which required using internal apis for workarounds. For example in some releases of Java 7 the swing gui thread did not start unless hacking internal apis (see https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an error occurs again in the future and we are no longer able to hack around the problem, our only choice to keep our business alive, is to discourage users from upgrading to newer versions of the jre, exposing them to security risks. - Stefan 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
Re: Private APIs not usable in Java 9?
Should I rely now on all of those fixes to be backported to 8? Why do you need them to be backported to 8? Just having them fixed in 9 should be fine, no? (keeping the private workarounds for 8) T.
Re: Private APIs not usable in Java 9?
On Apr 8, 2015, at 1:52 PM, Robert Krüger krue...@lesspain.de wrote: our only workaround is to use private API For the benefit of the devs on the list, could you please point out what private APIs you currently need to use? That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems.
Re: Private APIs not usable in Java 9?
Just adding to the comment that a specific user has the issue will help, especially when it comes to validating the fix. On Apr 8, 2015, at 2:24 PM, Hervé Girod herve.gi...@gmail.com wrote: Do you need a specific classification for such JIRAs? Sent from my iPhone On Apr 8, 2015, at 22:05, Danno Ferrin danno.fer...@oracle.com wrote: On Apr 8, 2015, at 1:52 PM, Robert Krüger krue...@lesspain.de wrote: our only workaround is to use private API For the benefit of the devs on the list, could you please point out what private APIs you currently need to use? That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems.
Re: Private APIs not usable in Java 9?
Do you need a specific classification for such JIRAs? Sent from my iPhone On Apr 8, 2015, at 22:05, Danno Ferrin danno.fer...@oracle.com wrote: On Apr 8, 2015, at 1:52 PM, Robert Krüger krue...@lesspain.de wrote: our only workaround is to use private API For the benefit of the devs on the list, could you please point out what private APIs you currently need to use? That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems.
