The Next Great Thing: An Application Framework (original) (raw)

Uclio Work uclio.work at googlemail.com
Tue Feb 21 03:36:29 PST 2012

... because they would introduce problems they won't notice when running outside OSGi. Take the 2.0 FXMLLoader example which works perfectly in an outside OSGi-World because there's one classloader which sees everything.

Do you mean maybe "when running inside** OSGi" ? There's a huge difference, Tom :-)

Other problems are e.g. dealing with CSS-Files (e.g. in pre 2.0 they didn't used the URLs appropriately and so OSGi-Paths didn't work appropiately) and resources defined in there like images, ... but also Java-Classes (-fx-skin!).

So if they are not running in OSGi they will most likely introduce other such problematic classloading things - some of them fixable e.g. using tricks like setting modifying the ContextClassLoader (the FXMLLoader problem in 2.0) and others unfixable like the -fx-skin stuff in CSS. Writing a library without using it on OSGi while doing so will lead to all sorts of problems - and if the JavaFX team would integrate our modifications into their source we are the ones responsible to ensure they'll work in future versions as well.

I totally agree with you, Tom. Having JFX made OSGi-aware by the JFX team would be the best option. But honestly, how much do they care at this very moment ? Maybe Richard can shed some light about this. Moreover, I am not aware of resources available to the team, butthis seems anyway to be a huge work, if not a refactoring of the entire platform.

I guess that as long as the platform does not reach a certain level of maturity, so that the burden for the team starts to decrease, we should suggest changes as we encounter potential problems.

But, hey, if someone in the JFX team says... "No, we need to have JFX OSGi-aware now"... I'll be very happy

You did not yet mention what you had to modify e.g. in the NativeLibLoader to make things work.

Because they have hardwired the path where the native libs have to be placed. Therefore the usual OSGi approach, that is having the Bundle-NativeCode header in your manifest with the OSGi engine doing loading, fails since the findLibrary of the OSGi ClassLoader can't resolve the location of the libs.

Lucio

More information about the openjfx-dev mailing list