Additional costs of supporting old platforms include the additional testing and infrastructure hit. Just avoiding use of Java 5 (or 6) features does not, of course, guarantee that an app will work on a 1.4 JRE; you need to actually test on that platform. In 2010 or whenever e4 debuts, will we still want to dedicate significant resources to testing on Java 1.4? Are we going to have enough test machines? Will we actually work to fix bugs even if they are found? Put it this way: if e4 were to ship in 2010, it should expect to be running first and foremost on Java 1.6, with strong support for Java 1.5 and with an awareness of Java 1.7. Those platforms will certainly be 90%+ of the market at that point, as certain as any prediction about the future can be. Can we afford to spend significant effort trying to ensure that an interesting subset of e4 runs on 1.4? Or would that effort better be spent on something else, even that choice it loses some potential users? ISTR there was a compile error recently because someone used a Java 1.4 language feature in a plug-in that needed to compile on 1.3. It wasn't me but it could have been; I learned on Java 5 and have never even touched Java 1.3 or lower. Three or four years from now (e4.2), will we be discouraging potential new developers, because of a requirement to support Java 1.4, a once-popular but dimly remembered platform? Abstractly I like the philosophy of "Unless there is real value in consuming something, don't do it", but the reality is that the bulk of the industry does move on, leaving a long tail behind. Serving that long tail is expensive and not always profitable. (I worked for years at a mainframe terminal emulation company...) This probably sounds like hyperbole, because right now Java 1.4 is still so mainstream that it's hard to imagine it feeling ancient. But I don't think that will be true two years from now. -walter
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff McAffer Sent: Thursday, April 17, 2008 7:26 PM To: 'E4 developer list' Subject: RE: [eclipse-incubator-e4-dev] e4 and J2SE-1.5 +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
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
