Bugzilla – Full Text Bug Listing
| Summary: | [RCP] Use only Foundation classes for RCP | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jeff McAffer <jeffmcaffer> | ||||
| Component: | UI | Assignee: | Nick Edgar <n.a.edgar> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | douglas.pollock, eclipse, ed.burnette, jed.anderson, jeem, mfaraj, n.a.edgar, remy.suen | ||||
| Version: | 3.1 | ||||||
| Target Milestone: | 3.1 M7 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 77787 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
sigh. Submitted bug before the list was complete. Rebuliding the list here so
it is coherent. Ignore the previous list. The one here is complete as of the
code in HEAD today.
- Use of javax.xml.transform : classes in this package are used in
XMLMemento.save to write out the memento. There are several copies of
XMLWriter in the platform (resources, JDT and PDE all have them). XMLWriter is
a helper that does effective quoting etc. In the case fo XMLMemento.save you
have a document so the approach should be to traverse the document and call
methods on an XMLWriter.
- java.nio.charset : classes in here used in WorkbenchEncoding ot get
Charset.isSupported() and IllegalCharsetNameException. Replacements are
unclear.
- Nested expections : Foundation's Throwable does not have a constructor that
takes a nested throwables. The fix is obviously to remove the nesting but this
will eliminate some information. We may instead elect to introduce a subclass
which does have the nesting support. Affected areas:
- XMLMemento
- CommandException
- ContextException
- KeyAssistDialog
- WorkbenchKeyboard
- java.util.regex : Not sure what the replacement strategy would be. Used in
- IActivityPatternBinding
- Activity
- ActivityPaternBinding
- MutableActivityManager
- java.util.Bitset.nextBitSet() and .clear() : used in WorkbenchPartReference.
Change is unclear but likely not hard.
- Boolean.valueOf(boolean) : easily replaced. Used in
- WorkbenchWindow
- Character.toString() : easily replaced. Used in
- MacKeyFormatter
- NativeKeyFormatter
- CharacterKey
- KeySequence
- KeyStroke
- String.split()/.matches : easily replaced. Used in
- ConfigurationLogDefaultSection
- ColorsAndFontsPreferencePage
- ColorUtils
- java.awt and javax.swing : used in WidgetMethodHandler. Not sure what this
is used for. We may be able to leave this in and just compile against J2SE.
Presumably people using Foundation are not expecting to be using Swing and
AWT...
- Exception.getStackTrace : this appears to be used in some debugging code in
WorkbenchContextSupport. Unclear if it needs to remain or what the replacement
would be.
Just to be clear, are we talking about the Foundation Profile for J2ME
("http://java.sun.com/products/foundation/overview.html")?
I'm not sure this is a good idea. My main concern is this line
"java.util.regex : Not sure what the replacement strategy would be. Used in
IActivityPatternBinding". The use of regular expressions is exposed as API,
and implementing a regular expression library seems like a lot of work.
What embedded devices would only support the Foundation Profile, but still be
capable of supporting the kind of footprint the workbench brings along with it?
(I'm fishing for background, as this kind of comes out of the blue.)
I'm not sure, but you might also need to consider the use of "java.util.zip" (used in AboutBundleGroupData). As for the references to Swing, this is covered by Bug 77787. Yes, J2ME Foundation. This is not coming out of the blue. We have been talking about this for some time. The runtime, osgi, and update have all been moved onto Foundation. The background for this does include the desire to run Eclipse on embedded devices (witness the eRCP project) but it also includes RCP work to be able to ship products complete with VMs and have this be less than the 40MB required for a J2SE JRE. The Foundation VM and classlibs can be paired down to about 3MB and useful Foundation based Eclipse application shipped in well under 10MB complete and ready to run. My recompile of UI on Foundation did not find any problems with the Zip stuff. Is it API changes or functional changes that you are concerned about? Reading the foundation page, I did not see java.util.zip mentioned as an allowed packages. Maybe I just missed it.... Well, perhaps by out-of-the-blue, I mean, "I didn't see it on eclipse-dev." If it hasn't been mentioned, would it not be appropriate to do so? hmmm... I just stumbled onto this by mistake. I dont have much background about this, but if I understood this correctly, its for runnning RCP apps on something like a PDA. I would no like to see an rcp app with no intro :-) Jeff, is it beneficial to include the RCP "friends and family" plugins onto the board? Eventhough intro is an optional RCP plugin, it does declare to be RCP complaint. Not with this bug, maybe? Maybe there is a technical issue Im missing, but if I can try to make intro live on whatever minimalistic java class library you guys are talking about, why not. I would rather do little changes along the way, than be doing one big port to a smallet library, if need be. not sure if I am way off here, but just wrote what came to mind when I read this... This bug is directed particularly at the UI workbench. There are/were other bugs for other elements of RCP. Of course, I would never turn down an offer to make more plugins run in more places. And I agree that Intro is interesting and useful in RCP scenarios. Not sure that Intro on a PDA makes sense BUT, Eclipse on Foundation is NOT just a PDA play. Applications shipping today either have to assume that an acceptable JRE is present or ship one with their product. A 1.4 JRE is pretty big (e.g., 30-50MB depending). The VM and JCL for Foundation can be pared down to about 6MB. This is easily downloaded and pretty acceptable. So, yes, intro on Foundation might be interesting but it is not a plan item. Curently the only board of X's we have relates to dynamic behaviour. Having intro be dynanmic aware/enabled would be much more interesting than having it on Foundation (if I had to pick). Jeff, so I dont wanna polute this defect with irrelavent details then but my only point was that keeping rcp friendly plugins aware of the Foundation requirements is goodness. We can code with planning ahead. and btw, intro has been dynamically aware since 3.0. We listen/react to removal/additions of plugins correctly. I did that already for 3.0. Welcome for RCP aps is important. I just bought an HP iPack PDA and they have a nice getting started movie/flash welcome. Having said that, there are other priorities for intro, but staying in the loop would be beneficial because if I can avoid using an api upfront, that would be great. I've been going through the readme on Sun's JRE and it's pretty explicit about what is and is not allowed to be removed. If you remove all the optional things you still have a 57MB uncompressed footprint, or about 18MB compressed. The IBM JRE looks like it's in the same ballpark, maybe a little bigger. So where are you coming up with this 6MB JRE? I suspect you are looking at J2SE related information. We are talking about CDC Foundation here. All those embedded Java systems out there are not running on 50+MB Java installs! Yes, but in comment #7 you said "Eclipse on Foundation is NOT just a PDA play... The VM and JCL for Foundation... can be pared down to about 6MB. This is easily downloaded". I'm asking where this non-PDA 6MB VM is downloadable from. RCP products for the desktop that didn't want to assume a JRE is present could be shipped with this instead, if they used the Foundation subset. There is nothing special about Foundation wrt VMs. It is the class library. Foundation configruations are available for pretty much any platform. My comment about "easily downloaded" refers to the size of the app/VM combo. That is, telling someone to download 10MB to get your product (3MB of your code + 6MB of VM/JCL) is way better than telling them to download 50-60MB (3MB of your code + 50MB of VM/JCL). As for actual sources, there are several VM vendors that supply this. I know IBM does for many platforms. At any rate, the point of this bug report is that without some changes to the Eclipse code base, it is all quite academic. Assigning to Nick to get this out of the bucket. cool, can I assign some of my bugs to Nick to get them out of my bucket? Created attachment 20159 [details]
patch to get XMLMemento off XML Transform
While reviewing API changes: - org.eclipse.ui.commands.CommandException.getCause() - missing @since 3.1 tag - this class is deprecated (do we need to be fixing too?) > this class is deprecated (do we need to be fixing too?)
Yes. All code in the generic workbench and its prerequisites needs to compile
against JCL Foundation (plus a few other bits).
I've tagged the following other cases as @since 3.1.
org.eclipse.core.commands.common.CommandException.getCause()
org.eclipse.jface.resource.DeviceResourceException.getCause()
org.eclipse.ui.commands.CommandException.getCause()
org.eclipse.ui.contexts.ContextException.getCause()
org.eclipse.ui.internal.components.framework.ComponentException.getCause()
Changes released. There are still compilation dependencies on java.util.regex.Pattern in [I]ActivityPatternBinding, but if Pattern is not available, activities are not read from the registry and this code is not reached. Verified in I20050509-2010. |
For 3.1 we want to have all Elcipse RCP plugins using only the JCL Foundation class library. In general there are very few types of changes needed to do this. Below is a list of the kinds of changes and some examples of where they occur. - Use of javax.xml.transform : classes in this package are used in XMLMemento.save to write out the memento. There are several copies of XMLWriter in the platform (resources, JDT and PDE all have them). XMLWriter is a helper that does effective quoting etc. In the case fo XMLMemento.save you have a document so the approach should be to traverse the document and call methods on an XMLWriter. - java.nio.charset : classes in here used in WorkbenchEncoding ot get Charset.isSupported() and IllegalCharsetNameException. Replacements are unclear. - Nested expections : Foundation's Throwable does not have a constructor that takes a nested throwables. The fix is obviously to remove the nesting but this will eliminate some information. We may instead elect to introduce a subclass which does have the nesting support. Affected areas: - XMLMemento - CommandException - ContextException - java.util.regex : Not sure what the replacement strategy would be. Used in - IActivityPatternBinding - java.util.Bitset.nextBitSet() and .clear() : used in WorkbenchPartReference. Change is unclear but likely not hard. - Boolean.valueOf(boolean) : easily replaced. Used in - WorkbenchWindow - String.split() : easily replaced. Used in - ConfigurationLogDefaultSection