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