Damian Hamill wrote:
Stefano Mazzocchi wrote:
I agree with you (and Ben) about the fact that monoculture brings
stagnation, but I don't think this is a good place for talking about
"java innovations".
<hat type="project mentor">
This project is about implement a JVM as specified by the JCP, of
which the ASF is part of.
Changing and influencing that JVM spec is out of scope it if brings
incompatibilities that will preclude passing the certification stage.
</hat>
This said, it is not impossible for Harmony to be instrumental in
showing that additions to the JVM might be beneficial for the outside
world and therefore submit them for review to the JCP.
There is *nothing* that prevents us from implementing harmony-specific
features, if this doesn't stop us from passing the TCK.
This is my cue;
I joined the list a few days ago and I got here as a result of reading the
"Java: Dead Like COBOL, Not Like Elvis?" thread on TheServerside
http://www.theserverside.com/news/thread.tss?thread_id=39066.
In a couple of posts by Dalibor Topic (a developer on GNU Classpath
and Kaffe OpenVM) he asserted that Java developers will move on to
.NET and he used this phrase "just like how applets were replaced by
Flash". He also said
"For example, you can write neat GUI applications for Windows today
using Java5 and/or SWT. Once Vista ships with bundled Whidbey, though,
GUI application developers on Windows will be facing an interesting
choice: n MB for a C# application on Whidbey, or n MB + sizeof(Sun JRE
1.6) for a Java application. As we've seen with applets vs flash,
there is a very simple answer: the ubiquitous one wins. See Netscape
vs IE, which was decided the moment Microsoft bundled the browser with
the OS."
I started to wonder if I should switch to c# .NET. I would rather
stick with Java but the 16MB JRE download is a killer. Unless Java
Applets are as easy for the user as other technologies then they will
be second choice for developers. I believe there is a solution but it
means changing the way classes are loaded, but it may take the JVM
out of spec, I don't know.
The problem is that before you start to run your applet you have to
download and install everything that makes up the JRE including
classes, programs and dlls that your applet will never use. A better
solution would be to download and install the core JVM and the classes
your applet uses only. Everything else should be downloaded on
demand e.g.
package javax.sql.rowset;
public abstract class BaseRowSet implements Serializable, Cloneable {
public static String classSourceURL =
"http://www.mydistribution-server.com/cgi-bin/classServer.cgi";;
// nothing else defined in this stub class. }
The class loader finds a class with only the classSourceURL field and
uses the URL in the field to download the real class passing the fully
qualified class name as an argument. The class server can return a
zip file with the named class and all the classes it depends on.
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.
So I found my way to Harmony in the hope that I can help and this is
the area I would like to get involved in.
BTW My 2 cents on the local (HTTP/FTP/SMTP) server issue is to
implement the servers as Java classes, the protocols are simple and a
lot of that code exists in apacheland anyway.
And who's going to pay for that bandwidth?
--
Stefano.
