+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:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] 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" <caniszczyk@xxxxxxxxx>
Sent by:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
04/17/2008
02:24 PM
|
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
|
|
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 <merks@xxxxxxxxxx>
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/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Michael Scharf
<Michael.Scharf@w
indriver.com>
To
Sent by:
E4 developer list
eclipse-incubator
<eclipse-incubator-e4-dev@eclipse.o
-e4-dev-bounces@e
rg>
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
r-e4-dev@eclipse.
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
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
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
