[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse-incubator-e4-dev] e4 and J2SE-1.5
|
(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"
<caniszczyk@xxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
04/18/2008 11:32 AM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx> |
|
To
| "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
|
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 <eclipse@xxxxxxxxxxxxxx>
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: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx]
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
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
--
Cheers,
~ Chris Aniszczyk _______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev