Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)


Following up my last mail on all this stuff. I had a meeting on IRC with
Tom Watson, discussing how one could make use of none public packages.

Normally I'd say to anyone that they should not use them because they
are an implementation detail of your JRE. The problem as it looks like
today is that JavaFX is not JSRed and hence not part of a EE-profile.

The current thinking is that it will endup in the ext/lib directory in
Java8 (and maybe one of the Java7-Updates) and so if people want to use
it in OSGi-Envs they need to get access to it.

There are 2 sides of the problem:
a) Runtime: How can we provide people access to javafx-Classes
b) Tooling: How can people make use of javafx-Classes inside their IDE
   (Bnd, PDE)

Tom Watson and myself came to the conclusion that the best solution to
provide people access to the none-public packages is to provide a
fragment to the system.bundle who itself has no source but exports the
javafx-packages, so that developers can use them in their app bundles.

An equinox specific problem in this regard is that equinox normally only
consults the bootclassloader for classes because of history reasons so
the fragment we'll have to provide has some equinox specific setting:

> Manifest-Version: 1.0
> Bundle-ManifestVersion: 2
> Bundle-Name: Myext
> Bundle-SymbolicName: javafx.bundle
> Bundle-Version: 8.0.0.qualifier
> Fragment-Host: system.bundle; extension:=extclasspath
> Bundle-RequiredExecutionEnvironment: JavaSE-1.6
> Export-Package: javafx

Would this extension:=extclasspath cause problems to other
OSGi-Implementations like e.g. felix?

The final question is which of the packages of javafx we'll export.
JavaFX is quite young and sometimes people have to reside to internal
APIs to implement things, so I think we need to be pragmatic and export
also none-public packages but mark them as x-internal:=true. Any objections?

Neil told me that BND-Tools already picked up stuff from the
system.bundle fragments and so I hope it simply works but I have not tested.

PDE does not pick up the stuff but consults the EE when createing the
JRE Classpath Container and setting up the accessible rules for it. In
reality this stuff is not done by PDE but JDT-Launch where all this
stuff is handled. That's the bad news. The good one is that
JDT-Launching has an extension point allowing us to contribute to the
access rules and so we can provide a plugin which adds access rules for
javafx-packages when we detect a Java8 EE (not sure yet how this
Compact1, ... is going to be handled).

We have a plan, a working prototype how we can integrate ext/lib or more
generally none public JRE-packages into the runtime. The tooling already
as of Eclipse 3.3 provides the needed hooks we need to provide the
tooling integration.


B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
tom schindl                 geschäftsführer/CEO
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833                      phone    ++43 512 935834

Back to the top