[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Java8 and JavaFX8

Hi Neil,

Thanks for the insight into this. It's exactly this kind of information
we need to assemble to find a way to solve the problems we'll all face
with once JavaFX8 is shipped.

My believe is that Oracle will not ship OSGi enabled JavaFX-jars and I
think the decision to ship as part of the JRE/JDK is already made.

If I get you right equinox isn't following the other OSGi spec when only
consulting the bootcloader for the system bundle? Tom what is the reason
for that? Could equinox by default consult the extension classloader?

Tom

Am 06.11.12 22:42, schrieb Neil Bartlett:
> Tom,
> 
> I should point out that from a "pure" OSGi point of view, it should be
> no issue for these libraries to be part of the extension path. It's up
> to the launcher code that creates the OSGi framework to choose which
> packages should be exported from the system bundle. Ordinarily the
> launcher has visibility of all classes on the boot, extension and
> application classloaders.
> 
> In other words, it's an Eclipse-ism for the system bundle to only have
> visibility of the boot classloader, and for there to be no way to expose
> libraries from the extension classloader short of modifying the Eclipse
> configuration.
> 
> Naturally I would much prefer if JavaFX was delivered as ordinary JAR
> files (or even as OSGi bundles, now wouldn't THAT be nice...) rather
> than having to be on the extension classloader! However it would be
> inaccurate to say to Oracle that they're  "breaking OSGi", when they're
> really just breaking the way Eclipse uses OSGi.
> 
> Thanks,
> Neil
> 
> 
> 
>> Tom Schindl <mailto:tom.schindl@xxxxxxxxxxxxxxx>
>> 6 November 2012 20:55
>> Hi Mike,
>>
>> myself, Steve and others are currently discussing in a mail-thread and
>> I'm trying to find a way through the jungle ;-) There's no decision (at
>> least what an outsider knows) yet the first the idea was to put it on
>> the bootclasspath, now it is lib/ext.
>>
>> I've just started exploring today what lib/ext would mean to us (OSGi
>> users) and found out that it will cause us more trouble I first thought
>> it would. Before we (Equinox and maybe broader OSGi community) - looks
>> like I'm one of the few who cares about that - have understood the
>> problems and how we can address them I don't want to go on the openjfx
>> list.
>>
>> I hope to isolate the problem and actions we'll have to take for a)
>> (bootclasspath) or b) (extclasspath). Naturally we can live better with
>> a) but going to Oracle saying that they have to do a) to not break OSGi
>> and later on someone steps up saying that b) would have been possible is
>> not good - this naturally pretends that a) can be done which is probably
>> beyond javafx' influence.
>>
>> I'm not sure who is in charge of the javafx into jre classpath
>> integration which would certainly help to get us all together and having
>> a defined timeline when we can expect it to happen, so that we can give
>> feedback on ea builds.
>>
>> Tom
>>
>>
>>
>> Mike Milinkovich <mailto:mike.milinkovich@xxxxxxxxxxx>
>> 6 November 2012 20:34
>> Tom,
>>
>> Just curious - have you reported this as a bug at openjfx.org? There
>> should be time for Oracle to fix their packaging for 2013, no?
>>
>>
>> Mike Milinkovich
>> mike.milinkovich@xxxxxxxxxxx
>> +1.613.220.3223
>>
>> -----Original Message-----
>> From: Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
>> Sender: equinox-dev-bounces@xxxxxxxxxxx
>> Date: Tue, 6 Nov 2012 20:58:36
>> To: Equinox development mailing list<equinox-dev@xxxxxxxxxxx>
>> Reply-To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>> Subject: Re: [equinox-dev] Java8 and JavaFX8
>>
>> _______________________________________________
>> 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
>> Tom Schindl <mailto:tom.schindl@xxxxxxxxxxxxxxx>
>> 6 November 2012 19:58
>> For RCP that would work. The problem is that people might use it in an
>> existing OSGi app like the Eclipse IDE and there we probably should
>> and can not modify it.
>>
>> The really problem is caused by Oracle but i'd really don't want to
>> suffer our users from it. Do you have time for an IRC session this or
>> next week to discuss possible solutions?
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>> Am 06.11.2012 um 20:38 schrieb Thomas Watson <tjwatson@xxxxxxxxxx
>> <mailto:tjwatson@xxxxxxxxxx>>:
>>
>>> How about setting the configuration property
>>> osgi.frameworkParentClassloader=ext (see the
>>> osgi.frameworkParentClassloaderr option at
>>> http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html&cp=2_1_3_0)
>>>
>>> This should cause the class loader which loads the framework
>>> implementation (setup by the equinox.launcher) to use the extension
>>> class loader as the parent class loader.  This should allow the
>>> system bundle to export the packages available on the extension class
>>> path.
>>>
>>> Tom
>>>
>>>
>>>
>>> <graycol.gif>Tom Schindl ---11/06/2012 12:42:54 PM---Hi, To integrate
>>> JavaFX2 into Java7 I had to reside to nasty stuff like
>>>
>>> From: Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx
>>> <mailto:tom.schindl@xxxxxxxxxxxxxxx>>
>>> To: equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>,
>>> Date: 11/06/2012 12:42 PM
>>> Subject: [equinox-dev] Java8 and JavaFX8
>>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>>> <mailto:equinox-dev-bounces@xxxxxxxxxxx>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> Hi,
>>>
>>> To integrate JavaFX2 into Java7 I had to reside to nasty stuff like
>>> Adapter Hooks but I don't want to go into detail.
>>>
>>> My current concerns are the future. First of all JavaFX 8 although
>>> shipped with Oracle-JDK8 will not be JSRed so its packages can not get
>>> part of the Java8 profile.
>>>
>>> It currently looks like they are not getting on the bootclasspath but
>>> rather pushed into lib/ext. I've done some tests today and it looks like
>>> this lib/ext stuff is going give us some headaches because this means
>>> the javafx stuff is not going to be on the bootclasspath which the
>>> system.bundle delegates to, am I right with this?
>>>
>>> So what could be a runtime-solution? Would a OpenJDK8-Profile which
>>> exports JavaFX packages help us, or would it ran into the same problem
>>> that it will delegate to the bootclassloader whereas we'd need to
>>> consult the extension-classloader?
>>>
>>> Once we figured out how we can solve the problem at the runtime layer we
>>> can go the next step to tweak PDE in a way that it we can work with it.
>>>
>>> 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@xxxxxxxxxxx <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
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> Thomas Watson <mailto:tjwatson@xxxxxxxxxx>
>> 6 November 2012 19:38
>>
>> How about setting the configuration property
>> osgi.frameworkParentClassloader=ext (see the
>> osgi.frameworkParentClassloaderr option at
>> http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html&cp=2_1_3_0)
>>
>> This should cause the class loader which loads the framework
>> implementation (setup by the equinox.launcher) to use the extension
>> class loader as the parent class loader.  This should allow the system
>> bundle to export the packages available on the extension class path.
>>
>> Tom
>>
>>
>>
>> Inactive hide details for Tom Schindl ---11/06/2012 12:42:54 PM---Hi,
>> To integrate JavaFX2 into Java7 I had to reside to nasty Tom Schindl
>> ---11/06/2012 12:42:54 PM---Hi, To integrate JavaFX2 into Java7 I had
>> to reside to nasty stuff like
>>
>> From: Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
>> To: equinox-dev@xxxxxxxxxxx,
>> Date: 11/06/2012 12:42 PM
>> Subject: [equinox-dev] Java8 and JavaFX8
>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Hi,
>>
>> To integrate JavaFX2 into Java7 I had to reside to nasty stuff like
>> Adapter Hooks but I don't want to go into detail.
>>
>> My current concerns are the future. First of all JavaFX 8 although
>> shipped with Oracle-JDK8 will not be JSRed so its packages can not get
>> part of the Java8 profile.
>>
>> It currently looks like they are not getting on the bootclasspath but
>> rather pushed into lib/ext. I've done some tests today and it looks like
>> this lib/ext stuff is going give us some headaches because this means
>> the javafx stuff is not going to be on the bootclasspath which the
>> system.bundle delegates to, am I right with this?
>>
>> So what could be a runtime-solution? Would a OpenJDK8-Profile which
>> exports JavaFX packages help us, or would it ran into the same problem
>> that it will delegate to the bootclassloader whereas we'd need to
>> consult the extension-classloader?
>>
>> Once we figured out how we can solve the problem at the runtime layer we
>> can go the next step to tweak PDE in a way that it we can work with it.
>>
>> 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@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> Tom Schindl <mailto:tom.schindl@xxxxxxxxxxxxxxx>
>> 6 November 2012 18:42
>> Hi,
>>
>> To integrate JavaFX2 into Java7 I had to reside to nasty stuff like
>> Adapter Hooks but I don't want to go into detail.
>>
>> My current concerns are the future. First of all JavaFX 8 although
>> shipped with Oracle-JDK8 will not be JSRed so its packages can not get
>> part of the Java8 profile.
>>
>> It currently looks like they are not getting on the bootclasspath but
>> rather pushed into lib/ext. I've done some tests today and it looks like
>> this lib/ext stuff is going give us some headaches because this means
>> the javafx stuff is not going to be on the bootclasspath which the
>> system.bundle delegates to, am I right with this?
>>
>> So what could be a runtime-solution? Would a OpenJDK8-Profile which
>> exports JavaFX packages help us, or would it ran into the same problem
>> that it will delegate to the bootclassloader whereas we'd need to
>> consult the extension-classloader?
>>
>> Once we figured out how we can solve the problem at the runtime layer we
>> can go the next step to tweak PDE in a way that it we can work with it.
>>
>> Tom
>>
> 
> 
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 


-- 
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