Platform independent deployment

Fri Oct 21 08:22:20 UTC 2022

Thanks Phil, I wasn't aware of those.

I think the point still stands though that the same class never has 
different contents (in JavaFX at least) for a different platform (ie, 
there aren't three different versions of ButtonSkin for the different 
platforms). Additional classes specific to a platform with unique names 
that are only used on that platform are okay -- you should still be able 
to package all of the artifacts, strip out duplicates and make a fat jar 
out of it that runs on all platforms.

--John

On 21/10/2022 08:11, Philip Race wrote:
> > this is Java code after all, why would all Java classes for a 
> platform be platform specific?
>
> There absolutely CAN be such things as platform-specific Java classes 
> in code that ports to a platform.
> OpenJDK is littered with subdirectories named "windows" and "linux" etc.
> And it takes great care to build and ship these only on appropriate 
> platforms.
>
> In JavaFX such things also exist that are less clear but still 
> platform-specific
> For example what place does
> modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext 
> have in the windows build, or
> modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite 
> have in the macos build ?
>
> None, really, and even though they are there, they really should not be.
>
> So the bottom line is that you should not assume that a platform like 
> JavaFX can be
> delivered only with platform independent Java code.
>
> -phil
>
>
> On 10/20/22 1:03 PM, John Hendrikx wrote:
>> 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
>>>>
>