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

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
>