(I'm enjoying the Chris and Jeff luv-in here <g>). I didn't get the sense that people didn't agree that its important that, as a framework. Eclipse be applicable to a wide set of usages. I think folks are just trying to understand the cost benefit, 2 years out.
Personally I don't find it productive trying to make these decisions in the abstract. If for example the web portion required java 1.5 to function (don't know if that's true, just suppose), then well that'd be a pretty strong argument for 1.5. In the absence of hard requirements for 1.5 then I agree we should remain as minimal as reasonably possible. Of course then we need to figure out what "reasonable" means... Our requirements will become clear as we progress on doing the real work. Kevin "Christopher Aniszczyk" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/18/2008 11:32 AM 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 I'll reiterate what Jeff said again. Eclipse is a platform. It needs to be able to run on various things. The core pieces of Eclipse are extra sensitive to this effort. The same logic should be followed with UI bits and pieces. People have to get out of their head that Eclipse is just about being on the desktop where the Java technology tends to be bleeding edge. Eclipse technology runs on devices, servers, my BMW 7 series that I dreamed about last night, SKI LIFTS (where? do they have openings ;p) etc... things tend to be behind due to the constrained environments. Eclipse has a very good story set out for itself if you can state that you can reuse components and skills across platforms. I dream of a world where an Eclipse plug-in developer can reuse his skills to create web applications, embedded applications, desktop applications and whatever other application platform is based on Eclipse. Will Java change in the future? Sure ( http://gizmodo.com/gadgets/cellphones/sun-scrapping-mobile-java-moving-devices-to-standard-java-313589.php ). If e4 is componentized in a good way, we should be able to keep old bundles that run on older platforms while building new plug-ins that run on newer platforms. The challenging thing is going to be to decide how to componentize things in a environment sensitive way while not inhibiting innovation. On Fri, Apr 18, 2008 at 1:00 AM, Walter Harley <[EMAIL PROTECTED]> wrote: 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 -- 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
