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 :-)
regards
damian
