Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release 
On 22.08.14 06:45, Ed Merks wrote:
> Tom,
> 
> Comments below.
> 
> On 21/08/2014 10:37 PM, Tom Schindl wrote:
>> You are right in that it is an install time problem as well - i think
>> from a p2 point of view tp-resolution & install a fairly equal - i think
>> it is the same p2-API-call!
> Yes, from our work with Oomph I know for a fact that the same underlying
> p2 resolution mechanisms are at work.
>>
>> The problem at runtime is:
>> a) javafx is not part of any EE so if you have a package import of
>>    javafx OSGi will not wire your bundle because nobody at runtime
>>    exposes a javafx-package, for javax the EE does that
> I see what you mean.  It seems related to this question
> http://stackoverflow.com/questions/16753429/test-apache-felix-with-java-8-and-javafx
> where the answer suggests |org.osgi.framework.system.packages.extra |can
> play a role.  But that seems problematic because it's so global. 

For felix this would be enough for Equinox it is not.

> Furthermore, I'm not sure one could declare such a thing and not cause
> problems trying to run on Java 1.6, which still ought to work.  Other
> alternatives are also suggested
> http://stackoverflow.com/questions/13240822/using-javafx-2-2-in-osgi-bundle,
> but I'm sure you've done more research than I!
> 
> It all seems inconsistently different from how javax is handled, but
> it's clear that javafx is handled differently in terms of bootstrap
> visibility for the JRE, so I suppose some inconsistency is unavoidable...

javax is available via BootClassloader
javafx is available via ExtensionClassloader

>>
>> b) javafx is part of the ExtClasspath but Equinox does NOT look up
>>    classes from there so in case you think you can get away with out
>>    doing any package impports, Equinox will tell you that no javafx
>>    classes are available
> Exactly.  In fact for Felix you do always need the package imports for
> any non-java.* package dependencies, as I found out enabling EMF's core
> runtime bundles to work properly as pure Felix bundles during the Luna
> release.

Felix is different to Equinox in that it will load classes from the
ExtensionClassloader by default whereas Equinox does not. One has to
reconfigure Equinox to use the ExtensionClassloader.

>>
>> So why fixing the runtime and tp/install problem differently (if you can
>> find a solution) if one - the current one - fixes all of them?
> Being curious, I used the wonders of open source to look at
> http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.javafx. 
> I see that it's literally creating a mirror image of the package
> structure for javafx (among other things, presumably runtime
> implementation support packages), and then simply exports those packages
> (along with version numbers you've assigned):
> 
> http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.javafx/META-INF/MANIFEST.MF
> 
> How does this mechanism help the classes actually load at runtime? 

Let's look at it in more detail let's say we have 2 bundles:
* org.eclipse.fx.javafx 1.0.0
* my.sample 1.0.0 (import-package javafx)

The classloader of my.sample 1.0.0 looks like this (BL =
BundleClassloader, CL = SimpleClassloader):

By default this would look like this:


o.e.fx.javafx 1.0.0:
--------------------
BL (o.e.fx.javafx-1.0.0.jar)
  CL (Boot)


my.sample 1.0.0:
----------------
BL (my.sample-1.0.0.jar)
  CL (Boot)
  BL (o.e.fx.javafx-1.0.0.jar)
    CL (Boot)


This explains why by default no Equinox bundle can load javafx-classes -
the ExtensionClassloader is not in the CL-Hierarchy!

Now org.eclipse.fx.osgi [1] steps in who adds a hook that allows it to
take part of the Classloader construction for any bundle. It only
handles the classloader creation of o.e.fx.javafx (see line 42 in [1])
and now suddenly the Classloader for hierarchy looks like this:

o.e.fx.javafx 1.0.0:
--------------------
BL (o.e.fx.javafx-1.0.0.jar)
  CL Ext
    CL (Boot)

which would be enough for pure javafx applications but is not enough
when we are in an swt-embedding env so we detect if org.eclipse.swt is
available (see getSWTClassloader in [1]) and then make the classloader
look like this:

o.e.fx.javafx 1.0.0:
--------------------
BL (o.e.fx.javafx-1.0.0.jar)
  CL
    CL ($java.home/jfxswt.jar)
      BL (org.eclipse.swt)
    CL Ext
      CL (Boot)


> Perhaps it's none of my business, but I'm curious...  (BTW, I wonder if
> package-info.java might be a better placeholder file in this
> dummy/mirror structure?)
> 

Right, i fact there's not need to for a dummy at all - this was only to
make PDE happy

> I suppose all this means that no bundle with javafx dependencies can
> resolve or run without this specific org.eclipse.fx.javafx bundle being
> present.  Again, it's none of my personal business, but if this is
> indeed the only solution, would Orbit be a better host for such a thing?

org.eclipse.fx.javafx and org.eclipse.fx.osgi have to be in your runtime.

Tom

[1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.osgi/src/org/eclipse/fx/osgi/fxloader/FXClassLoader.java

Back to the top