Hi, 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) Runtime: -------- 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? (Eclipse)Tooling: ----------------- BND-Tools: ---------- 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: ---- 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). Summary: -------- 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. Tom -- 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 http://www.BestSolution.at phone ++43 512 935834 _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev