harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FaeLLe <mrbillcollec...@gmail.com>
Subject Re: Backward compatibility
Date Wed, 11 May 2005 23:32:07 GMT
Very intresting and well noted writeup sir an insight from a Sun employee is 
always a bonus.

I will for sure followup comments on this article and see what the community 
has to say on this post.

On 5/11/05, Gerry Steele <gerry.steele@gmail.com> wrote:
> 
> I'm a big fan of the Apache foundation but this is one product I'm not too
> sure is such a good idea as of yet for reasons several:
> 
> >> Deprecated or non deprecated, we want Harmony to pass the TCK, so
> > >> whatever the TCK wants us to do, we'll do it.
> 
> I hope you understand what sticking to the TCK entails. When it comes to
> implementing GUI stuff for instance, your platform will have to fully copy
> the official JVM's Swing/AWT widgets and all other details in order for 
> the
> automation and robot driven tests to pass. The JCK testbase for tiger is
> immense. To get it setup and run is a skill on its own. To get it to pass
> all tests takes a serious am mount of tweaking and a noteable knowledge of
> the javatest harness. It will require implementations on things as 
> extensive
> as CORBA and RMI. We would need passive agents, tname servers etc.
> 
> Also, when running the TCK bear in mind that you'll have to run the 
> harness
> with the Sun VM.
> 
> I'm not sure about the particular extent of the testsuite provided with 
> the
> TCK you guys are talking about (if there is interest can find out more), 
> but
> the JCK, which is basically a TCK for the entire J2SE jre and jdk will be
> going on impossible to pass for an alternative implmentation as everything
> is written with the Sun JDK/JRE in mind and test cases are adapted in ways
> that will create an infinite unpredictable series of problems when trying 
> to
> adapt your code.
> 
> Another reason is that I'm not quite sure I see the point. It will take 
> 4-5
> years or more to even come close to a product like tiger. Sun are already
> working heavily on mustang and dolphin (to a lesser degree on the latter).
> As well as this, sun research have many projects looking at the future of
> the Java VM such as the Barcelona project which will drastically change 
> the
> implementation of the JVM. For instance to make it more network orientated
> or to improve resource sharing.
> 
> The latter things (which are yet to see real sun implementation) might be
> something you guys might then want to take advantage of in order to 
> leverage
> a selling point of Harmony. Without something like that it's just another
> attempt at a VM that will be playing catch-up forever.
> 
> Also, don't forget about quality. Sun put a serious amount of money and
> manpower into ensuring the quality and compatibility of the JVM. A lot of
> corporations depend on this. They have a regular update release cycle. For
> instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 & 5.0_05.
> 
> In a project of this size some of the the test suites take several days to
> run. Some take many many hours of man power. For excessive thoroughness
> there also manual JCK and regression test suites. Which, trust me, will 
> not
> be performed by someone who isn't being paid for it. Things like this 
> don't
> fit well with the community model.
> 
> Another worry I have is that the effort here might be better redirect to
> some other project. We already have Java. Even if harmony does make it to 
> a
> useable release people will still prefer to use the Sun VM. It will be the
> platform people build on and it will be the one they trust.
> 
> I'll be very interested in how this turns out.
> 
> Regards,
> Gerry
> 
> 1) speed
> >
> > 2) portability (java is claimed to run 'everywhere', but in fact, it
> > runs only on a few operating systems, even fewer for 1.5)
> >
> > 3) configurability (I might want to tune it differently and, for
> > example, choose different thread/GC models)
> >
> > 4) implementation stategy (in macosx, multiple JVMs share 80% of their
> > memory, and some of Swing is native, therefore feels like the rest of
> > the OS and it's hardware accelerated)
> >
> > 5) internal modularity (we want diversity of implementation to drive
> > innovation in the VM space, both in and out companies and universities)
> >
> > And, last but not least, if Sun or other vendors that already have JVM
> > want to stop paying for all that development on their and want to start
> > sharing the development costs with the java ecosystem in general and
> > with a clear warranty that we will not try to pollute the stream we all
> > drink from, therefore want to contribute some of their code to Harmony,
> > we will welcome them with open arms.
> >
> > --
> > Stefano.
> >
> >
> 
> --
> Gerry Steele
> 
> x74521/+353-1-8199 521
> http://blogs.sun.com/roller/page/gerrys
> [gerry.steele@sun.com OR gerry.steele@gmail.com]
> 
> 


-- 
www.FaeLLe.com <http://www.FaeLLe.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message