[including Alan and Mandy]
This came up briefly in a thread sent to jigsaw-dev [1], but with no
real conclusion. I agree that it would be good to get a recommendation
from the Jigsaw team.
After thinking about it more, here are my preferences:
* From the developer's point of view, they shouldn't have to know or
care that some of our modules have platform-specific native code and
others do not. Ideally, all an app developer should need is to declare a
dependency on the needed module(s). Something like this:
'javafx:javafx.controls:11'
'javafx:javafx.graphics:11' (although controls will depend on
graphics, so this should be optional)
* For maven, the pom file should take care of downloading the jar
file(s) for the specific platform; not sure if that is possible for
gradle dependencies, but it would be ideal.
* For each module, we can package up the natives in one of two ways:
A) create a separate jar file per platform with the native code and the
modular jar both in the same jar file. something like:
javafx-graphics-win-x64.jar
javafx-graphics-linux-x64.jar
javafx-graphics-osx-x64.jar
B) create one platform-independent modular jar file with all classes for
all platforms, and also a separate jar per platform just for the native
libraries:
javafx-graphics.jar (with classes for all platforms)
javafx-graphics-natives-win-x64.jar
javafx-graphics-natives-linux-x64.jar
javafx-graphics-natives-osx-x64.jar
For either option there will need to be code that unpacks the natives.
I prefer option A if feasible, as I think it simplifies the build,
hopefully without unduly complicating anything else. If it isn't
feasible, then option B might be a good fallback.
Comments?
-- Kevin
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-April/013762.html
On 5/1/2018 5:34 AM, Johan Vos wrote:
I'd love to hear a general recommendation from the jigsaw team as well.
Clearly, there are a number of solutions, and as a developer, I easily
get confused if some frameworks do it with option A and others with
option B.
So what is the preferred approach in general?
It seems (given the large size of the webkit native library) there is
a growing consensus here for bundling native code inside
platform-specific jars?
- Johan
On Tue, May 1, 2018 at 7:38 AM Phil Race <[email protected]
<mailto:[email protected]>> wrote:
You are describing the situation today and making it into a
contract. You need to be sure that it is policed and enforceable.
Meaning there need to be tests to ensure it stays that way and
that it is not an unreasonable constraint on changes in the platform.
Also what if anything do the jigsaw team recommend ?
-Phil.
> On Apr 30, 2018, at 4:07 PM, Kevin Rushforth
<[email protected] <mailto:[email protected]>>
wrote:
>
> The native libraries are quite large -- especially jfxwebkit --
and it does seem better to have per-platform jar files, at least
for the native libraries. The following modules could be
platform-independent since they have no natives:
>
> javafx.base
> javafx.controls
> javafx.fxml
> javafx.swing
>
> We would just need to test that the set of modular jar files for
each platform are the same, and then pick one (Linux?) to use for
generating the platform-independent jar files.
>
> The following modules have native libraries:
>
> javafx.graphics (*)
> javafx.media (*)
> javafx.web
>
> (*) - also has some differences in the set of class files that
are included depending on the platform
>
> So per-platform versions of the above would be needed to
accommodate the different native libraries.
>
> If it would help, the .class files could be always included for
all platforms, but there would be some additional effort to make
this work. Also, it might be just as easy to have the class files
and the natives in one downloaded jar file per platform, since at
least the natives need to be platform-independent. I'm far from a
maven expert, though, so I don't really know for sure which path
is easier.
>
> -- Kevin
>
>
>> On 4/30/2018 9:44 AM, Paul Ray Russell wrote:
>> >I'm not sure I understand the question about
platform-specific jar files,
>>
>> Last time I worked on native specifics (which was to package up
RXTX dlls
>> for different OSs / in 64/32 bit) The easiest solution for pure
Maven
>> builds seemed to be, to package DLLs inside a jar. We then used
a profile
>> to control which DLL's were grabbed in different cases. And
surely for this
>> specific case, it would be better to split the native specifics
into
>> separate jars per OS to avoid a huge cross-OS download?
>
