[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Simpler JavaFX class loading
- From: Thomas Watson <tjwatson@xxxxxxxxxx>
- Date: Tue, 25 Feb 2014 12:00:53 -0600
- Delivered-to: firstname.lastname@example.org
Sorry, I have lost track of what the framework extension is doing for JavaFX. Tom Schindl, perhaps you have a link for a quick refresher?
Adding the packages to org.osgi.framework.system.packages is not enough because that adds the packages as exported by the system bundle. For that to work the class loader used to load up the framework must have access to the packages. By default the equinox launcher sets the parent class loader for the framework to be the boot class loader. As Tom S. has indicated the JavaFX classes are on the extension class loader, not the boot class loader. That also prevents you from using a simple system.bundle fragment as Alex suggests, because these packages also must be loaded by the framework class loader. I think you could set the configuration property osgi.frameworkParentClassloader=ext to get that to work.
But I am not inclined to make that the default setting since we typically have hidden things from the extension class path. Usually we would want these extra libraries to be installed as normal bundles, either directly or wrapped inside a bundle so that we are not dependant on some VM specific configuration of the extension class path. Tom S. has explained why this is not possible a few times, but I don't recall all the issues there.
Doug Schaefer ---02/25/2014 11:09:50 AM---a) My focus is actually Mars, Luna for now, not Kepler. b) I don¹t care much about swt-embedding, I¹
From: Doug Schaefer <dschaefer@xxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date: 02/25/2014 11:09 AM
Subject: Re: [equinox-dev] Simpler JavaFX class loading
Sent by: equinox-dev-bounces@xxxxxxxxxxx
a) My focus is actually Mars, Luna for now, not Kepler.
b) I don¹t care much about swt-embedding, I¹m going the other way.
c) Agreed. A FX specific profile makes sense. That requires another
property to ensure it gets loaded, but better than the magic extensions
property. But I haven¹t had much luck getting the profiles to do what I
want anyway. Adding the packages to org.osgi.framework.system.packages
doesn¹t seem to be enough or correct at all.
On 2/25/2014, 12:00 PM, "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx> wrote:
>a) Simply providing a fragment
>No. The problem is that JavaFX is on the ExtensionClasspath which is
>skipped by default on Equinox - maybe this changes with Luna?
>On Kepler there was an invalid OSGi-Switch who made this possible!
>Search the forum on a discussion how this could work.
>b) SWT-FX integration
>This would still have to be done using the hook because the
>swt-embedding is not on the classpath
>c) putting in the JavaSE1.8 profile sounds wrong - this is not JSRed API
>so if I'd ship an extra profile JavaSE-FX-1.8 which holds the packages.
>Another problem with this is that - believe me - many people have to
>access internal API so if you only export the public one you'll make
>many people not happy.
>On 25.02.14 17:43, Alex Blewitt wrote:
>> Can you not just install a fragment to the system bundle that exports
>>the javafx packages?
>> Sent from my iPhone 5
>>> On 25 Feb 2014, at 16:15, Doug Schaefer <dschaefer@xxxxxxx> wrote:
>>> Hey gang,
>>> I¹m aware of the work Tom S has done with class loading hooks to get
>>>JavaFX classes to load. I¹m just wondering if there are easier
>>>approaches we could be following, something we can put in the
>>>JavaSE-1.8.profile file or somewhere else so that we can make this a
>>>more data driven approach. It¹s a pain to have to set the
>>>osgi.framework.extensions property for every product we want to build
>>>with JavaFX support. I¹m aware that not every 1.8 VM will have JavaFX
>>>in it, but for those that do, I¹d love to see this support enabled
>>>automagicly. Any thoughts?
>>> equinox-dev mailing list
>> equinox-dev mailing list
>equinox-dev mailing list
equinox-dev mailing list