You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Loenko <ml...@gmail.com> on 2006/02/18 19:03:53 UTC
Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
What is the goal of spec-compatibility for exceptions?
1. Existing applications that work well on Sun's Java might fail on Harmony.
2. Sun, once it discovers the bug, will most likely change the spec
rather then impl,
and we will have to return and fix our code
Thanks,
Mikhail
On 2/17/06, karan malhi <ka...@gmail.com> wrote:
>
>
> Anton Avtamonov wrote:
>
> IMHO, when spec states some exception we should be spec-compatible.
>
> +1
>
>
> >On 2/17/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >
> >
> >>I agree with Tim that we should discuss on the dev list
> >>
> >>
> >
> >+1
> >
> >
> >
> >>Later we might want to have some roadmap once we find a number
> >>of similar issues
> >>
> >>At this point I think we might be compatible when RI throws
> >>wrong exceptions - for example it often mixes NPE and
> >>IllegalArgumentException
> >>
> >>
> >
> >Sometimes spec states IllegalArgumentException should be thrown, but
> >implementation produces NPE. I think that is because
> >IllegalArgumentException is missed in impl and algorithm just failed
> >somewhere...
> >IMHO, when spec states some exception we should be spec-compatible.
> >
> >--
> >Anton Avtamonov,
> >Intel Middleware Products Division
> >
> >
> >
>
> --
> Karan Singh
>
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/19/06, karan malhi <ka...@gmail.com> wrote:
>
>
> Geir Magnusson Jr wrote:
>
> > Well, I don't really know if Sun would do that. There is an expert
> > group that Sun has to deal with...
> >
> > But if it did happen, yes, we'd have to fix our code.
> >
> I agree. Whatever experience I've had with java till now, I have found
> that Sun mainly deprecates a method and provides a replacement, instead
> of changing the spec for that method after the spec has been released.
> So, if Sun decides to deprecate a method, it will still not break
> harmony. I still feel our code should be spec compatible and not bug
> compatible with Sun's impl. As a developer, I would look at the API docs
> and then write the code. So, if our impl is compatible with the API
> docs, won't that make a case for using harmony instead of a buggy impl :)
Yeah! Very optimistic! I agree :-)
In practical terms developers hate when spec contradicts to the real
behavior so for the developers of the new applications it would be
fantastic to have such implementation. However we have to run all
existing applications first, and, therefore, have to be as closer to
Sun's impl as possible... If I got it right we decided to discuss all
not-trivial cases and I believe that is right approach.
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by karan malhi <ka...@gmail.com>.
Geir Magnusson Jr wrote:
> Well, I don't really know if Sun would do that. There is an expert
> group that Sun has to deal with...
>
> But if it did happen, yes, we'd have to fix our code.
>
I agree. Whatever experience I've had with java till now, I have found
that Sun mainly deprecates a method and provides a replacement, instead
of changing the spec for that method after the spec has been released.
So, if Sun decides to deprecate a method, it will still not break
harmony. I still feel our code should be spec compatible and not bug
compatible with Sun's impl. As a developer, I would look at the API docs
and then write the code. So, if our impl is compatible with the API
docs, won't that make a case for using harmony instead of a buggy impl :)
>>
>> Thanks,
>> Mikhail
>>
>> On 2/17/06, karan malhi <ka...@gmail.com> wrote:
>>
>>>
>>> Anton Avtamonov wrote:
>>>
>>> IMHO, when spec states some exception we should be spec-compatible.
>>>
>>> +1
>>>
>>>
>>>> On 2/17/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>>
>>>>
>>>>> I agree with Tim that we should discuss on the dev list
>>>>>
>>>>>
>>>> +1
>>>>
>>>>
>>>>
>>>>> Later we might want to have some roadmap once we find a number
>>>>> of similar issues
>>>>>
>>>>> At this point I think we might be compatible when RI throws
>>>>> wrong exceptions - for example it often mixes NPE and
>>>>> IllegalArgumentException
>>>>>
>>>>>
>>>> Sometimes spec states IllegalArgumentException should be thrown, but
>>>> implementation produces NPE. I think that is because
>>>> IllegalArgumentException is missed in impl and algorithm just failed
>>>> somewhere...
>>>> IMHO, when spec states some exception we should be spec-compatible.
>>>>
>>>> --
>>>> Anton Avtamonov,
>>>> Intel Middleware Products Division
>>>>
>>>>
>>>>
>>> --
>>> Karan Singh
>>>
>>>
>>
>>
>
--
Karan Singh
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/27/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > Lemme remember Paulex's rules:
> >
> >> 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
> >
>
> 5. Log every difference from either the spec or the RI in JIRA.
Absolutely agree.
[snip]
>
> Actually, I think that Sun does have an internal group which does
> exactly that. I've heard some great stories about the raging fights
> that have erupted internally due to this process...
>
> We'll get to have our great fights here :)
:-)
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Paulex Yang <pa...@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> Anton Avtamonov wrote:
>> On 2/27/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>> 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.
>>
>> Well, actually you are right. I disagree just to simply copy all the
>> existing bugs... And as I rememeber I'm not along :-). The main idea
>> is to follow the guidelines Paulex proposed, i.e. to be reasonable.
>> Lemme remember Paulex's rules:
>>
>>> 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
>>
>
> 5. Log every difference from either the spec or the RI in JIRA.
+1 from me.
>
>> I believe this approach will give better results: keepping us
>> compatible with the existing applications and provide more consistent
>> implementation where possible. Note that according to the rules above
>> we are not mandatory follow to the spec.
>>
>> Btw, releasing new JDK SUN updates some existing methods, sometimes
>> changing not only internal implementation, but even some behavior. I
>> suppose they don't run all existing applications to make sure nothing
>> is broken :-). I don't know how this process is organized, however I
>> would expect some kind of CCB (Change Control Board) which decide if
>> it's safe change or not. I suppose our mailing list can act in a very
>> similar manner.
>
> Actually, I think that Sun does have an internal group which does
> exactly that. I've heard some great stories about the raging fights
> that have erupted internally due to this process...
>
> We'll get to have our great fights here :)
That's the way to harmony ;-)
>
> geir
>
>>
>> --
>> Anton Avtamonov,
>> Intel Middleware Products Division
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Anton Avtamonov wrote:
> On 2/27/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> 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.
>
> Well, actually you are right. I disagree just to simply copy all the
> existing bugs... And as I rememeber I'm not along :-). The main idea
> is to follow the guidelines Paulex proposed, i.e. to be reasonable.
> Lemme remember Paulex's rules:
>
>> 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
>
5. Log every difference from either the spec or the RI in JIRA.
> I believe this approach will give better results: keepping us
> compatible with the existing applications and provide more consistent
> implementation where possible. Note that according to the rules above
> we are not mandatory follow to the spec.
>
> Btw, releasing new JDK SUN updates some existing methods, sometimes
> changing not only internal implementation, but even some behavior. I
> suppose they don't run all existing applications to make sure nothing
> is broken :-). I don't know how this process is organized, however I
> would expect some kind of CCB (Change Control Board) which decide if
> it's safe change or not. I suppose our mailing list can act in a very
> similar manner.
Actually, I think that Sun does have an internal group which does
exactly that. I've heard some great stories about the raging fights
that have erupted internally due to this process...
We'll get to have our great fights here :)
geir
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/27/06, Mikhail Loenko <ml...@gmail.com> wrote:
> 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.
Well, actually you are right. I disagree just to simply copy all the
existing bugs... And as I rememeber I'm not along :-). The main idea
is to follow the guidelines Paulex proposed, i.e. to be reasonable.
Lemme remember Paulex's rules:
>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
I believe this approach will give better results: keepping us
compatible with the existing applications and provide more consistent
implementation where possible. Note that according to the rules above
we are not mandatory follow to the spec.
Btw, releasing new JDK SUN updates some existing methods, sometimes
changing not only internal implementation, but even some behavior. I
suppose they don't run all existing applications to make sure nothing
is broken :-). I don't know how this process is organized, however I
would expect some kind of CCB (Change Control Board) which decide if
it's safe change or not. I suppose our mailing list can act in a very
similar manner.
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Tim Ellison <t....@gmail.com>.
LOL -- yes, we know what you meant Paulex; or to put it another way 'we
all heard what we wanted to hear'.
Regards,
Tim
Anton Avtamonov wrote:
> On 2/27/06, Paulex Yang <pa...@gmail.com> wrote:
>> 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.
>
> I also missed that!
> The idea was absolutely clear, particular words are not important :-)
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/27/06, Paulex Yang <pa...@gmail.com> wrote:
> 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.
I also missed that!
The idea was absolutely clear, particular words are not important :-)
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Paulex Yang <pa...@gmail.com>.
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
</quote>
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 <ge...@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....@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 <ml...@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.
>>>>
>>>>
>>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/2/27, Geir Magnusson Jr <ge...@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....@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 <ml...@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.
> >>
> >
> >
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Geir Magnusson Jr <ge...@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?
geir
>
> Thanks,
> Mikhail
>
> On 2/20/06, Tim Ellison <t....@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 <ml...@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.
>>
>
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 :)
geir
>
>
>
> *Thank you.*
>
> *--------------*
>
> *Vladimir Gorr*
>
> Intel Middleware Products Division.
>
>
> On 2/20/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> On 2/20/06, Mikhail Loenko <ml...@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....@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 <ml...@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.
>>>>
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Vladimir Gorr <vv...@gmail.com>.
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
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?
*Thank you.*
*--------------*
*Vladimir Gorr*
Intel Middleware Products Division.
On 2/20/06, Andrey Chernyshev <a....@gmail.com> wrote:
>
> On 2/20/06, Mikhail Loenko <ml...@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....@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 <ml...@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.
> > >
> >
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Alex Orlov <am...@gmail.com>.
I would support Mikhail. If we are aware of bug in RI there might be a few
cases. First, we suppose we're really better than RI not having this bug.
The second one is the case being discussed. When it basically does not
matter that much but we're considering being either spec or bug compatible.
In this case if we think it might be used in the applications why not to
implement it and create regression tests for this specific feature?
Following this rule:
- We would support compatibility with RI. People should not think about
which implementation their application would start.
- We would be able to track changes in RI in order to continue being
compatible.
My thinking is we would not rely on the scenario when the customer would
submit a bug to JIRA if he faced to the incompatibility. Most lilely he
would not submit anything and just stop using Harmony.
Thank you,
Alex Orlov
Intel Middleware Products Division
On 2/20/06, Andrey Chernyshev <a....@gmail.com> wrote:
>
> On 2/20/06, Mikhail Loenko <ml...@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....@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 <ml...@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.
> > >
> >
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Andrey Chernyshev <a....@gmail.com>.
On 2/20/06, Mikhail Loenko <ml...@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....@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 <ml...@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.
> >
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Mikhail Loenko <ml...@gmail.com>.
How will we verify Harmony with all existing apps in the world?
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....@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 <ml...@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.
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Tim Ellison <t....@gmail.com>.
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 <ml...@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.
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/20/06, Mikhail Loenko <ml...@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
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Mikhail Loenko <ml...@gmail.com>.
Well seems like we all agree with the general approach.
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
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?
Thanks,
Mikhail
On 2/20/06, Anton Avtamonov <an...@gmail.com> wrote:
> On 2/20/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Anton
> >
> > still no answer to: What is the goal of that firm spec compatibility?
> >
> > Are you sure that if some usage scenario does not make sense for you
> > and for all progressive people in the world then there no application working
> > this way?
> >
> > Think of the following: we release Harmony, people will try their apps
> > and find out
> > that they do not work. What will the people do?
>
> Absolutely agree with the concern above. I mean that some of ther
> potential users just stop using Harmony and get something which
> 'properly' works. However I believe:
> 1. We will test Harmony on many applications and will be able to
> identify the major part of the potential problems
> 2. People will send us bug report in the same manner they do for
> Sun's implementation.
>
> I completely agree that we must be very careful decising what is bug
> and what is not (actually, it was my original post :-) ).
> I just added that we should try to be spec-compatible when possible.
> Particulary talking about exceptions: I hope that there should not be
> too many applications which are relevant to what kind of
> RuntimeException JRE produces (NPE or IllegalArgumentException) in
> those cases when Sun's impl doesn't satisfy its spec. Therefore to be
> spec-compatible here should not cause a problem.
>
> [snip]
> > Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to
> > carefully work with all the cases when we can potentially break existing
> > applications.
>
> +2 (with both hands :-) )
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Gerry Steele wrote:
> It might also be worth nothing that if you are licensed to use the
> tck, there is an appeal process, so it may be possible to make sun
> accept deviation from the spec or unreasonable claims in the spec, on
> their part, on a case by case basis.
Sure, but that's a different issue. We've experienced that w/ J2EE,
and it was generally a reasonable and decent process.
However, in the end, it will be all about users running applications.
>
> But i suppose the real test is how well it runs existing applications.
> If a user finds it more difficult to run their app than with the Sun
> JVM, then they simply wont use it.
Yes!
>
> Also, has much thought been given to the GUI components of the spec?
> Can harmony/classpath replicate a compatible system with regards to
> the current line of development?
That's the goal. Of course, if Sun happened to donate an implementation
, we'd be better off :)
geir
>
>
> On 2/20/06, Anton Avtamonov <an...@gmail.com> wrote:
>> On 2/20/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>> Anton
>>>
>>> still no answer to: What is the goal of that firm spec compatibility?
>>>
>>> Are you sure that if some usage scenario does not make sense for you
>>> and for all progressive people in the world then there no application working
>>> this way?
>>>
>>> Think of the following: we release Harmony, people will try their apps
>>> and find out
>>> that they do not work. What will the people do?
>> Absolutely agree with the concern above. I mean that some of ther
>> potential users just stop using Harmony and get something which
>> 'properly' works. However I believe:
>> 1. We will test Harmony on many applications and will be able to
>> identify the major part of the potential problems
>> 2. People will send us bug report in the same manner they do for
>> Sun's implementation.
>>
>> I completely agree that we must be very careful decising what is bug
>> and what is not (actually, it was my original post :-) ).
>> I just added that we should try to be spec-compatible when possible.
>> Particulary talking about exceptions: I hope that there should not be
>> too many applications which are relevant to what kind of
>> RuntimeException JRE produces (NPE or IllegalArgumentException) in
>> those cases when Sun's impl doesn't satisfy its spec. Therefore to be
>> spec-compatible here should not cause a problem.
>>
>> [snip]
>>> Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to
>>> carefully work with all the cases when we can potentially break existing
>>> applications.
>> +2 (with both hands :-) )
>>
>> --
>> Anton Avtamonov,
>> Intel Middleware Products Division
>>
>
>
> --
> Gerry Steele
> http://gerry-steele.blogspot.com/
>
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Mikhail Loenko <ml...@gmail.com>.
On 2/20/06, Anton Avtamonov <an...@gmail.com> wrote:
> On 2/20/06, Gerry Steele <ge...@gmail.com> wrote:
> > It might also be worth nothing that if you are licensed to use the
> > tck, there is an appeal process, so it may be possible to make sun
> > accept deviation from the spec or unreasonable claims in the spec, on
> > their part, on a case by case basis.
> >
> > But i suppose the real test is how well it runs existing applications.
> > If a user finds it more difficult to run their app than with the Sun
> > JVM, then they simply wont use it.
>
> In general, of course. If I ran my application and found all the
> buttons are in the mess on the wrong places, scrollers don't scroll,
> etc... Yeah, most likely I just stop trying. In the other hand, if I
> have one exception with adequate message which I recognize as a
If you are a user, not a developer that message would not help you.
You will not care whether the bug is in the app or in the Harmony.
The only thing that you'll see is it worked on RI and does not work on Harmony.
Thanks,
Mikhail
> problem in my code... I just say 'great thanks' to those who helped me
> to find it :-)
> Again, it should not be hundreds of exceptions! It may be 1 exception
> per 100 applications... Something like that... Otherwise we will
> identify the problem when testing and decide what to do. Sorry if I
> very optimistic :-)
>
> Probably we can have some place where everyone will be able to record
> identified deviations? I'm not sure that is really makes sense 'cause
> I can't imagine how to handle such list for the practical value.
> Obviously all serious deviations have to be discussed here.
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/20/06, Gerry Steele <ge...@gmail.com> wrote:
> It might also be worth nothing that if you are licensed to use the
> tck, there is an appeal process, so it may be possible to make sun
> accept deviation from the spec or unreasonable claims in the spec, on
> their part, on a case by case basis.
>
> But i suppose the real test is how well it runs existing applications.
> If a user finds it more difficult to run their app than with the Sun
> JVM, then they simply wont use it.
In general, of course. If I ran my application and found all the
buttons are in the mess on the wrong places, scrollers don't scroll,
etc... Yeah, most likely I just stop trying. In the other hand, if I
have one exception with adequate message which I recognize as a
problem in my code... I just say 'great thanks' to those who helped me
to find it :-)
Again, it should not be hundreds of exceptions! It may be 1 exception
per 100 applications... Something like that... Otherwise we will
identify the problem when testing and decide what to do. Sorry if I
very optimistic :-)
Probably we can have some place where everyone will be able to record
identified deviations? I'm not sure that is really makes sense 'cause
I can't imagine how to handle such list for the practical value.
Obviously all serious deviations have to be discussed here.
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Gerry Steele <ge...@gmail.com>.
It might also be worth nothing that if you are licensed to use the
tck, there is an appeal process, so it may be possible to make sun
accept deviation from the spec or unreasonable claims in the spec, on
their part, on a case by case basis.
But i suppose the real test is how well it runs existing applications.
If a user finds it more difficult to run their app than with the Sun
JVM, then they simply wont use it.
Also, has much thought been given to the GUI components of the spec?
Can harmony/classpath replicate a compatible system with regards to
the current line of development?
On 2/20/06, Anton Avtamonov <an...@gmail.com> wrote:
> On 2/20/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Anton
> >
> > still no answer to: What is the goal of that firm spec compatibility?
> >
> > Are you sure that if some usage scenario does not make sense for you
> > and for all progressive people in the world then there no application working
> > this way?
> >
> > Think of the following: we release Harmony, people will try their apps
> > and find out
> > that they do not work. What will the people do?
>
> Absolutely agree with the concern above. I mean that some of ther
> potential users just stop using Harmony and get something which
> 'properly' works. However I believe:
> 1. We will test Harmony on many applications and will be able to
> identify the major part of the potential problems
> 2. People will send us bug report in the same manner they do for
> Sun's implementation.
>
> I completely agree that we must be very careful decising what is bug
> and what is not (actually, it was my original post :-) ).
> I just added that we should try to be spec-compatible when possible.
> Particulary talking about exceptions: I hope that there should not be
> too many applications which are relevant to what kind of
> RuntimeException JRE produces (NPE or IllegalArgumentException) in
> those cases when Sun's impl doesn't satisfy its spec. Therefore to be
> spec-compatible here should not cause a problem.
>
> [snip]
> > Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to
> > carefully work with all the cases when we can potentially break existing
> > applications.
>
> +2 (with both hands :-) )
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
--
Gerry Steele
http://gerry-steele.blogspot.com/
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/20/06, Mikhail Loenko <ml...@gmail.com> wrote:
> Anton
>
> still no answer to: What is the goal of that firm spec compatibility?
>
> Are you sure that if some usage scenario does not make sense for you
> and for all progressive people in the world then there no application working
> this way?
>
> Think of the following: we release Harmony, people will try their apps
> and find out
> that they do not work. What will the people do?
Absolutely agree with the concern above. I mean that some of ther
potential users just stop using Harmony and get something which
'properly' works. However I believe:
1. We will test Harmony on many applications and will be able to
identify the major part of the potential problems
2. People will send us bug report in the same manner they do for
Sun's implementation.
I completely agree that we must be very careful decising what is bug
and what is not (actually, it was my original post :-) ).
I just added that we should try to be spec-compatible when possible.
Particulary talking about exceptions: I hope that there should not be
too many applications which are relevant to what kind of
RuntimeException JRE produces (NPE or IllegalArgumentException) in
those cases when Sun's impl doesn't satisfy its spec. Therefore to be
spec-compatible here should not cause a problem.
[snip]
> Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to
> carefully work with all the cases when we can potentially break existing
> applications.
+2 (with both hands :-) )
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Mikhail Loenko <ml...@gmail.com>.
Anton
still no answer to: What is the goal of that firm spec compatibility?
Are you sure that if some usage scenario does not make sense for you
and for all progressive people in the world then there no application working
this way?
Think of the following: we release Harmony, people will try their apps
and find out
that they do not work. What will the people do?
I cannot recall an example, but when we were developing classes we have found
that the spec was changed from 1.4 to 1.5 to reflect existing
('buggy') behavior.
Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to
carefully work with all the cases when we can potentially break existing
applications.
Thanks,
Mikhail
On 2/20/06, Anton Avtamonov <an...@gmail.com> wrote:
> On 2/19/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >
> >
> > Mikhail Loenko wrote:
> > > What is the goal of spec-compatibility for exceptions?
> > >
> > > 1. Existing applications that work well on Sun's Java might fail on Harmony.
> >
> > Right - this is a problem. People will say that we're broken. It's not
> > a easy conversation to have with users who don't care about license,
> > just want a good JRE to work with, so then delete our implementation.
>
> Sounds reasonable.
> However I hope the expected deviations for Sun's impl (if we talk
> about exceptions) should not be so dramatic... I hope we will be
> basing on both spec, impl behavior and common sense.
> For instance, there is javax.swing.GrayFilter class which constructor
> takes 'percentage of gray' parameter (a value in a [0-100] range).
> Spec doesn't state there should be IllegalArgumentException if the
> value is out of range, but both Sun's impl and common sense tell us it
> should be.
> Another case is if spec states IllegalArgumentException, but impl
> produces NPE... I don't believe there are applications which are
> really care about the particular kind of RuntimeException :-). So in
> this case I would follow the spec.
> Really, IllegalArgumentException is always a guard statement for
> definitely wrong usage of API (like setting percentage out of [0-100]
> range). Not too many people should break such 'common sense' idea.
> Besides, I hope we will have not too many places when Sun's impl and
> spec differ.
>
>
> >
> > > 2. Sun, once it discovers the bug, will most likely change the spec
> > > rather then impl,
> > > and we will have to return and fix our code
> >
> > Well, I don't really know if Sun would do that. There is an expert
> > group that Sun has to deal with...
>
> I think we should try to be spec-compatible when possible. If the spec
> is changed - we will change the implementation.
>
> Actually, for the time being I don't know any applications which are
> broken because of using IllegalArgumentException instead of NPE or
> vise versa. Let's see if we have such and then decide. Before that,
> spec-compatibility looks more preferrable for me...
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/19/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Mikhail Loenko wrote:
> > What is the goal of spec-compatibility for exceptions?
> >
> > 1. Existing applications that work well on Sun's Java might fail on Harmony.
>
> Right - this is a problem. People will say that we're broken. It's not
> a easy conversation to have with users who don't care about license,
> just want a good JRE to work with, so then delete our implementation.
Sounds reasonable.
However I hope the expected deviations for Sun's impl (if we talk
about exceptions) should not be so dramatic... I hope we will be
basing on both spec, impl behavior and common sense.
For instance, there is javax.swing.GrayFilter class which constructor
takes 'percentage of gray' parameter (a value in a [0-100] range).
Spec doesn't state there should be IllegalArgumentException if the
value is out of range, but both Sun's impl and common sense tell us it
should be.
Another case is if spec states IllegalArgumentException, but impl
produces NPE... I don't believe there are applications which are
really care about the particular kind of RuntimeException :-). So in
this case I would follow the spec.
Really, IllegalArgumentException is always a guard statement for
definitely wrong usage of API (like setting percentage out of [0-100]
range). Not too many people should break such 'common sense' idea.
Besides, I hope we will have not too many places when Sun's impl and
spec differ.
>
> > 2. Sun, once it discovers the bug, will most likely change the spec
> > rather then impl,
> > and we will have to return and fix our code
>
> Well, I don't really know if Sun would do that. There is an expert
> group that Sun has to deal with...
I think we should try to be spec-compatible when possible. If the spec
is changed - we will change the implementation.
Actually, for the time being I don't know any applications which are
broken because of using IllegalArgumentException instead of NPE or
vise versa. Let's see if we have such and then decide. Before that,
spec-compatibility looks more preferrable for me...
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where
to start from)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Mikhail Loenko wrote:
> What is the goal of spec-compatibility for exceptions?
>
> 1. Existing applications that work well on Sun's Java might fail on Harmony.
Right - this is a problem. People will say that we're broken. It's not
a easy conversation to have with users who don't care about license,
just want a good JRE to work with, so then delete our implementation.
> 2. Sun, once it discovers the bug, will most likely change the spec
> rather then impl,
> and we will have to return and fix our code
Well, I don't really know if Sun would do that. There is an expert
group that Sun has to deal with...
But if it did happen, yes, we'd have to fix our code.
geir
>
> Thanks,
> Mikhail
>
> On 2/17/06, karan malhi <ka...@gmail.com> wrote:
>>
>> Anton Avtamonov wrote:
>>
>> IMHO, when spec states some exception we should be spec-compatible.
>>
>> +1
>>
>>
>>> On 2/17/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>
>>>
>>>> I agree with Tim that we should discuss on the dev list
>>>>
>>>>
>>> +1
>>>
>>>
>>>
>>>> Later we might want to have some roadmap once we find a number
>>>> of similar issues
>>>>
>>>> At this point I think we might be compatible when RI throws
>>>> wrong exceptions - for example it often mixes NPE and
>>>> IllegalArgumentException
>>>>
>>>>
>>> Sometimes spec states IllegalArgumentException should be thrown, but
>>> implementation produces NPE. I think that is because
>>> IllegalArgumentException is missed in impl and algorithm just failed
>>> somewhere...
>>> IMHO, when spec states some exception we should be spec-compatible.
>>>
>>> --
>>> Anton Avtamonov,
>>> Intel Middleware Products Division
>>>
>>>
>>>
>> --
>> Karan Singh
>>
>>
>
>