|
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
+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
|
