harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Date Mon, 27 Feb 2006 08:24:43 GMT
Ah, I must say sorry at first, because I guess some confuse has been 
caused due to my typo on my proposal about the bug-compatible 
principles, O:-) , I copied it here:

<quote from posts before>
1. we should comply with spec
2. if RI is contradict with spec, and RI is not logical(sometimes it is 
very obvious, you know what I mean), we comply with RI; else, we discuss 
it case by case.
3. if spec is not so clear, we should comply with RI
4. if some application failing on that different behavior, we discuss it 
case by case

The second line, I meant to be:
2. if RI is contradict with spec, and RI is not logical(sometimes it is 
very obvious, you know what I mean), we comply with _*SPEC*_; else, we 
discuss it case by case.

The second principle is very important, and I made a typo on the most 
important word in this sentence, I'm really, really sorry about the 
confuse caused, I myself is almost faint when I found it just now :-[ . 

I think I'd better clarify my reasoning about this principle here again, 
we should comply with RI when spec is not clear, we can try to comply 
with RI when sometimes RI is different with spec and can justify itself. 
BUT sometimes, RI is not logical, and then we should comply with spec. 
As an example, I posted two test cases about RI's CharsetDecoder 
internal status, in which case, RI's behavior is contradict with spec at 
several places and it is not logical to be understood.

Mikhail Loenko wrote:
> 2006/2/27, Geir Magnusson Jr <geir@pobox.com>:
>> 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?
> As I understood people in this and similar threads tend to be compatible
> with the Spec rather then with RI (unless we prove that being incompatible
> with RI breaks some existing implementation)
> I'm trying to oppose that, I'd to be compatible with RI when in doubt.
> Thanks,
> Mikhail
>> 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
>>>>>> 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.

Paulex Yang
China Software Development Lab

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