Remove dependency on java.desktop from javafx.base and javafx.graphics

[Maran23]

This PR makes the java.desktop requirement static for javafx.base and javafx.graphics. With this changes, a JavaFX app without Swing and the WebView will be much smaller (results below).

Consequences:

• java.desktop need to be loaded (required) when using anything from the javafx.beans.property.adapter package (the property classes from java.beans.XXX are used here)
• java.desktop need to be loaded (required) when using printing, that is e.g. PrinterJob.createPrinterJob().showPrintDialog(..)

Results:

• Removing java.desktop gives a huge size boost! I benchmarked the following values when using jlink with: [zip-6, --no-man-pages, --no-header-files, --strip-debug, --strip-java-debug-attributes] to build an own runtime

Tried on a real application (here called myapp) with JDK-25 on Windows 11 that has dependencies to: [javafx-base, javafx-graphics, javafx-fxml, javafx-controls]

---

master

70.009.288 Bytes

myapp
java.base@25
java.datatransfer@25
java.desktop@25
java.prefs@25
java.scripting@25
java.xml@25
javafx.base@26-internal
javafx.controls@26-internal
javafx.fxml@26-internal
javafx.graphics@26-internal
jdk.localedata@25
jdk.unsupported@25

---

This PR

57.266.538 Bytes

myapp
java.base@25
java.scripting@25
java.xml@25
javafx.base@26-internal
javafx.controls@26-internal
javafx.fxml@26-internal
javafx.graphics@26-internal
jdk.localedata@25
jdk.unsupported@25

---

This PR + https://github.com/openjdk/jfx/pull/1957

57.249.459 Bytes

myapp
java.base@25
java.scripting@25
java.xml@25
javafx.base@26-internal
javafx.controls@26-internal
javafx.fxml@26-internal
javafx.graphics@26-internal
jdk.localedata@25

---

So we save around 13MB. If building a native package, e.g. an .msi installer, this will be even higher.

This change however probably need some discussion, if we want to go that direction + add a note in the release notes, that if one of the two things mentioned above are needed, an requirement to java.desktop is needed (in case of a modular project).

---

Progress

• [x] Change must not contain extraneous whitespace
• [ ] Commit message must refer to an issue
• [ ] Change must be properly reviewed (2 reviews required, with at least 2 Reviewers)
• [ ] Change requires a CSR request matching fixVersion jfx26 to be approved (needs to be created)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1958/head:pull/1958
$ git checkout pull/1958

Update a local copy of the PR:
$ git checkout pull/1958
$ git pull https://git.openjdk.org/jfx.git pull/1958/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1958

View PR using the GUI difftool:
$ git pr show -t 1958

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1958.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper[bot]]

:wave: Welcome back mhanl! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk[bot]]

❗ This change is not yet ready to be integrated. See the Progress checklist in the description for automated requirements.

[mlbridge[bot]]

Webrevs

• 00: Full (07971235)

[kevinrushforth]

Three quick comments before I review.

1. This will need a CSR
2. Removing the direct dependency on java.desktop from javafx.base, making it a requires static, seems reasonable, as I wrote in the description of the enhancement request. This will need testing.
3. Removing the direct dependency on java.desktop from javafx.graphics, making it a requires static will almost certainly not be accepted as long as the implementation depends on it. I'll add more details when I review.

/reviewers 2 reviewers /csr

[openjdk[bot]]

@kevinrushforth The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 2 Reviewers).

[openjdk[bot]]

@kevinrushforth has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@Maran23 please create a CSR request for issue JDK-8240844 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[Maran23]

3. Removing the direct dependency on `java.desktop` from `javafx.graphics`, making it a `requires static` will almost certainly not be accepted as long as the implementation depends on it. I'll add more details when I review.

I agree, this change has the biggest 'risk'. Still, I would like to bring this up for discussion, as there is a huge benefit (much higher than I thought). I have already considered discussing this on the mailing list, but I would like to know first whether this change might be out of question, as we would not need to discuss it in that case.

[kevinrushforth]

3. Removing the direct dependency on java.desktop from javafx.graphics, making it a requires static will almost certainly not be accepted as long as the implementation depends on it. I'll add more details when I review.

I agree, this change has the biggest 'risk'. Still, I would like to bring this up for discussion, as there is a huge benefit (much higher than I thought). I have already considered discussing this on the mailing list, but I would like to know first whether this change might be out of question, as we would not need to discuss it in that case.

While I might not quite go as far as to say "out of the question", it is unlikely that such a proposal would be accepted. This would be an incompatible change, which we very rarely do, especially for features that are still useful (and even then, not without notice, such as deprecating API for removal, followed by later removal). Applications that use JavaFX Printing APIs would stop working in some cases, unpredictably so, since it would work as long as any other module required java.desktop, but would fail at runtime if not (with a confusing error message). The recently-added ImageIO support added to images would also behave differently. Whereas today loading a ".tiff" file will just work (by falling back to the ImageIO TIFF loader shipped with java.desktop), it would fail to load (gracefully, but it would fail nonetheless).

The difference between the javafx.graphics usage and the javafx.base usage, is that the javafx.graphics usage of java.desktop for printing is incidental, and is an implementation detail as far as the app is concerns: There is nothing in the API docs that suggests the use of the Java2D printing API. So we would effectively have to tell application developers -- via API docs, a CSR, and a release note (at least) -- "if you want to use these APIs, your application now has to add a dependency on java.desktop because we no longer do". That will be a hard sell.

So, feel free to raise it on the mailing list. In the mean time, either move this to Draft or revert the change in javafx.graphics.

[nlisker]

There was a discussion on this on the mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043731.html.

[Maran23]

There was a discussion on this on the mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043731.html.

Thanks. Is there a way to answer to it, even if I don't have the original email anymore?

[nlisker]

There was a discussion on this on the mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043731.html.

Thanks. Is there a way to answer to it, even if I don't have the original email anymore?

Not sure. I sent an email from that thread now so you can latch onto it.