Platform independent deployment

Nir Lisker nlisker at gmail.com
Thu Oct 20 21:14:50 UTC 2022


There was a discussion on this some years ago, it started here:
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).
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>
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> on behalf of Andy
> Goryachev <andy.goryachev at oracle.com>
> *Sent:* 20 October 2022 22:53
> *To:* John Hendrikx <john.hendrikx at gmail.com>; openjfx-dev at openjdk.org <
> 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> on behalf of John
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Thursday, 2022/10/20 at 13:03
> *To: *openjfx-dev at openjdk.org <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>, 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
> <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
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20221021/1398b2a9/attachment.htm>


More information about the openjfx-dev mailing list