Proposal: make JavaFX cooperate better with Flatpak sand-boxing on Linux

[Frederic Thevenet]

Hi Daniel,

Yes, jpackage and Flatpak are very much complementary technologies.

Ultimately, Flatpak is just a mean to isolate and run an arbitrary 
binary bundle in a container-like environnement; in the case of a 
Java-based app it makes a lot of sense to use jpackage to generate that 
bundle.

This is precisely what I do to package my own app, if you'd like an 
example: [0] [1] (the first link shows the jpackage parameters I use to 
build a runtime image, the second shows the options I use to set up the 
Flatpak "manifest").

Cheers,
Frederic

[0] 
https://github.com/binjr/binjr/blob/a93c1bfeb024209cf6e86bfb31ef66b7ffe97a02/build.gradle#L653
[1] https://github.com/flathub/eu.binjr.binjr/blob/master/eu.binjr.binjr.yml

On 1/7/26 10:32 AM, Daniel Peintner wrote:
> Hi Frederic,
>
> May I ask you about the correlation between jpackage and Flatpak.
>
> I encounter quite often the case that the library I build uses a 
> different version of a dependent library as the one used on the target 
> machine, which causes issues (I use jpackage to create the distros).
> I believe I understand this problem is tackled by Flatpak. However, I 
> was wondering how Flatpak works in conjunction with jpackage. Can the 
> technologies be combined?
>
> Thanks for your time,
>
> -- Daniel
>
>
>
>
> On Tue, Jan 6, 2026 at 5:24 PM Frederic Thevenet <fthevene at redhat.com> 
> wrote:
>
>     Hi,
>
>     I would like to discuss a change to the native implementation for
>     CommonDialogs::showFileChooser/showFolderChooser in the GTK back-end,
>     with the ultimate goal of making JavaFX based application work better
>     when packaged as Flatpak[0] under Linux.
>
>     Flatpak is a framework for distributing desktop applications across
>     various Linux distributions, that runs each application into its own
>     sandbox to limit its access to the host environnement to the strict
>     minimum, including access to the network, HW devices or the host file
>     system.
>     It provides a specific set of APIs, known as "XDG Desktop Portal
>     "[1] to
>     allow applications to only access resources the end user has
>     specifically requested, for example a specific file, and in order to
>     fully take advantage of Flatpak's containment feature, the guest
>     application needs to be aware of these API; which is not the case for
>     Java/JavaFX based applications.
>
>     Fortunately, some level of support for XDG Desktop Portal is baked
>     into
>     GTK3 which should be easy to surface so that JavaFX can benefit
>     from it
>     in a transparent way.
>
>     One such opportunity is the e File Chooser portal, wich make apps use
>     the file picker dialog native to the desktop environment they’re
>     running
>     on, and dynamically grants permissions to the host file system to
>     sandboxed apps, on a strictly need-to-access basis (i.e. the
>     application
>     is granted access only the files picked by the user using the file
>     chooser dialog, transparently).
>     In order to let JavaFX based apps opt into this feature, we need to
>     replace explicit use of GtkFileChooserDialog[2] with
>     GtkFileChooserNative[3], which is only a small change, and should
>     completely transparent when an app is run normally, outside of a
>     sandbox
>     since the gtk glass implementation is only used on Linux anyway. I
>     have
>     prototyped it as a draft PR[4] and as you'll see, the changes are
>     minimal.
>
>     There are other aspects of the sandboxing that currently aren't
>     supported well by Java/JavaFX applications and that this won't solve,
>     such as the fact the  java.nio.file APIs will remain unaware of the
>     sandbox and so will refer to the files picked by the FileChooser
>     using a
>     path that is opaque for the end user (e.g.
>     "/run/user/1000/doc/adda6d11f/foo.bar" instead of
>     "~/Downloads/foo.bar"), but this is a first step, that I believe
>     still
>     has much value and no obvious drawback, and I would very much like to
>     see it considered for inclusion.
>
>     Thanks!
>
>     [0] https://docs.flatpak.org/en/latest/introduction.html
>     [1] https://flatpak.github.io/xdg-desktop-portal/docs/
>     [2] https://docs.gtk.org/gtk3/class.FileChooserNative.html
>     [3] https://docs.gtk.org/gtk3/class.FileChooserDialog.html
>     [4] https://github.com/openjdk/jfx/pull/2025
>
>     -- 
>     Frederic Thevenet
>     Senior Software Engineer - OpenJDK
>     Red Hat France <https://www.redhat.com>
>     BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260107/b08a5604/attachment-0001.htm>