Maven JavaFx native libraries and OSGi
Tom Schindl
tom.schindl at bestsolution.at
Tue Dec 13 14:25:16 PST 2011
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.
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.
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.
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
+ ...
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
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
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).
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
------------------------------------------------------------------------
tom schindl geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833
http://www.BestSolution.at phone ++43 512 935834
More information about the openjfx-dev
mailing list