harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Backward compatibility
Date Sun, 15 May 2005 16:12:49 GMT

On May 12, 2005, at 8:29 PM, FaeLLe wrote:

> Everytime i read posts from you lot at Apache i feel more conviced  
> this
> thing is going to be one huge success.

Thanks - we hope so.  It's going to be a lot of work by a lot of  
people...

>
> I cant imagine how convincing your salesmen must be !! (If you  
> indeed did
> have salesment to market).

At Apache? :)

geir

>
> On 5/13/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
>
>>
>> I didn't cc Gerry - I assume he's subscribed.
>>
>> On May 11, 2005, at 6:22 PM, Gerry Steele 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.
>>>
>>
>> Indeed. We face the same thing with the J2EE TCK. It's a lot of
>> work, but we've proven that it can be done in the Apache environment.
>>
>>
>>>
>>> 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.
>>>
>>
>> I believe that you may be mistaken, or it's just a problem of
>> phrasing :) I'm sure that any tests that are for specific extra-
>> specification Sun-specific behavior will be added to the exception
>> list and therefore not have to pass. We've run into a few things
>> like this w/ the TCK for J2EE. For me, they are just TCK
>> implementation mistakes, rather than any requirement to have Sun
>> implementations as part of the tested 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.
>>>
>>
>> It's clear that Sun does put a lot of effort into this. But don't
>> underestimate what an open source community can do.
>>
>>
>>>
>>> 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.
>>>
>>
>> We'll see :)
>>
>>
>>>
>>> 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.
>>>
>>
>> Yes - quality is a major factor here. If we can't have the same
>> quality, people won't care, and the code won't be used. That's been
>> something we've been aware of since day 1.
>>
>>
>>>
>>> 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.
>>>
>>
>> I'm not so sure. I can easily see that we can find people that would
>> want to be paid to do it, and people that might pay them to do it.
>> There's nothing wrong with commercial involvement in projects at
>> apache, as long as it's a standard Apache-style, transparent
>> meritocracy. Throughout the ASF, you'll find individuals
>> participating in projects that are paid by someone to do so.
>>
>>
>>>
>>> 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.
>>>
>>
>> As will we all. Please consider helping us out :)
>>
>> geir
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>
>
> -- 
> www.FaeLLe.com <http://www.FaeLLe.com>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message