[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Simpler JavaFX class loading

I change the contents of the eclipse.ini from p2.inf files all the time.
It would be easy to add this option. Also, we're going to need a separate
launcher anyway to avoid loading the native UI. It could also be done
there.

I’m just trying to keep things simple so we can do Eclipse SDK CBI builds
and get things running as quickly as we can. I also don’t care about the
JavaFX on SWT (FXCanvas) use case at all, just the SWT on JavaFX one. It
seems they need different solutions anyway.

Doug.

On 2/25/2014, 3:30 PM, "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx> wrote:

>This is not an option how would you make this work when installing
>through p2 you need to modify the launch parameters of the framework
>which is fine a single vendor env but not in a multi-vendor one like
>Eclipse.
>
>Other things:
>* repackage is not possible (legally)
>* repackage is not feasable because the native stuff will ALWAYS be
>  loaded from the JRE-Directory so there's a great likeliness of a java
>  <-> native code mismatch
>
>Back to my stuff.
>
>How does my stuff work:
>a) there's a bundle which exports javafx-packages (it has no sources at
>   all)
>b) there's a fragment doing the hooks and intercepts classloading ONLY
>   if the framework tries to load classes from the fake bundle
>
>b)1) If the framework detects the loading of FXCanvas it puts JavaFX in
>     a special mode so that it is not shutdown
>
>p2 handles the setting of the framework extension just fine when
>installing and so I'm not stepping on any other bundles toes like i
>would when modifying the classloading strategy in a global way.
>
>If we leave the b1 out for now and only want to target JDK8 there's an
>option which has not been discussed until now. Equinox (at least in
>kepler) allowed one to reference jars in the Bundle-ClassPath which are
>somewhere on the system. I can not recall the exact syntax but it would
>be something like
>
>Bundle-ClassPath: .,
> external:$jre.home/lib/ext/jfxrt.jar
>
>Advantage: No framework hooks, only one bundle which exports classes
>Draw back: JavaFX classes are NOT loaded by the ExtensionClassLoader so
>things like ScenicView are not going to work!
>
>Tom
>
>On 25.02.14 20:04, Doug Schaefer wrote:
>> I’m trying to avoid too much magic which is why I’m not sold on Tom S’s
>> approach.
>> 
>> Interesting enough adding -Dorg.osgi.framework.bundle.parent=ext worked.
>> Not ideal as you mention, but gets us going until JavaFX gets onto the
>> boot classpath in Java 9, or we come up with a better idea.
>> 
>> Thanks!
>> :D
>> 
>> From: Thomas Watson <tjwatson@xxxxxxxxxx <mailto:tjwatson@xxxxxxxxxx>>
>> Reply-To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx
>> <mailto:equinox-dev@xxxxxxxxxxx>>
>> Date: Tuesday, February 25, 2014 at 1:28 PM
>> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx
>> <mailto:equinox-dev@xxxxxxxxxxx>>
>> Subject: Re: [equinox-dev] Simpler JavaFX class loading
>> 
>> Right, I think it is both a licensing issue and, from what I recall,
>> some technical issues as to why javafx must be loaded by the extension
>> class loader instead of some higher up application class loader (or
>> bundle loader).
>> 
>> I think one of the things Tom S. javafx framework extension is doing is
>> creating a virtual kind of bundle that essentally puts the javafx jar on
>> the classpath of a bundle to export the packages.  Again my memory is
>> fuzzy here.
>> 
>> Tom
>> 
>> 
>> 
>> Inactive hide details for Doug Schaefer ---02/25/2014 12:18:07 PM---I
>> think I get it. Ideally, we'd have a bundle that exports Doug Schaefer
>> ---02/25/2014 12:18:07 PM---I think I get it. Ideally, we'd have a
>> bundle that exports the packages. That would be easiest to ma
>> 
>> From: Doug Schaefer <dschaefer@xxxxxxx <mailto:dschaefer@xxxxxxx>>
>> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx
>> <mailto:equinox-dev@xxxxxxxxxxx>>,
>> Date: 02/25/2014 12:18 PM
>> Subject: Re: [equinox-dev] Simpler JavaFX class loading
>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>> <mailto:equinox-dev-bounces@xxxxxxxxxxx>
>> 
>> ------------------------------------------------------------------------
>> 
>> 
>> 
>> I think I get it. Ideally, we'd have a bundle that exports the packages.
>> That would be easiest to manage. But is that possible with a jar file
>> that’s on the ext path and not in the bundle? I think it’s pretty clear
>> licensing of the Oracle JRE would prevent us from copying that jar file
>> anywhere and redistributing it which we wouldn’t want to do anyway.
>> 
>> Thanks!
>> Doug.
>> 
>> *From: *Thomas Watson <_tjwatson@xxxxxxxxxxx
>><mailto:tjwatson@xxxxxxxxxx>>*
>> Reply-To: *Equinox development mailing list <_equinox-dev@xxxxxxxxxxxx
>> <mailto:equinox-dev@xxxxxxxxxxx>>*
>> Date: *Tuesday, February 25, 2014 at 1:07 PM*
>> To: *Equinox development mailing list <_equinox-dev@xxxxxxxxxxxx
>> <mailto:equinox-dev@xxxxxxxxxxx>>*
>> Subject: *Re: [equinox-dev] Simpler JavaFX class loading
>> 
>> We would not do this in the framework delegation (BundleLoader) by
>> default because it would expose classes to bundles which have no defined
>> dependencies on the package (e.g Import-Package: javafx.*).  Bundles
>> should declare their dependencies on the packages they require to
>> function.  Providing the bundles with packages for free will allow them
>> to "work" but they will then fail with class loading issues on platforms
>> that do not have javafx.
>> 
>> Tom
>> 
>> 
>> 
>> Inactive hide details for Doug Schaefer ---02/25/2014 11:01:57 AM---PDE
>> wouldn¹t let me export packages not defined in my plug-Doug Schaefer
>> ---02/25/2014 11:01:57 AM---PDE wouldn¹t let me export packages not
>> defined in my plug-in. BTW, I¹ve created a pretty simple cla
>> 
>> From: Doug Schaefer <_dschaefer@xxxxxxxx <mailto:dschaefer@xxxxxxx>>
>> To: Equinox development mailing list <_equinox-dev@xxxxxxxxxxxx
>> <mailto:equinox-dev@xxxxxxxxxxx>>,
>> Date: 02/25/2014 11:01 AM
>> Subject: Re: [equinox-dev] Simpler JavaFX class loading
>> Sent by: _equinox-dev-bounces@xxxxxxxxxxxx
>> <mailto:equinox-dev-bounces@xxxxxxxxxxx>
>> 
>> ------------------------------------------------------------------------
>> 
>> 
>> 
>> PDE wouldn¹t let me export packages not defined in my plug-in.
>> 
>> BTW, I¹ve created a pretty simple class loading hook that works. I¹m
>> actually surprised the BundleLoader doesn¹t try something like this in
>> it¹s search algorithm.
>> 
>> @Override
>> public Class<?> postFindClass(String name, ModuleClassLoader
>>classLoader)
>> throws ClassNotFoundException {
>>   if (name.startsWith("javafx.") || name.startsWith("com.sun.glass") ||
>> name.startsWith("com.sun.javafx")) {
>>       return ClassLoader.getSystemClassLoader().loadClass(name);
>>   } else {
>>       return null;
>>   }
>> }
>> 
>> 
>> On 2/25/2014, 11:43 AM, "Alex Blewitt" <_alex.blewitt@xxxxxxxxxx
>> <mailto:alex.blewitt@xxxxxxxxx>> 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@xxxxxxxx
>>>><mailto: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?
>>>> 
>>>> Thanks,
>>>> Doug.
>>>> _______________________________________________
>>>> equinox-dev mailing list
>>>> _equinox-dev@xxxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>>>> _https://dev.eclipse.org/mailman/listinfo/equinox-dev_
>>>_______________________________________________
>>>equinox-dev mailing list
>>>_equinox-dev@xxxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>>>_https://dev.eclipse.org/mailman/listinfo/equinox-dev_
>> 
>> _______________________________________________
>> equinox-dev mailing list_
>> __equinox-dev@xxxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>_
>> __https://dev.eclipse.org/mailman/listinfo/equinox-dev_
>> 
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> 
>> [attachment "graycol.gif" deleted by Thomas Watson/Austin/IBM]
>> 
>> 
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> 
>
>_______________________________________________
>equinox-dev mailing list
>equinox-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/equinox-dev