Platform independent deployment
Thomas Reinhardt
thomas.reinhardt at s4p.de
Fri Oct 21 09:36:52 UTC 2022
Hi Nir,
No, it is not a "big problem", but it certainly is an annoyance. I went
from 2 dependencies that manage transitive dependencies themselves to 12
handcrafted depdendencies. I also have to manage versions for all the
platform specific artifacts by hand. That is 6 artifacts for two
platforms and most have a platform independent version also. Totalling
to 18 versions that I have to manage in my bom. All of that is "easy"
but it has to be done and clutters my poms. If we ever want to support
another os I will have to add even more noise to my poms.
As for the javafx-maven-plugin: I don't see how this would help here. It
states on the github page "JavaFX dependencies are added as usual".
Don't get me wrong, I am perfectly fine with doing it that way. But the
situation is far from easy or painless. And after a little digging I
think half of the artifacts should not have been platform dependent in
the first place:
$ diff -rq javafx-base-19-linux/ javafx-base-19-win/ | wc -l
1
$ diff -rq javafx-controls-19-linux/ javafx-controls-19-win/ | wc -l
6
$ diff -rq javafx-fxml-19-linux/ javafx-fxml-19-win/ | wc -l
0
$ diff -rq javafx-graphics-19-linux/ javafx-graphics-19-win/ | wc -l
72
$ diff -rq javafx-media-19-linux/ javafx-media-19-win/ | wc -l
13
$ diff -rq javafx-swing-19-linux/ javafx-swing-19-win/ | wc -l
0
$ diff -rq javafx-web-19-linux/ javafx-web-19-win/ | wc -l
2
javafx-base only differs in VersionInfo.class, javafx-fxml and
javafx-swing are completely identical so 3 out of 7 artifacts really
should not be platform dependent at all.
javafx-controls only differs in .bss files (binary css? interesting).
seems like a packaging artifact to me as the (corresponding?) .css files
are identical. So this artifact probably should not be platform
dependent either.
javafx-graphics differs in a handful of java classes and native
libraries of course.
javafx-media and javafx-web which differ only in native libraries.
I would really like to see the platform dependency be removed from
javafx-base, javafx-fxml, javafx-swing and javafx-controls. That would
be a big step to ease platform independent deployments.
Sorry for the big wall of text :)
-Thomas
On 21/10/2022 00:38, Nir Lisker wrote:
> It doesn't look to me like a big problem, regardless of the size of the
> project. You just include the modules you want depending on what your
> application needs and which platforms it targets. In Gradle, it's just 2
> lines of code.
>
> There is also the JavaFX plugin that might help with this, but it's
> unrelated to the development here:
> Gradle variant - https://github.com/openjfx/javafx-gradle-plugin
> <https://github.com/openjfx/javafx-gradle-plugin>
> Maven variant - https://github.com/openjfx/javafx-maven-plugin
> <https://github.com/openjfx/javafx-maven-plugin>
>
> On Fri, Oct 21, 2022 at 1:29 AM Thomas Reinhardt
> <thomas.reinhardt at s4p.de <mailto:thomas.reinhardt at s4p.de>> wrote:
>
> Thanks Nir for the links to the other discussions. I got the thing
> to run with the simple approach of including all artifacts. Probably
> did miss some before but it's late in the night here :)
>
> One thing that still bugs me is that I have to do dependency
> resolution manually if I want to include artifacts for different
> platforms. Not a huge problem but far from a perfect solution. And
> I can't stop to think what other big projects are doing. Apart from
> toy-applications that run on the development system only, everybody
> should have the same problems I had. Or maybe I am just the last one
> striving for a platform independent application.
>
> Thank you all for helping out!
>
> ------------------------------------------------------------------------
> *From:* Nir Lisker <nlisker at gmail.com <mailto:nlisker at gmail.com>>
> *Sent:* 20 October 2022 23:14
> *To:* Thomas Reinhardt <thomas.reinhardt at s4p.de
> <mailto:thomas.reinhardt at s4p.de>>
> *Cc:* openjfx-dev at openjdk.org <mailto:openjfx-dev at openjdk.org>
> <openjfx-dev at openjdk.org <mailto:openjfx-dev at openjdk.org>>
> *Subject:* Re: Platform independent deployment
> There was a discussion on this some years ago, it started here:
> https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html <https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html> (and continued in https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html <https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html>).
> There might have been another discussion after that, I don't remember.
>
> Thomas, the graphics, media, and web modules contain OS-specific
> libraries. You will need to do what I showed for any of these that
> you use.
>
> On Fri, Oct 21, 2022 at 12:05 AM Thomas Reinhardt
> <thomas.reinhardt at s4p.de <mailto:thomas.reinhardt at s4p.de>> wrote:
>
> Interesting. I will repeat my test more carefully. Maybe I am
> just doing something incredible stupid. But Andy has a good
> point: why include the java classes at all in the
> platform-specific jars - shouldn't they just contain the native
> libraries if all the java code is indeed the same?
>
> -Thomas
>
> ------------------------------------------------------------------------
> *From:* openjfx-dev <openjfx-dev-retn at openjdk.org
> <mailto:openjfx-dev-retn at openjdk.org>> on behalf of Andy
> Goryachev <andy.goryachev at oracle.com
> <mailto:andy.goryachev at oracle.com>>
> *Sent:* 20 October 2022 22:53
> *To:* John Hendrikx <john.hendrikx at gmail.com
> <mailto:john.hendrikx at gmail.com>>; openjfx-dev at openjdk.org
> <mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org
> <mailto:openjfx-dev at openjdk.org>>
> *Subject:* Re: Platform independent deployment
>
> Good point - are we packaging platform-specific javafx parts
> incorrectly?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org
> <mailto:openjfx-dev-retn at openjdk.org>> on behalf of John
> Hendrikx <john.hendrikx at gmail.com <mailto:john.hendrikx at gmail.com>>
> *Date: *Thursday, 2022/10/20 at 13:03
> *To: *openjfx-dev at openjdk.org <mailto:openjfx-dev at openjdk.org>
> <openjfx-dev at openjdk.org <mailto:openjfx-dev at openjdk.org>>
> *Subject: *Re: Platform independent deployment
>
> Correct me if I'm wrong, but all the classes in the artifacts
> for win,
> linux and mac are actually exactly the same -- this is Java code
> after
> all, why would all Java classes for a platform be platform
> specific? It
> doesn't matter which one is packaged. The platform specific
> stuff lives
> in the native libraries -- my shaded jar just includes all of
> them for
> all platforms (dll for windows, so for linux, dylib for mac). I'm
> pretty sure I used this exact same jar to run my software on
> windows and
> linux. Never tested mac as I don't own one.
>
> My pom therefore includes all three, like Nir Lisker has, and my
> shaded
> artifact just packages them all (I get a lot of warnings about
> duplicate
> classes, but those can just be ignored).
>
> --John
>
> On 20/10/2022 19:03, Thomas Reinhardt wrote:
> >
> > Hi Nir,
> >
> > Does not work (I testet it) and it can not work (see below).
> >
> > Also, this is exactly what my naive test was (I did not use maven to
> > copy the artifacts, but the result obviously is the same).
> >
> > It can not work as the implementation classes have the same name and
> > thus the jre can not distinguish which one to load. For example both
> > javafx-web-18-win and javafx-web-18-linux define a class
> > "javafx.scene.web.WebEngine". From the jre's point of view they are
> > the same.
> >
> > What would be needed is
> >
> > Either: a class "javafx.scene.web.WebEngine" that is only a thin
> > wrapper to javafx.scene.web.linux.WebEngine.
> >
> > Or: a class that loads only one of the implementations during
> > application startup (technically it could load both implementations
> > with different classloaders, but lets not go there).
> >
> > There might be other solutions but I am not aware of any.
> >
> >
> > I was looking for a help forum but did only find the #introduction
> > link you mentioned.
> >
> >
> > -Thomas
> >
> >
> >
> > On 20/10/2022 17:52, Nir Lisker wrote:
> >> Hi Thomas,
> >>
> >> Did you try to just specify the platform-specific dependencies in the
> >> POM?
> >>
> >> <dependency>
> >> <groupId>org.openjfx</groupId>
> >> <artifactId>javafx-graphics</artifactId>
> >> <version>19</version>
> >> <classifier>win</classifier>
> >> </dependency>
> >> <dependency>
> >> <groupId>org.openjfx</groupId>
> >> <artifactId>javafx-graphics</artifactId>
> >> <version>19</version>
> >> <classifier>linux</classifier>
> >> </dependency>
> >> <dependency>
> >> <groupId>org.openjfx</groupId>
> >> <artifactId>javafx-graphics</artifactId>
> >> <version>19</version>
> >> <classifier>mac</classifier>
> >> </dependency>
> >>
> >> Seems more of a question for help forums, though if this information
> >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction
> <https://openjfx.io/openjfx-docs/#introduction>
> >> <https://openjfx.io/openjfx-docs/#introduction
> <https://openjfx.io/openjfx-docs/#introduction>>, it might be worth
> >> adding it.
> >>
> >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt
> >> <thomas.reinhardt at s4p.de <mailto:thomas.reinhardt at s4p.de>
> <mailto:thomas.reinhardt at s4p.de
> <mailto:thomas.reinhardt at s4p.de>>> wrote:
> >>
> >>
> >> Hi!
> >>
> >> Apologizes if this is not the proper list to ask my question.
> >>
> >> For context: we are using the WebView of JavaFX in our legacy swing
> >> based frontend application. For now that is the only component we
> >> are
> >> using but we might migrate completely at a later point in time.
> >>
> >> I have an issue with the way platform dependent dependencies are
> >> handled. We are using maven btw.
> >> My understanding is that during the build a profile is selected
> >> based on
> >> the host os name and architecture. That profile then sets a property
> >> (javafx.platform) that is in turn used as the classifier for
> >> platform
> >> dependent dependencies.
> >> (Offtopic to my question: eclipse warns that the profile ids are not
> >> unique in the org.openjfx:javafx pom.xml).
> >>
> >> Which means that the result of my build is locked to a single
> >> platform.
> >> But we have customers for windows and linux and don't want to have
> >> separate artifacts as that would mean we also have to handle that
> >> distinction in our installer etc.
> >>
> >> I know I can override the automatically detected platform but
> >> that does
> >> not solve the issue.
> >>
> >> Ideally I would use something like -Djavafx.platform=all but that
> >> does
> >> not exist.
> >>
> >> My question is: is there an existing solution where I can just
> >> include
> >> all platform dependencies for say windows and linux and the runtime
> >> "sorts it out"? A naive test (manual copying of artifacts) of mine
> >> unfortunately failed. Of course I could just use custom classloaders
> >> and
> >> do it myself but I really would prefer to use an existing
> >> solution and
> >> not implement some workaround.
> >>
> >> If there is no solution (yet), is there interest in such a
> >> feature? We
> >> might be able to contribute to the project.
> >>
> >>
> >> -Thomas
> >>
>
More information about the openjfx-dev
mailing list