Re: [External] : Re: Dependencies on java.desktop
Did someone mention my name ? Implementing FX printing on top of 2D printing was always a pragmatic way of delivering in FX 8. Never something that was done because we wanted to for any reason. A new native implementation will still cost the same amount of work that we put off in JDK 8. So it needs to be prioritised. But note that I think it can be done one platform at a time. So if we did a Windows print implementation javafx.graphics might no longer require it on Windows (at least for printing) but would still need it on macOS. This is the right long term answer rather than @ConditionalFeature. -phil. On 5/18/21 2:40 PM, Kevin Rushforth wrote: As noted in the thread you quoted below, removing the dependency on java.desktop from javafx.base isn't a particularly hard problem, and is tracked by JDK-8240844 [1]. And even though it will require a spec change (meaning a CSR), it doesn't result in any loss of functionality, since in order to usefully do anything with the JavaBeanX classes requires java.desktop anyway. Removing the dependency on java.desktop from javafx.graphics is a larger issue because of printing. There is also an implementation dependency on the Desktop class to implement HostServices::showDocument that would need to be redone. And of course it depends on the above (eliminating the dependency from javafx.base) being done first. For printing we would need to do one of two things: 1. Eliminate the implementation dependency on the Java2D printing code. This is a large effort, but would preserve existing functionality. 2. Make the JavaFX Printing function "optional" (i.e., make it a "ConditionalFeature"), such that if java.desktop is not present, printing doesn't work (all of the printing APIs would throw an UnsupportedOperationException if java.desktop is not available). An application that wants to do printing would need to include java.desktop. Option 1 would be my preferred approach, but as mentioned above it's a lot of work. Option 2 would need a spec change, and I'm not convinced we want to do it. If there are enough other developers who would want this, we could open it up for discussion for some future version (not JavaFX 17). Phil might have some thoughts on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8240844 On 5/18/2021 10:45 AM, Tom Schindl wrote: Uff - I'd like to revisit this topic. As I did some jlink stuff for our applications adding java.desktop once more bugged me. I guess the first thing to do is to file a JIRA-Ticket but it really starts to bug me to include java.desktop although I don't plan to use printing (and I guess > 90% of the JavaFX don't use the printing API either but produce PDFs or whatever) and Java-Beans. Tom Am 27.03.18 um 14:26 schrieb Kevin Rushforth: Hi Tom, Yes, this is an unfortunate dependency. It is "only" an implementation dependency, meaning that nothing in the public API depends on java.desktop (which is why we don't "requires transient java.desktop"), so it should be possible to remove this dependency in the future. As noted, it is only there because Java Beans is part of the java.desktop module. In the interim, your suggestion of "requires static java.base" could be the way to go. It would need a spec change to the JavaFX beans adapter classes documenting that they would throw an UnsupportedOperationException if java.desktop was not present at runtime, along with a recommendation that applications needing that functionality should add "requires java.desktop" to their own module-info.java. Note that this would only help non-graphical JavaFX applications that use javafx.base for its collections, properties, and bindings, since javafx.graphics requires java.desktop in a way that currently cannot easily be made optional (not without reimplementing printing support anyway). -- Kevin Tom Schindl wrote: Hi, Anyone else has an opinion on that? Is require static the way to go? Tom On 21.03.18 23:23, Tom Schindl wrote: Hi, I always thought the JavaFX-Codebase should be able to run with just the java.base module but I was browsing the codebase a bit and was suprised (or rather shocked) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom
Re: [External] : Re: Dependencies on java.desktop
That's an interesting idea, although splitting it up to the degree you listed below would be unwieldy at best and likely unworkable (due to split package issues and interdependencies). It also would be wrong to create any implementation modules unless they are 100% hidden from the application developer. If any of them would (or even could) ever show up in a developer's .pom, .xml, or .gradle file, then it would be a non-starter since that would amount to leaking implementation details. Irrespective of how the graphics module might be broken up, I suspect that splitting any of our existing modules might run into compatibility problems in the maven.central deployment case, unless gradle and maven have completely solved the module dependencies properly such that application can specify, for example, javafx.controls and have it automatically pull in all of the other javafx dependencies. Leaving that last point aside, I can see how splitting it up into just two modules *might* be workable with a bit of refactoring: javafx.graphics --> depends on javafx.graphics.* (requires transitive) javafx.graphics.core (includes all of the public API except printing, and all of the implementation except printing + j2d pipeline) javafx.graphics.printing --> depends on javafx.graphics.core, java.desktop (includes printing api, printing impl, j2d pipeline) An application that doesn't need printing could depend on javafx.graphics.core. Of course, that leaves out UI controls-based applications, since javafx.controls "requires transitive" javafx.graphics. So you'd have to split that one too, and possibly javafx.fxml, in order to really get any benefit from this. Anyway, I'm not really in favor of this approach, just pointing out a less radical idea that we could at least discuss further as a possibility. I still think making printing optional might be a feasible alternative to reimplementing it natively (which isn't as odd an idea as it might seem initially, since embedded / mobile systems don't typically have a printer). If so, a better approach to throwing an exception would probably be to just to report no printers if the Java2D library (the java.desktop module) isn't available. Need to think about this one some more. > Out of curiosity I tried that locally and it just works ;-) I'm sure it depends on your definition of "just works". If you mean taking the class files after the fact and cobbling together some modules from the built class files and running something, then maybe, although even then I don't see how it could work seamlessly. -- Kevin On 5/19/2021 10:20 AM, Tom Schindl wrote: Hi, Well I looked a bit closer now and the situation and you are right. I think need to do that one by one. I think getting rid of HostServices::showDocument is quite easy as the code in Java-AWT is just 1 JNI-Method so copying that to OpenJFX should be fairly easy. Now on the printing story which is the real problem a fairly radical approach would be to split up javafx.graphics into multiple modules and make javafx.graphics a META-Module who provides the backward compat using "requires transitive". We would end up with: * javafx.graphics * javafx.graphics.base * javafx.graphics.print * javafx.graphics.prism.base * javafx.graphics.prism.j2d * javafx.graphics.prism.es2 * javafx.graphics.prism.d3d * javafx.graphics.glass.base * javafx.graphics.glass.win32 * javafx.graphics.glass.mac * ... I know that sounds radical but from a pure architectual point of view this would be better than optional features in javafx.graphics and would not require us to reimplement printing to get rid of java.desktop. Out of curiosity I tried that locally and it just works ;-) Tom Am 18.05.21 um 23:40 schrieb Kevin Rushforth: As noted in the thread you quoted below, removing the dependency on java.desktop from javafx.base isn't a particularly hard problem, and is tracked by JDK-8240844 [1]. And even though it will require a spec change (meaning a CSR), it doesn't result in any loss of functionality, since in order to usefully do anything with the JavaBeanX classes requires java.desktop anyway. Removing the dependency on java.desktop from javafx.graphics is a larger issue because of printing. There is also an implementation dependency on the Desktop class to implement HostServices::showDocument that would need to be redone. And of course it depends on the above (eliminating the dependency from javafx.base) being done first. For printing we would need to do one of two things: 1. Eliminate the implementation dependency on the Java2D printing code. This is a large effort, but would preserve existing functionality. 2. Make the JavaFX Printing function "optional" (i.e., make it a "ConditionalFeature"), such that if java.desktop is not present, printing doesn't work (all of the printing APIs would throw an UnsupportedOperationException if java.desktop is not
Re: [External] : Re: Dependencies on java.desktop
Hi, Well I looked a bit closer now and the situation and you are right. I think need to do that one by one. I think getting rid of HostServices::showDocument is quite easy as the code in Java-AWT is just 1 JNI-Method so copying that to OpenJFX should be fairly easy. Now on the printing story which is the real problem a fairly radical approach would be to split up javafx.graphics into multiple modules and make javafx.graphics a META-Module who provides the backward compat using "requires transitive". We would end up with: * javafx.graphics * javafx.graphics.base * javafx.graphics.print * javafx.graphics.prism.base * javafx.graphics.prism.j2d * javafx.graphics.prism.es2 * javafx.graphics.prism.d3d * javafx.graphics.glass.base * javafx.graphics.glass.win32 * javafx.graphics.glass.mac * ... I know that sounds radical but from a pure architectual point of view this would be better than optional features in javafx.graphics and would not require us to reimplement printing to get rid of java.desktop. Out of curiosity I tried that locally and it just works ;-) Tom Am 18.05.21 um 23:40 schrieb Kevin Rushforth: As noted in the thread you quoted below, removing the dependency on java.desktop from javafx.base isn't a particularly hard problem, and is tracked by JDK-8240844 [1]. And even though it will require a spec change (meaning a CSR), it doesn't result in any loss of functionality, since in order to usefully do anything with the JavaBeanX classes requires java.desktop anyway. Removing the dependency on java.desktop from javafx.graphics is a larger issue because of printing. There is also an implementation dependency on the Desktop class to implement HostServices::showDocument that would need to be redone. And of course it depends on the above (eliminating the dependency from javafx.base) being done first. For printing we would need to do one of two things: 1. Eliminate the implementation dependency on the Java2D printing code. This is a large effort, but would preserve existing functionality. 2. Make the JavaFX Printing function "optional" (i.e., make it a "ConditionalFeature"), such that if java.desktop is not present, printing doesn't work (all of the printing APIs would throw an UnsupportedOperationException if java.desktop is not available). An application that wants to do printing would need to include java.desktop. Option 1 would be my preferred approach, but as mentioned above it's a lot of work. Option 2 would need a spec change, and I'm not convinced we want to do it. If there are enough other developers who would want this, we could open it up for discussion for some future version (not JavaFX 17). Phil might have some thoughts on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8240844 On 5/18/2021 10:45 AM, Tom Schindl wrote: Uff - I'd like to revisit this topic. As I did some jlink stuff for our applications adding java.desktop once more bugged me. I guess the first thing to do is to file a JIRA-Ticket but it really starts to bug me to include java.desktop although I don't plan to use printing (and I guess > 90% of the JavaFX don't use the printing API either but produce PDFs or whatever) and Java-Beans. Tom Am 27.03.18 um 14:26 schrieb Kevin Rushforth: Hi Tom, Yes, this is an unfortunate dependency. It is "only" an implementation dependency, meaning that nothing in the public API depends on java.desktop (which is why we don't "requires transient java.desktop"), so it should be possible to remove this dependency in the future. As noted, it is only there because Java Beans is part of the java.desktop module. In the interim, your suggestion of "requires static java.base" could be the way to go. It would need a spec change to the JavaFX beans adapter classes documenting that they would throw an UnsupportedOperationException if java.desktop was not present at runtime, along with a recommendation that applications needing that functionality should add "requires java.desktop" to their own module-info.java. Note that this would only help non-graphical JavaFX applications that use javafx.base for its collections, properties, and bindings, since javafx.graphics requires java.desktop in a way that currently cannot easily be made optional (not without reimplementing printing support anyway). -- Kevin Tom Schindl wrote: Hi, Anyone else has an opinion on that? Is require static the way to go? Tom On 21.03.18 23:23, Tom Schindl wrote: Hi, I always thought the JavaFX-Codebase should be able to run with just the java.base module but I was browsing the codebase a bit and was suprised (or rather shocked) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom
Re: [External] : Re: Dependencies on java.desktop
As noted in the thread you quoted below, removing the dependency on java.desktop from javafx.base isn't a particularly hard problem, and is tracked by JDK-8240844 [1]. And even though it will require a spec change (meaning a CSR), it doesn't result in any loss of functionality, since in order to usefully do anything with the JavaBeanX classes requires java.desktop anyway. Removing the dependency on java.desktop from javafx.graphics is a larger issue because of printing. There is also an implementation dependency on the Desktop class to implement HostServices::showDocument that would need to be redone. And of course it depends on the above (eliminating the dependency from javafx.base) being done first. For printing we would need to do one of two things: 1. Eliminate the implementation dependency on the Java2D printing code. This is a large effort, but would preserve existing functionality. 2. Make the JavaFX Printing function "optional" (i.e., make it a "ConditionalFeature"), such that if java.desktop is not present, printing doesn't work (all of the printing APIs would throw an UnsupportedOperationException if java.desktop is not available). An application that wants to do printing would need to include java.desktop. Option 1 would be my preferred approach, but as mentioned above it's a lot of work. Option 2 would need a spec change, and I'm not convinced we want to do it. If there are enough other developers who would want this, we could open it up for discussion for some future version (not JavaFX 17). Phil might have some thoughts on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8240844 On 5/18/2021 10:45 AM, Tom Schindl wrote: Uff - I'd like to revisit this topic. As I did some jlink stuff for our applications adding java.desktop once more bugged me. I guess the first thing to do is to file a JIRA-Ticket but it really starts to bug me to include java.desktop although I don't plan to use printing (and I guess > 90% of the JavaFX don't use the printing API either but produce PDFs or whatever) and Java-Beans. Tom Am 27.03.18 um 14:26 schrieb Kevin Rushforth: Hi Tom, Yes, this is an unfortunate dependency. It is "only" an implementation dependency, meaning that nothing in the public API depends on java.desktop (which is why we don't "requires transient java.desktop"), so it should be possible to remove this dependency in the future. As noted, it is only there because Java Beans is part of the java.desktop module. In the interim, your suggestion of "requires static java.base" could be the way to go. It would need a spec change to the JavaFX beans adapter classes documenting that they would throw an UnsupportedOperationException if java.desktop was not present at runtime, along with a recommendation that applications needing that functionality should add "requires java.desktop" to their own module-info.java. Note that this would only help non-graphical JavaFX applications that use javafx.base for its collections, properties, and bindings, since javafx.graphics requires java.desktop in a way that currently cannot easily be made optional (not without reimplementing printing support anyway). -- Kevin Tom Schindl wrote: Hi, Anyone else has an opinion on that? Is require static the way to go? Tom On 21.03.18 23:23, Tom Schindl wrote: Hi, I always thought the JavaFX-Codebase should be able to run with just the java.base module but I was browsing the codebase a bit and was suprised (or rather shocked) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom
Re: Dependencies on java.desktop
I would also be surprised if printing and bean adapters are used much, but what are the options? Rewrite the printing implementation. On Tue, May 18, 2021 at 8:45 PM Tom Schindl wrote: > Uff - I'd like to revisit this topic. As I did some jlink stuff for our > applications adding java.desktop once more bugged me. > > I guess the first thing to do is to file a JIRA-Ticket but it really > starts to bug me to include java.desktop although I don't plan to use > printing (and I guess > 90% of the JavaFX don't use the printing API > either but produce PDFs or whatever) and Java-Beans. > > Tom > > Am 27.03.18 um 14:26 schrieb Kevin Rushforth: > > Hi Tom, > > > > Yes, this is an unfortunate dependency. It is "only" an implementation > > dependency, meaning that nothing in the public API depends on > > java.desktop (which is why we don't "requires transient java.desktop"), > > so it should be possible to remove this dependency in the future. As > > noted, it is only there because Java Beans is part of the java.desktop > > module. > > > > In the interim, your suggestion of "requires static java.base" could be > > the way to go. It would need a spec change to the JavaFX beans adapter > > classes documenting that they would throw an > > UnsupportedOperationException if java.desktop was not present at > > runtime, along with a recommendation that applications needing that > > functionality should add "requires java.desktop" to their own > > module-info.java. > > > > Note that this would only help non-graphical JavaFX applications that > > use javafx.base for its collections, properties, and bindings, since > > javafx.graphics requires java.desktop in a way that currently cannot > > easily be made optional (not without reimplementing printing support > > anyway). > > > > -- Kevin > > > > > > Tom Schindl wrote: > >> Hi, > >> > >> Anyone else has an opinion on that? Is require static the way to go? > >> > >> Tom > >> > >> On 21.03.18 23:23, Tom Schindl wrote: > >>> Hi, > >>> > >>> I always thought the JavaFX-Codebase should be able to run with just > the > >>> java.base module but I was browsing the codebase a bit and was suprised > >>> (or rather shocked) that even the base-module requires java.desktop. > >>> > >>> If I get it correct this because of the java.beans (provided by the > >>> adapters) stuff is found in there. Why hasn't the requires there not > >>> defined as: > >>> > >>> requires static java.desktop; > >>> > >>> Tom > >>> >
Re: Dependencies on java.desktop
Uff - I'd like to revisit this topic. As I did some jlink stuff for our applications adding java.desktop once more bugged me. I guess the first thing to do is to file a JIRA-Ticket but it really starts to bug me to include java.desktop although I don't plan to use printing (and I guess > 90% of the JavaFX don't use the printing API either but produce PDFs or whatever) and Java-Beans. Tom Am 27.03.18 um 14:26 schrieb Kevin Rushforth: Hi Tom, Yes, this is an unfortunate dependency. It is "only" an implementation dependency, meaning that nothing in the public API depends on java.desktop (which is why we don't "requires transient java.desktop"), so it should be possible to remove this dependency in the future. As noted, it is only there because Java Beans is part of the java.desktop module. In the interim, your suggestion of "requires static java.base" could be the way to go. It would need a spec change to the JavaFX beans adapter classes documenting that they would throw an UnsupportedOperationException if java.desktop was not present at runtime, along with a recommendation that applications needing that functionality should add "requires java.desktop" to their own module-info.java. Note that this would only help non-graphical JavaFX applications that use javafx.base for its collections, properties, and bindings, since javafx.graphics requires java.desktop in a way that currently cannot easily be made optional (not without reimplementing printing support anyway). -- Kevin Tom Schindl wrote: Hi, Anyone else has an opinion on that? Is require static the way to go? Tom On 21.03.18 23:23, Tom Schindl wrote: Hi, I always thought the JavaFX-Codebase should be able to run with just the java.base module but I was browsing the codebase a bit and was suprised (or rather shocked) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom
Re: Dependencies on java.desktop
On 27.03.18 14:26, Kevin Rushforth wrote: > Hi Tom, > > Yes, this is an unfortunate dependency. It is "only" an implementation > dependency, meaning that nothing in the public API depends on > java.desktop (which is why we don't "requires transient java.desktop"), > so it should be possible to remove this dependency in the future. As > noted, it is only there because Java Beans is part of the java.desktop > module. > > In the interim, your suggestion of "requires static java.base" could be > the way to go. It would need a spec change to the JavaFX beans adapter > classes documenting that they would throw an > UnsupportedOperationException if java.desktop was not present at How can that happen. To write a JavaBean the consumer of the API by definition has to have java.desktop as a dependency how else would he've been able to construct the bean? > runtime, along with a recommendation that applications needing that > functionality should add "requires java.desktop" to their own > module-info.java. > > Note that this would only help non-graphical JavaFX applications that > use javafx.base for its collections, properties, and bindings, since > javafx.graphics requires java.desktop in a way that currently cannot > easily be made optional (not without reimplementing printing support > anyway). > I understand but I guess here one could do a spec change to define that printing is only available if one add java.desktop yourself as a dependency. Looking at printing I might be better moved to its own module, the problem with JPMS is that you can't move stuff after having released the API module, I wished instead of "require module" JPMS would have used "import package". Tom
Re: Dependencies on java.desktop
Hi Tom, Yes, this is an unfortunate dependency. It is "only" an implementation dependency, meaning that nothing in the public API depends on java.desktop (which is why we don't "requires transient java.desktop"), so it should be possible to remove this dependency in the future. As noted, it is only there because Java Beans is part of the java.desktop module. In the interim, your suggestion of "requires static java.base" could be the way to go. It would need a spec change to the JavaFX beans adapter classes documenting that they would throw an UnsupportedOperationException if java.desktop was not present at runtime, along with a recommendation that applications needing that functionality should add "requires java.desktop" to their own module-info.java. Note that this would only help non-graphical JavaFX applications that use javafx.base for its collections, properties, and bindings, since javafx.graphics requires java.desktop in a way that currently cannot easily be made optional (not without reimplementing printing support anyway). -- Kevin Tom Schindl wrote: Hi, Anyone else has an opinion on that? Is require static the way to go? Tom On 21.03.18 23:23, Tom Schindl wrote: Hi, I always thought the JavaFX-Codebase should be able to run with just the java.base module but I was browsing the codebase a bit and was suprised (or rather shocked) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom
Re: Dependencies on java.desktop
Hi, Anyone else has an opinion on that? Is require static the way to go? Tom On 21.03.18 23:23, Tom Schindl wrote: > Hi, > > I always thought the JavaFX-Codebase should be able to run with just the > java.base module but I was browsing the codebase a bit and was suprised > (or rather shocked) that even the base-module requires java.desktop. > > If I get it correct this because of the java.beans (provided by the > adapters) stuff is found in there. Why hasn't the requires there not > defined as: > > requires static java.desktop; > > Tom >
Dependencies on java.desktop
Hi, I always thought the JavaFX-Codebase should be able to run with just the java.base module but I was browsing the codebase a bit and was suprised (or rather shocked) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom
