harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Date Sun, 26 Feb 2006 22:43:06 GMT

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?


> 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.

View raw message