[External] : Re: Dependencies on java.desktop

Philip Race philip.race at oracle.com
Wed May 19 19:51:55 UTC 2021


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



More information about the openjfx-dev mailing list