native libs in modules
johan.vos at gluonhq.com
Tue May 1 12:34:20 UTC 2018
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
On Tue, May 1, 2018 at 7:38 AM Phil Race <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>
> > 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
> >> Last time I worked on native specifics (which was to package up RXTX
> >> 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
> >> to control which DLL's were grabbed in different cases. And surely for
> >> specific case, it would be better to split the native specifics into
> >> separate jars per OS to avoid a huge cross-OS download?
More information about the openjfx-dev