Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <44022EFA.5010908@pobox.com>
Date: Sun, 26 Feb 2006 17:43:06 -0500
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Do we want to be bug compatible? (was: Re: newbie to
 project-where
 to start from)
References: <906dd82e0602181003i78fc954erdf85942536644be9@mail.gmail.com>
	 <43F7996A.7000401@pobox.com>
	 <46d21a9a0602200020g217da660laa1c7a282a3e8af4@mail.gmail.com>
	 <906dd82e0602200041r22ab1c7ge8fb360f14c9ec55@mail.gmail.com>
	 <46d21a9a0602200206h74fac9d8v2b99bfc514155a39@mail.gmail.com>
	 <906dd82e0602200220v55490c5x8d4df31903912dac@mail.gmail.com>
	 <46d21a9a0602200335y3e30570ercd2e47762301d9fa@mail.gmail.com>
	 <43F9B75E.9070400@gmail.com>
 <906dd82e0602200511m79e0c5eekef31a8f0c30e6971@mail.gmail.com>
In-Reply-To: <906dd82e0602200511m79e0c5eekef31a8f0c30e6971@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Mikhail Loenko wrote:
> How will we verify Harmony with all existing apps in the world?

Gump :)

> 
> Why should we cross fingers and believe that most of the users do
> not have such apps rather then make it compatible with RI and be
> [almost] sure that all apps working on RI will work on Harmony?

I'm confused.  Isn't that one of our principles?  On a case by case 
basis, examine our deviance from RI or spec, but lean towards making 
compatible with RI?

geir

> 
> Thanks,
> Mikhail
> 
> On 2/20/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> I agree Anton, these are the right guiding principles and the proof will
>> be in running apps.
>>
>> Regards,
>> Tim
>>
>> Anton Avtamonov wrote:
>>> On 2/20/06, Mikhail Loenko <mloenko@gmail.com> wrote:
>>>> Well seems like we all agree with the general approach.
>>> Yes. Agree.
>>>
>>>> But...
>>>>
>>>> :)
>>>>
>>>> I do not agree with the specific case you describe: NPE vs. IAE.
>>>>
>>>> I can imagine a programmer who does not read the spec, who
>>>> does not want to check for null, who just makes 'catch NPE' somewhere
>>> Mikhail, I definitely can imagine the same story. I only want to have
>>> such application first. Then we will be able to judge and decide what
>>> to do. Before that no need to deviate from spec (of cource, excepting
>>> the cases when spec itself contains bugs as in my example with
>>> GrayFilter when required exception is missed from spec).
>>> In your example, such 'professional' developer most likely catches
>>> just Exception rather then the particular one :-)
>>>
>>>> And his app would work well on RI and fail with uncaught IAE on Harmony
>>>> if we follow the spec. So, what is the reason in this very specific case
>>>> to firmly follow the spec?
>>> Because NPE (IMHO) is not well-defined way to inform the developer
>>> something is wrong with his/her code. It just shows 'something inside
>>> implementation' fails (excluding cases when NPE contains proper
>>> message and is thrown intentively).
>>> In opposite, IAE always shows programmer called the method with wrong
>>> input values. All is about better notation only.
>>> In case existing program specified percentage outside the reasonable
>>> range, for instance, and worked anyway it may be even better to
>>> clearly inform the developer something is wrong with the program.
>>> Because in reality there were no garantee that such incorrect code
>>> worked properly on Sun's impl: just a play of chance. Of course we
>>> should not add more exceptions than exist in code/spec (at least for
>>> now), but try to use 'proper' exceptions with better notation clear
>>> for the developers.
>>>
>>> I propose to continue this discussion when we have real examples, i.e.
>>> real applications failed because of such differences or particular
>>> methods which can potentially fail applications... Otherwise the
>>> discussion is quite abstract... Just IMHO.
>>>
>>> --
>>> Anton Avtamonov,
>>> Intel Middleware Products Division
>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
> 
>