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