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 Tue, 21 Feb 2006 02:52:15 GMT
I need to read the whole thread (will do it on plane tomorrow) but just 
a couple of quick notes...

Vladimir Gorr wrote:
> In my opinion we should not wait when Harmony users let us know about our
> incompatibility.
> We need to hurry and to eliminate this as soon as possible. Otherwise we
> will not be successful.
> All existent (well-known) applications have been already tuned for RI.
> Therefore we also need to carry for the compatibility
> if we wish to run these applications. First thing would like to mention once
> more about is TCK. If we will have a license

We will have a license at some point.

> for it we can resolve a lot of our problem on early stage project.  Is it
> reasonable to think about this? Is it possible to have this license for
> Harmony? Or is it unrealizable thing?

Nope, that's very realistic.  We're doing a compatible implementation, 
and we'll need the TCK.

I foresee few problems getting a TCK :)


> *Thank you.*
> *--------------*
> *Vladimir Gorr*
> Intel Middleware Products Division.
> On 2/20/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
>> On 2/20/06, Mikhail Loenko <mloenko@gmail.com> wrote:
>>> How will we verify Harmony with all existing apps in the world?
>> Certainly there is no way to verify Harmony with all existing apps
>> ourselves. But, it looks like we do have a bug reporting system which
>> would allow Harmony users to let us know about possible binary
>> incompatibilities with RI (which might be critical for them for some
>> reason). We could consider and fix (or not fix) such incompatibilities
>> on a case-by-case basis, depending on the importance of a particular
>> application.
>> Gerry did an excellent note earlier in this thread that there is an
>> appeal process which can help to fix the spec/RI inconsistencies. In
>> particular, it would address the issue when RI doesn't conform to the
>> spec for some reason while the variety of apps are already dependent
>> on a wrongly thrown exception.
>> Thank you,
>> Andrey Chernyshev
>> Intel Middleware Products Division
>>> 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?
>>> 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