harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Harmony and the future of Java
Date Sat, 25 Feb 2006 15:48:30 GMT
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.


Mime
View raw message