harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karen Bennet <benne...@yahoo.com>
Subject Re: Backward compatibility
Date Thu, 12 May 2005 00:59:25 GMT

Gerry,

Additional help in testing is always welcome. However,

your posting makes me wonder why Sun wouldn't enable
this project to leapfrog whose 4-5 years to a product
like Tiger by donating the missing pieces.   This
would enable the community to work alongside Sun in
the development of mustang and dolphin in an
collaborative development model.  I'm not sure if
feasibility or not 
but you did say if there was anything that you could
do to help ...  maybe an internal Sun employee might
have a better chance of convincing their employer that
collaboration around this technology would benefit
them and potentially get Java development accelerated
with future ideas.

P.S. I know there have been many before who have asked
 for this same request; but here's hoping that its
reconsidered. 

 
--- Gerry Steele <gegerrytsteelemgmailom> wrote:

> Hi
> 
> I actually did seem a bit cynical there.
> 
> I forgot to mention that if there is anything I can
> do to help let me know 
> or perhaps I'll keep an eye on the lists. I've
> experience with the JCJCK 
> other tests so I could be useful in the QA area
> considering it's quite an 
> esoteric task. I do believe that variety and
> competition is good in software 
> for everyone. Though I do feel a bit sorry for sun..
> they put up the money 
> to develop and create the Java world we have now and
> everyone seems to want 
> it for their own. And they don't exactly ask for a
> lot from users..... just 
> remember that the nearest competitor costs a small
> fortune.
> 
> Another sisidenotes Project Peabody. All those bugs
> in Mustang that have 
> been bothering you are now open to anyone to submit
> fixes. 
>
hthttp/jajavaun.com/developer/tetechnicalArticles2SE/pepeabody
> 
> And you get a free t-shirt when you contribute!
> 
> Gerry
> 
> On 5/12/05, FaFaeLLemrmrbillcollectormgmailom>
> wrote:
> > 
> > Very inintrestingnd 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 < gegerrytsteelemgmailom>
> 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 TCTCKso
> > > > >> whatever the TCTCKants us to do, we'll do
> it.
> > > 
> > > I hope you understand what sticking to the
TCTCK> entails. When it comes to 
> > > 
> > > implementing GUI stuff for instance, your
> platform will have to fully 
> > > copy
> > > the official JVJVM'swing/AWAWTidgets and all
> other details in order for 
> > > the
> > > automation and robot driven tests to pass. The
> JCJCKetestbaseor 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 nonoteablenowledge 
> > > of
> > > the jajavatestarness. It will require
> implementations on things as 
> > > extensive 
> > > as COCORBAnd RMRMIWe would need passive agents,
> tntnameervers etc.
> > > 
> > > Also, when running the TCTCKear in mind that
> you'll have to run the 
> > > harness
> > > with the Sun VMVM
> > > 
> > > I'm not sure about the particular extent of the
> tetestsuiterovided with 
> > > the 
> > > TCTCKou guys are talking about (if there is
> interest can find out more), 
> > > but
> > > the JCJCKwhich is basically a TCTCKor the entire
> J2SE jrjrend jdjdkill 
> > > be
> > > going on impossible to pass for an alternative
> imimplmentations 
> > > everything 
> > > is written with the Sun JDJDKRJREn 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 VMVMuch as the Barcelona project which
> will drastically change 
> > > the
> > > implementation of the JVJVMFor 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 VMVMhat 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 JVJVMA 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 JCJCKnd 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
> > > ususeableelease people will still prefer to use
> the Sun VMVMIt 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 (jajavas claimed to run
> 'everywhere', but in fact, it
> > > > runs only on a few operating systems, even
> fewer for 1.5)
> > > >
> > > > 3) coconfigurabilityI might want to tune it
> differently and, for
> > > > example, choose different thread/GCGCodels)
> > > >
> > > > 4) implementation ststategyin mamacosxmultiple
> JVJVMshare 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 VMVMpace, both in and out
> companies and 
> 
=== message truncated ===


		
Discover Yahoo! 
Stay in touch with email, IM, photo sharing and more. Check it out! 
http://discover.yahoo.com/stayintouch.html

Mime
View raw message