Maven JavaFx native libraries and OSGi
Peter Pilgrim
peter.pilgrim at gmail.com
Wed Dec 14 07:43:52 PST 2011
On 13 December 2011 22:25, Tom Schindl <tom.schindl at bestsolution.at> wrote:
> Bring it back to the list (Peter replied to me in private). See my
> comments below.
>
> BTW: Isn't is possible to to make the list set the reply-to header
> appropriately?
>
> Am 13.12.11 19:16, schrieb Peter Pilgrim:
>> On 12 December 2011 21:49, Tom Schindl <tom.schindl at bestsolution.at> wrote:
>>> Am 12.12.11 22:17, schrieb Roman Kennke:
>>>>> Just in case the people who could answer this one tuned out because of all
>>>>> the other Maven stuff in the previous email, I'm just bumping this one:
>>>>>
>>>>>
>>>>>> Co-bundling jfx+jre will be an interesting addition to this whole problem.
>>>>>> Where will the dlls live then and will that mean just cause I have java
>>>>>> installed, I'll have the jfxrt.jar automatically on my classpath and it
>>>>>> will then have access to the dlls? If so all of this will be academic, we
>>>>>> won't need a maven dependency, anymore than we need one for java.util or
>>>>>> java.swing, etc. Can anyone elaborate on this and also the expected
>>>>>> timeframe for co-bundling?
>>>>>>
>>>>>
>>>>> I'm particularly interested in the timeframe for the co-bundling? I've
>>>>> heard vague rumours ranging from first quarter next year to somewhere in
>>>>> 2013.
>>>>
>>>> I still don't understand why this would be necessary in the first place.
>>>> A JavaFX as library, available as Maven artifact/dependency (ideally via
>>>> Maven central for maximum availability), with the dll/so embedded in the
>>>> JAR, with proper versioning, seems to be the best option to me. This
>>>> way, as a developer (or release manager or whatever) I have most control
>>>> over which version of what goes into an application, i.e. JRE version X
>>>> with JavaFX version Y. Imagine that I need JavaFX version Y which is
>>>> cobundled with JRE version Z which has a bug that makes it impossible
>>>> for me to use, but the JavaFX that is cobundled with JRE version X
>>>> doesn't yet have a feature that's introduced in JavaFX Y. And no, that's
>>>> not contrived.
>>>>
>>>> Keeping it separate also has the additional advantage that there's less
>>>> (or no) chance that dependencies on internal stuff in the JRE creep into
>>>> the JavaFX code (as has happened with Swing and many other cobundled
>>>> former-external libs before).
>>>>
>>>> Regards, Roman
>>>>
>>>>
>>>
>>> Isn't that what you describe exactly what jigsaw is good for? I can only
>>> hope that jigsaw allows me to have different version of a library and I
>>> as an application developer can define through version ranges which one
>>> is loaded.
>>
>> Jigsaw would be fine or OSGi as modularity solution. (The latter is
>> suitable for weird life cycle issues assuming we work with different
>> future JavaFX version on a machine )
>> The issue is the native libraries and how to dynamically load them at
>> initialisation time.
>
OSGi is also most likely a professional requirement at this point for me ;-)
> Well as you might or might not know I'm coming from the OSGi side so I
> could outline how I'd like the layout to be for OSGi.
>
Please do.
> I'm quite sure Oracle has no plans to directly suppor the OSGi all I'd
> like to ask for is that no actions are taken to block out OSGi users.
Agreed. Flexible to all.
>
> Layout 1 - The all in one jar
> -----------------------------
> * Java-Classes for all Platforms (Win, Mac, Lin, ...)
> * All native libraries part of the jar
>
> So the jar would look like this:
>
> javafx-all-in-one.jar
> + javafx
> + ...
> + Win.class
> + Mac.class
> + ...
> + Main.class
> + native
> + win32
> + lib.dll
> + win32_64
> + lib.dll
> + ...
>
Obvious question here would you expect Java to explode the JAR in
order to dynamic load the native libraries?
How is this achieved with OSGi?
I do not want to confuse packaging of artifacts with the execution of
them. With your Layout 1 the javafx-all-in-one.jar
would be downloaded a temporary folder and then exploded, and then the
ClassPath set up.
I am unsure if this would work with a Maven Java Executable as is.
So in short you would write this:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-java-all-in-one</artifactId>
<version>2.0.2</version>
</dependency>
I assume you are expecting some magic to explode the JAR and push the
native libraries to known locations in the Maven repository.
The Maven Dependency Plugin can explode JAR file with native libraries
and put them a directory of your choice e.g. ${baseProject}/lib
The other builders like Scala Build Tool, Gradle, Apache Ivy, etc can
be taught to do the same explosion.
Obviously, Layout 1, which is very cool is a bit brute force, one shoe fits all.
>
> Layout 2 - A jar per native
> ---------------------------
> * All Java classes are ship inside a jar (Win, Mac, Lin, ...)
> * We have one extra jar per platform
>
> javafx-java.jar
> + javafx
> + ...
> + Win.class
> + Mac.class
> + ...
> + Main.class
>
> javafx-win32-native.jar
> + native
> + win32
> + lib.dll
>
In other words, you can write:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-java</artifactId>
<version>2.0.2</version>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-win32-native</artifactId>
<version>2.0.2</version>
</dependency>
This closest to my preferred solution, but no cigar. The explicit
reference to the architecture (win32-native) is the disadvantage.
> Layout 3 - A jar per platform + 1 for generic stuff
> ----------------------------------------------------
> * All none platform specific Java class in a jar
> * A platform specific Java classes in a jar per platform (Win, Mac,
> Lin, ...) plus native stuff
>
> javafx-java.jar
> + javafx
> + ...
> + Main.class
>
> javafx-win32.jar
> + javafx
> + ...
> + Win.class
> + native
> + win32
> + lib.dll
>
>
> javafx-mac.jar
> + javafx
> + ...
> + Mac.class
> + native
> + mac
> + lib.dylib
>
In other words, you can write:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-java</artifactId>
<version>2.0.2</version>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-win32</artifactId>
<version>2.0.2</version>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-mac</artifactId>
<version>2.0.2</version>
</dependency>
This makes sense if you had in a JavaFX that took advantage of
specific Windows features (if they existed System Tray) and
also support Mac specific extension. Plus it is extendible to others
like Linux, Solaris.
Ok, there is still issue about exploding the native parts of the
platform specific JAR in order to load the native library. So I do not
like mixing Java class and native SO at all.
>
> Layout 4 - A jar per platform
> ----------------------------
> * One jar per platform (duplicated generic stuff)
>
>
> javafx-win32.jar
> + javafx
> + ...
> + Win.class
> + Main.class
> + native
> + win32
> + lib.dll
>
>
> javafx-mac.jar
> + javafx
> + ...
> + Mac.class
> + Main.class
> + native
> + mac
> + lib.dylib
>
>
> I'd favor layout 4 because the more platforms the bigger layout 1 would
> make the jar and I can't believe this is a good thing if (and I hope)
> JavaFX will reach out to mobile platforms where every application by
> definition has to bring with it's own copy.
>
> Layout 4 though would make a cross platform application download bigger
> but I don't think this is really a problem (in my experience the other
> way round really is - a major pain in the ass for Eclipse RCP
> applications where you have a download per platform)
>
> All above layouts don't cause problems for OSGi which can't be said for
> the current approach where those native parts are located next relative
> to he jar. It's really strange but the fact that one can ship javafx.jar
> since 2.0.2 with the application doesn't help OSGi at all - the
> javafx-installer situation is the only working one (and you really don't
> want to know how my hoops I had to jump through to make all this work)!
>
> For OSGi the native libraries have to be packaged inside a jar and
> here's the important fact: The JavaFX library should provide a way to
> customize the dll loading because because then one can use OSGi builtin
> native library loading support or if they don't do that they should
> follow the approach SWT is doing - write their code in a way that it
> works with and without OSGi (and here ones more my hope to don't block
> OSGi users).
>
In other words, you have write some stanza:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-java-${javafx.arch}</artifactId>
<version>2.0.2</version>
</dependency>
where arch is a Maven property e.g.
<property>
<javafx.arch>win64</javafx>
</propeprty>
I do not like Layout 4, because of this indirection to depend
dynamically on the architecture.
Somewhere we have separated out pure JavaFX, support of Java around
the native libraries and the native libraries themselves.
So what I would like is this:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-java</artifactId>
<version>2.0.2</version>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-nativelib</artifactId>
<version>2.0.2</version>
</dependency>
You only need ever to specify two Maven dependencies the JavaFX with
pure Java and the Java support for bootstrapping the native libraries.
The artiface ``javafx-nativelib'' would contain a Class of the same
name ``NativeLibLoader'' with the responsibility to pick the DLL/SO
for the platform.
If only and if necessary you may need to explicitly specify the native
dependencies for your development platform.
[
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx-nativelib-win32</artifactId>
<version>2.0.2</version>
</dependency>
]
In Maven you would push the javafx-nativelib-win32 to a developer
specific profile.
I also like this because it is amenable to JDK 8, javafx-java.jmod,
javafx-nativelib.jmod and all the rest of the blighters that I will
come along soon
javafx-nativelib-win32.jmod
javafx-nativelib-win64.jmod
javafx-nativelib-macos.jmod
javafx-nativelib-linux32.jmod
javafx-nativelib-linux64.jmod
This JDIC blogger, Jacob Briggs, gives a good clue how to support
Swing/JDIC application with Maven and native libraries with JDK6.
http://www.buildanddeploy.com/node/17
This leaves us with the implementation of NativeLibLoader.java ...
> Tom
>
>> I think the direct ../bin/jfxrt.dll has to be replaced in the runtime.
>> Only the Oracle SDK team can fix it at the mo ...
>> This native path currently causes copying of the current *.dll for any
>> JavaFX project, be it Gradle, GroovyFX or ScalaFX to non-Maven or Ivy
>> compatible file structure.
>>
>> So the question is what is the correct Maven structure at the moment
>> in terms of Group Artificat Version for JAR and then
>> what is the same GAV for native libraries?
>
>
> --
> B e s t S o l u t i o n . a t EDV Systemhaus GmbH
===/////===
--
Peter Pilgrim,
**Java Champion**,
Java EE Software Development / Design / Architect for financial
services, London, UK
JavaFX and Scala Enthusiast, Creative Adaptive Software Practices
:: http://www.xenonique.co.uk/blog/ ::
:: http://twitter.com/peter_pilgrim ::
:: http://audio.fm/profile/peter_pilgrim ::
:: Skype Call peter_pilgrim ::
:: http://java-champions.java.net/ ::
More information about the openjfx-dev
mailing list