What you suggest would not be possible without considerable refactoring
of the modules with native code, since the Java module system does not
allow modules to be split across jars.
-- Kevin
On 8/27/2018 12:02 PM, Sam Carlberg wrote:
It would be moving the platform-independent classes (ie th
It would be moving the platform-independent classes (ie the public API)
into the empty jars, leaving the platform-specific classes and binaries
where they are in the platform JARs. The service loader mechanism seems
suitable for tying the APi and platform modules together at runtime.
I don't think
The platform-specific code is a general Java issue that needs to be solved
one day. Your suggestion basically comes down to moving the classfiles from
the platform-specific jars into the empty jars, right?
A problem with this is that currently, the jars are platform-dependent as
well (e.g. no OpenG
As I see it, providing only platform-specific artifacts makes it difficult
or impossible for third-party JavaFX libraries or frameworks to depend on
the JavaFX API and pass it along to consumers. Libraries don't care about
the platform-specific code - that's up the final application to determine -
