Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

As already said, I also got the impression that the bundle's BREE could be the way to go. Having considered the ExecutionEnvironment guidelines at http://wiki.eclipse.org/Execution_Environments, and especially the section on 'XML and other optional JRE pieces', I think it pretty much burns down to the question of whether we want to/are able to regard JavaFX as an "optional JRE piece" or not. 

That is, the way we currently access JavaFX trough e(fx)clipse pretty much resembles what the ExecutionEnvironment guide describes as the recommended handling of an "optional JRE piece". However, as already laid out, I have the impression that the special constraints that hold for the org.eclipse.javafx bundle (which does not bundle any classes itself but only serves as a placeholder) will probably require some different handling compared to the org.w3c.dom bundle that is named as an example in the guide. In addition, only a client bundle's BREE will probably be able to capture its exact JavaFX version requirements, as the different JavaFX versions cannot be differentiated on the level of packages alone (even if the org.eclipse.javafx bundle would not use the version constraints on its package-exports like it currently does). On the other hand, as JavaFX is not JSRed (as indicated by Tom), we will probably end up with quite a few new EEs to handle that properly... 

Cheers
Alexander

Am 08.09.2014 um 18:31 schrieb Doug Schaefer <dschaefer@xxxxxxx>:

> I think I keep asking this question, but isn't there a way to define a new execution environment to describe the environment that enables JavaFX on Java 8? I thought that's what they were for.
> 
> Sent from my BlackBerry 10 smartphone on the Rogers network.
>  Original Message
> From: Tom Schindl
> Sent: Monday, September 8, 2014 4:09 AM
> To: cross-project-issues-dev@xxxxxxxxxxx
> Reply To: Cross project issues
> Subject: Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
> 
> 
> Hi,
> 
> From a e(fx)clipse point of view we will load the javafx libraries from
> the JRE you are running on and JavaFX is a singleton like anything you
> get from the JRE as well (you can not load multiple version of javafx at
> once!), if you are running on JRE 1.7 you get JavaFX 2.2 classes if you
> run on JRE 1.8 you get JavaFX8 classes.
> 
> If you require Java8 features you need *your* bundle to require a an EE
> for JavaSE-1.8 (in reality this might not be enough because what you'd
> really want to spec is that you want OpenJDK/OracleJDK 1.8!).
> 
> Our fake bundle will never define an EE itself.
> 
> Please also note that because JavaFX is NOT JSRed they are adding
> methods and features inside Java8 releases as well so an EE (e.g. in
> 8u40 you get a Dialog-API, ...).
> 
> The versioned package exports only tell you in which JavaFX release the
> package was exposed the first time - I know this is not proper use of
> OSGi-Versions and maybe we should have omitted them completely but that
> would be a breaking change for anyone out there having versioned package
> imports on the other had simply updateing them to javafx 8.0 seems
> invalid as well.
> 
> In case there's consensus from people here that our version package
> exports are so wrong that this blocks integration I'm willing to break
> people and require them to update their applications to use unversion
> package imports.
> 
> Tom
> 
> On 07.09.14 11:57, Alexander Nyßen wrote:
>> Let me add another question to this discussion: As JavaFX 8 is now
>> around (in addition to JavaFX 2.2), what will be the strategy to deal
>> with the different JavaFX versions?
>> 
>> Up to now it seems the org.eclipse.javafx bundle exports the javafx
>> packages with version constraints. As its a singleton, there will only
>> be one org.eclipse.javafx bundle in an Eclipse installation, and for
>> clients (with package imports) the available JavaFX version will thus
>> depend on that bundle's package exports. However, org.eclipse.javafx is
>> just a dummy bundle, so the version of the actually loaded JavaFX
>> classes will IMHO depend on the JRE that was used to start the
>> application (or whatever strategy the org.eclipse.fx.osgi fragment uses
>> to locate them).
>> 
>> How can you ensure that stays consistent? Doesn't it mean you will have
>> to remove the version constraints from the org.eclipse.javafx bundle as
>> soon as you are going to support multiple JavaFX versions (so the
>> version will be decided at runtime when org.eclipse.fx.osgi loads the
>> classes)? And wouldn't that imply that clients could also not specify
>> version constraints on their package imports, because these could
>> otherwise not be resolved? If this was the case, then would not the
>> bundle's BREE be the right  indicator for its required JavaFX version
>> (as its done for all other JRE provided classes; of course implicating
>> some support for JavaFX within the Execution Environment Descriptors)?
>> Or does it mean for Mars there will only be an org.eclipse.javafx bundle
>> that is bound to BREE 1.8 and exposes JavaFX 8 only (and there will be
>> no support for JavaFX 2.2 and BREE 1.7)?
>> 
>> Cheers
>> Alexander
>> 
>> Am 22.08.2014 um 09:17 schrieb Alexander Nyßen
>> <Alexander.Nyssen@xxxxxxxxx <mailto:Alexander.Nyssen@xxxxxxxxx>>:
>> 
>>> Tom,
>>> 
>>>> 
>>>>> I suppose all this means that no bundle with javafx dependencies can
>>>>> resolve or run without this specific org.eclipse.fx.javafx bundle being
>>>>> present.  Again, it's none of my personal business, but if this is
>>>>> indeed the only solution, would Orbit be a better host for such a thing?
>>>> 
>>>> org.eclipse.fx.javafx and org.eclipse.fx.osgi have to be in your runtime.
>>> 
>>> what I infer from your detailed elaboration (thanks for bringing light
>>> into the darkness) is that it would make no sense at all to separate
>>> org.eclipse.fx.javafx from org.eclipse.fx.osgi, because without the
>>> org.eclipse.fx.osgi fragment the org.eclipse.javafx bundle would be
>>> useless at runtime.
>>> 
>>> Nevertheless, couldn't it be an option to have both within Orbit? From
>>> a (simrel) participant client's perspective this could make things
>>> easier (but probably only if these bundle would then also be provided
>>> by some +0 component).
>>> 
>>>> 
>>>> Tom
>>> 
>>> Cheers
>>> Alexander
>>> 
>>>> 
>>>> [1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.osgi/src/org/eclipse/fx/osgi/fxloader/FXClassLoader.java
>>>> _______________________________________________
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@xxxxxxxxxxx
>>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>>> To change your delivery options, retrieve your password, or
>>>> unsubscribe from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>> 
>>> --
>>> Dr. Alexander Nyßen
>>> Dipl.-Inform.
>>> Software-Engineer
>>> 
>>> Telefon: +49 (0) 231 / 98 60-210
>>> Telefax: +49 (0) 231 / 98 60-211
>>> Mobil: +49 (0) 151 /  17396743
>>> 
>>> http://www.itemis.de <http://www.itemis.de/>
>>> alexander.nyssen@xxxxxxxxx <mailto:alexander.nyssen@xxxxxxxxx>
>>> 
>>> itemis AG
>>> Am Brambusch 15-24
>>> 44536 Lünen
>>> 
>>> Rechtlicher Hinweis:
>>> 
>>> Amtsgericht Dortmund, HRB 20621
>>> 
>>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek,
>>> Jens Trompeter, Sebastian Neus
>>> 
>>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael
>>> Neuhaus
>>> 
>>> 
>>> _______________________________________________
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@xxxxxxxxxxx
>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
>> --
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Software-Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-210
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de
>> alexander.nyssen@xxxxxxxxx <mailto:alexander.nyssen@xxxxxxxxx>
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek,
>> Jens Trompeter, Sebastian Neus
>> 
>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>> 
>> 
>> 
>> 
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nyssen@xxxxxxxxx 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Back to the top