Hi Andy,

This is actually a good suggestion. There are compatibility issues with 
existing installations (end users could change the commandline/arguments). I 
will have to check.

        - Thomas


Mit freundlichen Grüßen,

Thomas Reinhardt

Am 20.10.2022 19:12 schrieb Andy Goryachev <andy.goryac...@oracle.com>:

Thomas:



if your installer can change the command line it uses to launch java, you could 
modify the classpath to point to a subdirectory or a set of platform-specific 
jars.  do you think this might work?



-andy





From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Thomas Reinhardt 
<thomas.reinha...@s4p.de>
Date: Thursday, 2022/10/20 at 10:03
To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org>
Subject: Re: Platform independent deployment

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.reinha...@s4p.de <mailto:thomas.reinha...@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
>

Reply via email to