harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damian Hamill <dam...@herculeez.com>
Subject Re: Harmony and the future of Java
Date Mon, 27 Feb 2006 17:09:10 GMT
Dalibor Topic wrote:
> Damian Hamill <damian <at> herculeez.com> writes:
>> If most/all of the classes were like this then the class library zip
>> file would be very small.  The same goes for the other programs and
>> dlls, if they are not part of the JVM core and needed by every
>> applet/application that runs then make them stubs that download the
>> real thing when they are used the first time.
> That's an interesting idea, but unfortunately, it can't be done in an
> implementation that wants to be certified as Java compatible, like Harmony,
> since the VM + class library that you ship needs to be certified as compatible,
> not the VM + class library + something you download on demand from some server
> if you have a network connection around. The fundamental problem with the idea
> is that you end up effectively subsetting J2SE, and the current rules do not
> allow for that, a J2SE implementation always needs to behave as one, even
> without a network connection. :)

I think this scenario only applies when there is a network connection, 
we are talking about Applets in web pages after all.

I understand that from the Harmony project point of view the goal is to 
be certified as Java compatible.  From a USER point of view I am less 
concerned about Java certification, all I care about is getting my 
Applets to run in the users browser before they hit the back button and 
when they are running to be able to do useful things.

Can we have a  distribution of Harmony that complies with Java 
certification and add whatever is required to build an on-demand version 
so as a developer/distributor I can choose what technologies I adopt for 
the distribution and execution of my Applets ? 

This argument goes way beyond the JVM and classlib, it also applies to 
all the useful stuff we use from jakarta commons etc.  That all adds to 
the overall download.  My Applet is ~200kb but once I add JDOM (148kb), 
commons-httpclient (284kb) and commons-logging etc I am up to ~700kb, 
when I add audio there is another 316kb and charts add another 1.3MB and 
I bet I am using only a small percentage of the classes in these 
distributions.  Then there is the JMF which looks useful but isn't part 
of the standard JRE so I can't use it.  I am just not going to ask users 
to download and install another Java installation so I can play a video 
- I think I'll use Flash instead.

If the classes our programs/applets use are downloaded on-demand and 
cached locally things will be a lot easier and quicker next time 
around.  If my Java Applet needs the user to jump through a load of 
hoops in order to run but my competitors ActiveX control runs out of the 
box the choice for the user is easy and I will be faced with the choice 
of sinking with Java or swimming with ActiveX.

So from my user perspective I need the barriers of entry to be removed 
so I can continue to use Java and continue to benefit from the wide 
variety of open source Java software that I can use in my projects.  
 From my perspective those barriers are;

1) seamless and efficient download and execution
2) a security regime based on user interaction or trust metrics

uhmmmm... can I start hacking :-)


View raw message