[External] : Re: Dependencies on java.desktop

[Tom Schindl]

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