Bug 257109

Comment 1 Boris Bokowski 2008-12-01 13:38:49 EST

Note that if org.eclipse.equinox.common moves to Foundation 1.1, Platform UI bundles requiring equinox.common and currently spec'd as Foundation 1.0 (e.g. JFace, org.eclipse.ui.workbench) would probably be moved to Foundation 1.1 as well.

Comment 2 Chris Goldthorpe 2008-12-01 13:39:10 EST

I am in favor of making this change. org.eclipse.help is in a similar situation
and the Foundation 1.0 restriction has the effect of tieing us to eight year
old technology in the form of the Java 1.3 jre even though the overwhelming
majority of users are using newer jres. 

Comment 3 Boris Bokowski 2008-12-01 13:43:28 EST

... should have added that we'd be doing it for three reasons:
1) We have a number of "impurities" in that not all of our code would actually
run on Foundation 1.0. Moving to Foundation 1.1 would mean fewer of these
impurities.
2) Same reason as given by John on the mailing list - there is no freely
available Foundation 1.0 class library.
3) We would like to make use of new features, such as exception chaining.

Comment 4 Thomas Watson 2008-12-01 13:56:03 EST

(In reply to comment #1)
> Note that if org.eclipse.equinox.common moves to Foundation 1.1, Platform UI
> bundles requiring equinox.common and currently spec'd as Foundation 1.0 (e.g.
> JFace, org.eclipse.ui.workbench) would probably be moved to Foundation 1.1 as
> well.
> 

I see you added comments to why you are doing this, which is good because folks should only move up if their own code needs features in a higher execution environment.

I will also add my +1 to this change.  This is a requirement in the Equinox framework in order for us to move up to the new OSGi APIs in the R4.2 specification.

Comment 5 Ken Walker 2008-12-01 14:47:27 EST

I would say that it is accurate that if someone were going to support CDC/Foundation on a newer device they would choose the 1.1 version of the specification.  It offers compatibility with at least Java 1.4.2 vs 1.3 on the old 1.0 release.

The only major shipping CDC/Foundation 1.0 platform of concern is the BD-J or Blu-ray Disk Java profile.  However, since this profile is usually burned into ROM or equivalently inaccessible for extension it is likely not a concern.

Comment 6 Jeff McAffer 2008-12-02 11:02:05 EST

I also agree with this change but want to echo Tom's points in comment 4.  Well said.

Comment 7 John Arthorne 2008-12-03 12:09:46 EST

We intend to resolve this by M4 next week.

Comment 8 Szymon Brandys 2008-12-04 07:16:15 EST

I would like to add org.eclipse.core.net and org.eclipse.ui.net to the list of platform plug-ins considered moving to Foundation-1.1.

We want to use URI in IProxyService API.

Comment 9 Remy Suen 2008-12-09 07:43:52 EST

(In reply to comment #3)
> 2) Same reason as given by John on the mailing list - there is no freely
> available Foundation 1.0 class library.

My google foo is a little weak here, where do I pick up a "freely available Foundation 1.1 class library"?

Comment 10 Oleg Besedin 2008-12-09 10:54:22 EST

Good question. One possible way to setup Foundation 1.1 environment is described here:

http://wiki.eclipse.org/J9

Comment 11 Remy Suen 2008-12-09 11:01:22 EST

(In reply to comment #10)
> Good question. One possible way to setup Foundation 1.1 environment is
> described here:
> 
> http://wiki.eclipse.org/J9

Seems like the Window builds have been removed though. :/

Comment 12 John Arthorne 2008-12-09 11:44:12 EST

We have foundation 1.1 class library stubs in org.eclipse.osgi/osgi/ee.foundation.jar for compile time. There is also a free Foundation 1.1 class library implementation here (although IBM employees can't download it for legal reasons):

https://phoneme.dev.java.net/downloads_page.html

Comment 13 John Arthorne 2008-12-11 11:38:46 EST

Based on this positive feedback, we are proceeding with moving bundles to Foundation 1.1 as required. We will be updating the EE information in the project plans (Eclipse and Equinox) as details become available.