native libs in modules
kevin.rushforth at oracle.com
Tue May 1 15:36:05 UTC 2018
[including Alan and Mandy]
This came up briefly in a thread sent to jigsaw-dev , 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.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:
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
javafx-graphics.jar (with classes for all platforms)
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.
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 <philip.race at oracle.com
> <mailto:philip.race at oracle.com>> 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 ?
> > On Apr 30, 2018, at 4:07 PM, Kevin Rushforth
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
> > 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
> >> 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
> >> separate jars per OS to avoid a huge cross-OS download?
More information about the openjfx-dev