Platform independent deployment

[Andy Goryachev]

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>> 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/20221020/300a7b39/attachment-0001.htm>