+1 for what Chris said. Actually, forget about cell phones. Pick any embedded app. Ski lifts, trucks, bomb sniffers, routers, ticket kiosks, . These are all real world examples of embedded systems running Eclipse. There are a couple I'm not sure of the VM but most are running foundation something or other.
Now, consider downloaded apps. For whatever reason (not material here) many people feel the need to ship the JRE with their app as this is the tested configuration. Foundation JRE is small and therefore easy to see including in your app download. Aside, in an ironic twist, the IBM J9 Foundation JREs come in an InstallShield installer that runs Java. So the 6-8Mb Foundation 1.1 JRE actually comes as a 48MB download cause it includes the J2SE1.? JRE to run the installer. The right answer, IMO is what Chris said. Regardless of the dependency (JRE, other bundles, .). Unless there is real value in consuming something, don't do it. Failure to follow this minimalistic principle leads to bloat-ware like RAD and RSA. It is fine for product teams to decide that they don't care about size/dependencies/JREs (for whatever reason) but Eclipse is a PLATFORM. As producers we have to keep in mind the needs of our consumers. Our consumers are all over the map on this. Clearly there is a tradeoff. If there is real value, I am all for moving forward. Convenience in writing for loops does not count. For areas where there are improvements in 1.5 etc, it is useful to distinguish between language features and class lib features. For class lib features often these are simply included in the JRE but are not exclusive to that JRE level (e.g., javax.management or JMX). You can get implementations for a wide range of JREs. For genuine, JRE level class lib improvements, great! Write a bundle that leverages those improvements and works if the underlying JRE has the features. People who want that can make their choice as consumers building their products. Again, we are producers and don't have that information. Jeff From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Besedin Sent: Thursday, April 17, 2008 3:34 PM To: E4 developer list Subject: Re: [eclipse-incubator-e4-dev] e4 and J2SE-1.5 I think minimum execution environment is an important question that should not be taken lightly. There is a non-trivial cost to staying on Java 1.4. Aside from obvious (how many times did you write a for-all loop this week?), there are enhancements that are hard or impossible to retrofit into 1.4 VMs. Two such places I personally encountered were in the profiling and security. In addition, there are questions of VM bug fixes added in new releases, support from VM vendors, and increased testing as the list of supported VMs gets longer over time. Another observation is that cell phones and devices don't seem to market their products as Foundation 1.x - rather as some mix of CLDC, MIDP, and device-specific JSRs. So I have two questions: - In a cost/benefit approach are we prepared to accept limitations of staying on Java 1.4 for another 7 - 10 years? - What device developers are *really* interested in at this time and for 2010 - 2015? Thanks, Oleg "Christopher Aniszczyk" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/17/2008 02:24 PM Please respond to E4 developer list <[email protected]> To "E4 developer list" <[email protected]> cc Subject Re: [eclipse-incubator-e4-dev] e4 and J2SE-1.5 Let me state that that one of the goals of e4 should be working on various environments, platforms and thingamajiggers. Respecting your BREE is very important. I can't count how many times there has been cases where people wanted to use some component (e.g,., Draw2D/GEF) on a more restricted environment but they couldn't due to the BREE of the component. Personally, I think the way Eclipse respect's BREE's (http://www.eclipsecon.com/eclipse/development/eclipse_project_plan_3_4.html #Appendix1) has been one of our greatest strengths. It has enabled Eclipse technology to be reused on cell phones, embedded devices and even web browsers. With that goal in mind, crafting the BREEs for the e4 plug-ins should be done very carefully with these use cases in mind. On the whole, my recommendation has always been to target the minimum environment unless there's a valid reason not to do so. On Thu, Apr 17, 2008 at 1:09 PM, Ed Merks <[EMAIL PROTECTED]> wrote: Michael, I don't think so. The EMF 2.2 runtime, which the 2.4 tools can target, works with Foundation 1.1, so the options are all available. I'm not sure how much sense it makes for the platform to remain forever bound to Java 1.4, but obviously I can see that small footprint environments are stuck at Foundation 1.1. That being said, I see nothing about Java 5.0 that appears to be a barrier to building a Foundation 1.2 that's no bigger but just adopts the new language mechanisms... Ed Merks/Toronto/[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] 905-413-3265 (t/l 313) Michael Scharf <[EMAIL PROTECTED] indriver.com <http://indriver.com/> > To Sent by: E4 developer list eclipse-incubator <[EMAIL PROTECTED] [EMAIL PROTECTED] rg> clipse.org <http://clipse.org/> cc Subject 04/17/2008 02:00 [eclipse-incubator-e4-dev] e4 and PM J2SE-1.5 Please respond to E4 developer list <eclipse-incubato [EMAIL PROTECTED] org> Has there been a decision for e4 to use J2SE-1.5? In CVS four projects require J2SE-1.5: org.eclipse.e4.presentationmodel.pure.emf org.eclipse.e4.presentationmodel.pure.emf.workbench org.eclipse.e4.servlet org.eclipse.e4.servlet.starter Michael _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev -- Cheers, ~ Chris Aniszczyk _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
