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 <[email protected]> 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 > >
