<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Daniel,<br>
<br>
Yes, jpackage and Flatpak are very much complementary technologies. <br>
<br>
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.<br>
<br>
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").<br>
<br>
Cheers,<br>
Frederic<br>
<br>
[0]
<a class="moz-txt-link-freetext" href="https://github.com/binjr/binjr/blob/a93c1bfeb024209cf6e86bfb31ef66b7ffe97a02/build.gradle#L653">https://github.com/binjr/binjr/blob/a93c1bfeb024209cf6e86bfb31ef66b7ffe97a02/build.gradle#L653</a><br>
[1]
<a class="moz-txt-link-freetext" href="https://github.com/flathub/eu.binjr.binjr/blob/master/eu.binjr.binjr.yml">https://github.com/flathub/eu.binjr.binjr/blob/master/eu.binjr.binjr.yml</a><br>
<br>
<div class="moz-cite-prefix">On 1/7/26 10:32 AM, Daniel Peintner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAoP7T4VORuMRW1hwzV7UK39ncUBg5ABQjr4=PGK155DWHck_Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi Frederic,</div>
<div><br>
</div>
<div>May I ask you about the correlation between jpackage and
Flatpak.</div>
<div><br>
</div>
<div>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).</div>
<div>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?</div>
<div><br>
</div>
<div>Thanks for your time,</div>
<div><br>
</div>
<div>-- Daniel</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, Jan 6, 2026 at 5:24 PM
Frederic Thevenet <<a href="mailto:fthevene@redhat.com"
moz-do-not-send="true" class="moz-txt-link-freetext">fthevene@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I would like to discuss a change to the native implementation
for <br>
CommonDialogs::showFileChooser/showFolderChooser in the GTK
back-end, <br>
with the ultimate goal of making JavaFX based application work
better <br>
when packaged as Flatpak[0] under Linux.<br>
<br>
Flatpak is a framework for distributing desktop applications
across <br>
various Linux distributions, that runs each application into
its own <br>
sandbox to limit its access to the host environnement to the
strict <br>
minimum, including access to the network, HW devices or the
host file <br>
system.<br>
It provides a specific set of APIs, known as "XDG Desktop
Portal "[1] to <br>
allow applications to only access resources the end user has <br>
specifically requested, for example a specific file, and in
order to <br>
fully take advantage of Flatpak's containment feature, the
guest <br>
application needs to be aware of these API; which is not the
case for <br>
Java/JavaFX based applications.<br>
<br>
Fortunately, some level of support for XDG Desktop Portal is
baked into <br>
GTK3 which should be easy to surface so that JavaFX can
benefit from it <br>
in a transparent way.<br>
<br>
One such opportunity is the e File Chooser portal, wich make
apps use <br>
the file picker dialog native to the desktop environment
they’re running <br>
on, and dynamically grants permissions to the host file system
to <br>
sandboxed apps, on a strictly need-to-access basis (i.e. the
application <br>
is granted access only the files picked by the user using the
file <br>
chooser dialog, transparently).<br>
In order to let JavaFX based apps opt into this feature, we
need to <br>
replace explicit use of GtkFileChooserDialog[2] with <br>
GtkFileChooserNative[3], which is only a small change, and
should <br>
completely transparent when an app is run normally, outside of
a sandbox <br>
since the gtk glass implementation is only used on Linux
anyway. I have <br>
prototyped it as a draft PR[4] and as you'll see, the changes
are minimal.<br>
<br>
There are other aspects of the sandboxing that currently
aren't <br>
supported well by Java/JavaFX applications and that this won't
solve, <br>
such as the fact the java.nio.file APIs will remain unaware
of the <br>
sandbox and so will refer to the files picked by the
FileChooser using a <br>
path that is opaque for the end user (e.g. <br>
"/run/user/1000/doc/adda6d11f/foo.bar" instead of <br>
"~/Downloads/foo.bar"), but this is a first step, that I
believe still <br>
has much value and no obvious drawback, and I would very much
like to <br>
see it considered for inclusion.<br>
<br>
Thanks!<br>
<br>
[0] <a
href="https://docs.flatpak.org/en/latest/introduction.html"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://docs.flatpak.org/en/latest/introduction.html</a><br>
[1] <a
href="https://flatpak.github.io/xdg-desktop-portal/docs/"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://flatpak.github.io/xdg-desktop-portal/docs/</a><br>
[2] <a
href="https://docs.gtk.org/gtk3/class.FileChooserNative.html"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://docs.gtk.org/gtk3/class.FileChooserNative.html</a><br>
[3] <a
href="https://docs.gtk.org/gtk3/class.FileChooserDialog.html"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://docs.gtk.org/gtk3/class.FileChooserDialog.html</a><br>
[4] <a href="https://github.com/openjdk/jfx/pull/2025"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/openjdk/jfx/pull/2025</a><br>
<br>
-- <br>
Frederic Thevenet<br>
Senior Software Engineer - OpenJDK<br>
Red Hat France <<a href="https://www.redhat.com"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.redhat.com</a>><br>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92<br>
<br>
</blockquote>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <a class="moz-txt-link-rfc2396E" href="https://www.redhat.com"><https://www.redhat.com></a>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92</pre>
<br>
</body>
</html>