You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/04/24 16:29:31 UTC
[doc] Compatibility guidelines
I've tried to capture in a webpage the compatibility guidelines that we
have agreed over the last few weeks.
The page is here:
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
I'm sure I'll have forgotten something, so additions / corrections /
etc. are welcome.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Mikhail Loenko <ml...@gmail.com>.
Geir agreed to 1-5 guidline in "Do we want to be bug compatible?" thread.
Probably doc does not exactly match them. Let's ask Geir
Thanks,
Mikhail
2006/4/25, Anton Avtamonov <an...@gmail.com>:
> On 4/25/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Anton,
> >
> > look at "Do we want to be bug compatible?" thread
> >
> > everybody agreed to the scheme:
> >
> > 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 spec; 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.
>
> Mikhail, I suppose that Tim's guidelines are generally about the same.
> Am I wrong? And as you can see it is not something which everyone
> agreed on: at least Geir's position is different. Or I got him wrong?
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/25/06, Mikhail Loenko <ml...@gmail.com> wrote:
> Anton,
>
> look at "Do we want to be bug compatible?" thread
>
> everybody agreed to the scheme:
>
> 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 spec; 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.
Mikhail, I suppose that Tim's guidelines are generally about the same.
Am I wrong? And as you can see it is not something which everyone
agreed on: at least Geir's position is different. Or I got him wrong?
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Mikhail Loenko <ml...@gmail.com>.
Anton,
look at "Do we want to be bug compatible?" thread
everybody agreed to the scheme:
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 spec; 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.
Thanks,
Mikhail
2006/4/25, Anton Avtamonov <an...@gmail.com>:
> On 4/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >
> >
> > Anton Avtamonov wrote:
> > > On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
> > >> Anton Avtamonov wrote:
> > >>> Tim, that is excellent! Thank you.
> > >>>
> > >>> I have couple of minor questions:
> > >>>
> > >>> Am I right with interpretation that the primary "source" is the spec
> > >>> rather than RI behavior? If the spec is consistent and logical, but
> > >>> contradicts to the RI behavior we are basing on spec? I'm asking just
> > >>> because that caused lots of debates last time and I want to make sure
> > >>> everyone agreed with this statement now.
> > >> That's what I thought we agreed. If the guide does not make that clear
> > >> then I am happy to clarify.
> > >
> > > Guidelines clearly mentioned that. I could not recall if everyone was
> > > agree or not :-).
> > > As I remember there were lots of people who proposed to base on RI
> > > behavior only (to be as much comatible as possible).
> > >
> > > Personally I'm completely agree with guidelines approach.
> >
> > The problem is that in the real world, we're going to have trouble
> > defending why everyone else is wrong, and we are correct.
> >
> > This is why I'd like to discuss and be able to go w/ RI behavior, and in
> > either case, WRITE EVERYTHING DOWN so that for diversions from the RI we
> > can make it easy for users to see why their code breaks on Harmony when
> > it runs everywhere else and for diversions from spec, we can eventually
> > come back after some time when we have achieved World Dominance(tm) and
> > fix them...
>
> I see I was right that we didn't have an agreement :-)
>
> Geir, I completely understood you point and even agree with you. My
> idea (and I believe Tim's guidelines support it) was to avoid copying
> of definite RI bugs. Just because I believe that there are no (or
> almost no) applications which are based on something which is
> definitely bug, not feature.
>
> However your proposal just to be as good as RI does for now, 'mark'
> all problems and revise them later definitely makes sense.
>
> Let's say I'm neutral and wait for others opinions.
>
> I'm sure that this is very key question and we have to achieve an
> agreement here.
>
> Wishes,
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> What I'm trying to convey is:
>
> 1) We should be doing spec-driven development, not development based on
> probing the behavior of any particular implementation of the spec (even
> the RI).
>
> I believe this is in best keeping with the spirit of Sun's intent for
> independent implementations of Java.
Absolutely! However, I don't think Sun even does this in pure form -
they have persisted bugs version after version because they didn't want
to break customers.
>
> 2) Since we know from experience that the spec leaves many questions
> unanswered, we should use the RI of the spec to resolve those questions
> using the public published interfaces to the RI. Typically this will
> mean running a test, written to public APIs, and observing the result.
>
> 3) Compatibility with existing implementations is very important to us,
> therefore we will run our tests written based on the spec against both
> our implementation and the RI (and possibly other implementations) to
> ensure we behave in the established way.
So far so good.
>
> Where there are anomalies or inconsistencies in the way the spec
> describes how things should work, how they work in the RI, or how they
> work in accepted implementations, then we discuss, decide, and document
> the chosen solution for Harmony.
Absolutely.
We're in harmonious agreement.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Tim Ellison <t....@gmail.com>.
IMHO discuss on the mailing list is always a good option, I just
wouldn't expect any discussion around items that work in the RI the way
they are described in the spec :-) we just do those!
Where there is some discrepancy or question, I see no problem with
people giving a heads up to their decisions (and noting such in
documentation):
To pick a random example:
"I read the spec and it says that java.nio.Buffer#clear() always
discards the mark, but my tests on the RI show it doesn't. Makes sense
to me that it should discard mark, so I'm going to do that"
or
"I found that FooBarPopularApp depends on the mark being kept even
though the data is invalid! so I'm going to do that <sigh>."
or
"I don't know what makes sense here. What do people think?"
You get the idea. The point being that the spec should be our first
port of call, with the RI filling in the blanks, and mailing list
consensus being the arbiter of any non-trivial decisions.
However, the nature of these discrepancies is that there are no concrete
rules for when things must come to the list, we rely on the quality of
our contributors and committers to do the right thing. Running popular
apps and ultimately the JCK is the stick that people can beat us with.
Regards,
Tim
Anton Avtamonov wrote:
> Hi Tim,
>
> May I ask for minor clarification just to make sure (looks like it is
> not fully covered here).
>
> In case the spec definitely says something which is not true for RI we should:
> - base on spec
> - base on RI
> - discuss in the mailing list
>
> I think that is the very core question which we cannot agree on.
>
>
> On 4/26/06, Tim Ellison <t....@gmail.com> wrote:
>> What I'm trying to convey is:
>>
>> 1) We should be doing spec-driven development, not development based on
>> probing the behavior of any particular implementation of the spec (even
>> the RI).
>>
>> I believe this is in best keeping with the spirit of Sun's intent for
>> independent implementations of Java.
>>
>> 2) Since we know from experience that the spec leaves many questions
>> unanswered, we should use the RI of the spec to resolve those questions
>> using the public published interfaces to the RI. Typically this will
>> mean running a test, written to public APIs, and observing the result.
>>
>> 3) Compatibility with existing implementations is very important to us,
>> therefore we will run our tests written based on the spec against both
>> our implementation and the RI (and possibly other implementations) to
>> ensure we behave in the established way.
>>
>> Where there are anomalies or inconsistencies in the way the spec
>> describes how things should work, how they work in the RI, or how they
>> work in accepted implementations, then we discuss, decide, and document
>> the chosen solution for Harmony.
>>
>> Regards,
>> Tim
>>
>>
>> Anton Avtamonov wrote:
>>> On 4/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>> Anton Avtamonov wrote:
>>>>> On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
>>>>>> Anton Avtamonov wrote:
>>>>>>> Tim, that is excellent! Thank you.
>>>>>>>
>>>>>>> I have couple of minor questions:
>>>>>>>
>>>>>>> Am I right with interpretation that the primary "source" is the spec
>>>>>>> rather than RI behavior? If the spec is consistent and logical, but
>>>>>>> contradicts to the RI behavior we are basing on spec? I'm asking just
>>>>>>> because that caused lots of debates last time and I want to make sure
>>>>>>> everyone agreed with this statement now.
>>>>>> That's what I thought we agreed. If the guide does not make that clear
>>>>>> then I am happy to clarify.
>>>>> Guidelines clearly mentioned that. I could not recall if everyone was
>>>>> agree or not :-).
>>>>> As I remember there were lots of people who proposed to base on RI
>>>>> behavior only (to be as much comatible as possible).
>>>>>
>>>>> Personally I'm completely agree with guidelines approach.
>>>> The problem is that in the real world, we're going to have trouble
>>>> defending why everyone else is wrong, and we are correct.
>>>>
>>>> This is why I'd like to discuss and be able to go w/ RI behavior, and in
>>>> either case, WRITE EVERYTHING DOWN so that for diversions from the RI we
>>>> can make it easy for users to see why their code breaks on Harmony when
>>>> it runs everywhere else and for diversions from spec, we can eventually
>>>> come back after some time when we have achieved World Dominance(tm) and
>>>> fix them...
>>> I see I was right that we didn't have an agreement :-)
>>>
>>> Geir, I completely understood you point and even agree with you. My
>>> idea (and I believe Tim's guidelines support it) was to avoid copying
>>> of definite RI bugs. Just because I believe that there are no (or
>>> almost no) applications which are based on something which is
>>> definitely bug, not feature.
>>>
>>> However your proposal just to be as good as RI does for now, 'mark'
>>> all problems and revise them later definitely makes sense.
>>>
>>> Let's say I'm neutral and wait for others opinions.
>>>
>>> I'm sure that this is very key question and we have to achieve an
>>> agreement here.
>>>
>>> Wishes,
>>> --
>>> Anton Avtamonov,
>>> Intel Middleware Products Division
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Anton Avtamonov <an...@gmail.com>.
Hi Tim,
May I ask for minor clarification just to make sure (looks like it is
not fully covered here).
In case the spec definitely says something which is not true for RI we should:
- base on spec
- base on RI
- discuss in the mailing list
I think that is the very core question which we cannot agree on.
On 4/26/06, Tim Ellison <t....@gmail.com> wrote:
> What I'm trying to convey is:
>
> 1) We should be doing spec-driven development, not development based on
> probing the behavior of any particular implementation of the spec (even
> the RI).
>
> I believe this is in best keeping with the spirit of Sun's intent for
> independent implementations of Java.
>
> 2) Since we know from experience that the spec leaves many questions
> unanswered, we should use the RI of the spec to resolve those questions
> using the public published interfaces to the RI. Typically this will
> mean running a test, written to public APIs, and observing the result.
>
> 3) Compatibility with existing implementations is very important to us,
> therefore we will run our tests written based on the spec against both
> our implementation and the RI (and possibly other implementations) to
> ensure we behave in the established way.
>
> Where there are anomalies or inconsistencies in the way the spec
> describes how things should work, how they work in the RI, or how they
> work in accepted implementations, then we discuss, decide, and document
> the chosen solution for Harmony.
>
> Regards,
> Tim
>
>
> Anton Avtamonov wrote:
> > On 4/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>
> >> Anton Avtamonov wrote:
> >>> On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
> >>>> Anton Avtamonov wrote:
> >>>>> Tim, that is excellent! Thank you.
> >>>>>
> >>>>> I have couple of minor questions:
> >>>>>
> >>>>> Am I right with interpretation that the primary "source" is the spec
> >>>>> rather than RI behavior? If the spec is consistent and logical, but
> >>>>> contradicts to the RI behavior we are basing on spec? I'm asking just
> >>>>> because that caused lots of debates last time and I want to make sure
> >>>>> everyone agreed with this statement now.
> >>>> That's what I thought we agreed. If the guide does not make that clear
> >>>> then I am happy to clarify.
> >>> Guidelines clearly mentioned that. I could not recall if everyone was
> >>> agree or not :-).
> >>> As I remember there were lots of people who proposed to base on RI
> >>> behavior only (to be as much comatible as possible).
> >>>
> >>> Personally I'm completely agree with guidelines approach.
> >> The problem is that in the real world, we're going to have trouble
> >> defending why everyone else is wrong, and we are correct.
> >>
> >> This is why I'd like to discuss and be able to go w/ RI behavior, and in
> >> either case, WRITE EVERYTHING DOWN so that for diversions from the RI we
> >> can make it easy for users to see why their code breaks on Harmony when
> >> it runs everywhere else and for diversions from spec, we can eventually
> >> come back after some time when we have achieved World Dominance(tm) and
> >> fix them...
> >
> > I see I was right that we didn't have an agreement :-)
> >
> > Geir, I completely understood you point and even agree with you. My
> > idea (and I believe Tim's guidelines support it) was to avoid copying
> > of definite RI bugs. Just because I believe that there are no (or
> > almost no) applications which are based on something which is
> > definitely bug, not feature.
> >
> > However your proposal just to be as good as RI does for now, 'mark'
> > all problems and revise them later definitely makes sense.
> >
> > Let's say I'm neutral and wait for others opinions.
> >
> > I'm sure that this is very key question and we have to achieve an
> > agreement here.
> >
> > Wishes,
> > --
> > Anton Avtamonov,
> > Intel Middleware Products Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Tim Ellison <t....@gmail.com>.
What I'm trying to convey is:
1) We should be doing spec-driven development, not development based on
probing the behavior of any particular implementation of the spec (even
the RI).
I believe this is in best keeping with the spirit of Sun's intent for
independent implementations of Java.
2) Since we know from experience that the spec leaves many questions
unanswered, we should use the RI of the spec to resolve those questions
using the public published interfaces to the RI. Typically this will
mean running a test, written to public APIs, and observing the result.
3) Compatibility with existing implementations is very important to us,
therefore we will run our tests written based on the spec against both
our implementation and the RI (and possibly other implementations) to
ensure we behave in the established way.
Where there are anomalies or inconsistencies in the way the spec
describes how things should work, how they work in the RI, or how they
work in accepted implementations, then we discuss, decide, and document
the chosen solution for Harmony.
Regards,
Tim
Anton Avtamonov wrote:
> On 4/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>> Anton Avtamonov wrote:
>>> On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
>>>> Anton Avtamonov wrote:
>>>>> Tim, that is excellent! Thank you.
>>>>>
>>>>> I have couple of minor questions:
>>>>>
>>>>> Am I right with interpretation that the primary "source" is the spec
>>>>> rather than RI behavior? If the spec is consistent and logical, but
>>>>> contradicts to the RI behavior we are basing on spec? I'm asking just
>>>>> because that caused lots of debates last time and I want to make sure
>>>>> everyone agreed with this statement now.
>>>> That's what I thought we agreed. If the guide does not make that clear
>>>> then I am happy to clarify.
>>> Guidelines clearly mentioned that. I could not recall if everyone was
>>> agree or not :-).
>>> As I remember there were lots of people who proposed to base on RI
>>> behavior only (to be as much comatible as possible).
>>>
>>> Personally I'm completely agree with guidelines approach.
>> The problem is that in the real world, we're going to have trouble
>> defending why everyone else is wrong, and we are correct.
>>
>> This is why I'd like to discuss and be able to go w/ RI behavior, and in
>> either case, WRITE EVERYTHING DOWN so that for diversions from the RI we
>> can make it easy for users to see why their code breaks on Harmony when
>> it runs everywhere else and for diversions from spec, we can eventually
>> come back after some time when we have achieved World Dominance(tm) and
>> fix them...
>
> I see I was right that we didn't have an agreement :-)
>
> Geir, I completely understood you point and even agree with you. My
> idea (and I believe Tim's guidelines support it) was to avoid copying
> of definite RI bugs. Just because I believe that there are no (or
> almost no) applications which are based on something which is
> definitely bug, not feature.
>
> However your proposal just to be as good as RI does for now, 'mark'
> all problems and revise them later definitely makes sense.
>
> Let's say I'm neutral and wait for others opinions.
>
> I'm sure that this is very key question and we have to achieve an
> agreement here.
>
> Wishes,
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Anton Avtamonov wrote:
> > On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
> >> Anton Avtamonov wrote:
> >>> Tim, that is excellent! Thank you.
> >>>
> >>> I have couple of minor questions:
> >>>
> >>> Am I right with interpretation that the primary "source" is the spec
> >>> rather than RI behavior? If the spec is consistent and logical, but
> >>> contradicts to the RI behavior we are basing on spec? I'm asking just
> >>> because that caused lots of debates last time and I want to make sure
> >>> everyone agreed with this statement now.
> >> That's what I thought we agreed. If the guide does not make that clear
> >> then I am happy to clarify.
> >
> > Guidelines clearly mentioned that. I could not recall if everyone was
> > agree or not :-).
> > As I remember there were lots of people who proposed to base on RI
> > behavior only (to be as much comatible as possible).
> >
> > Personally I'm completely agree with guidelines approach.
>
> The problem is that in the real world, we're going to have trouble
> defending why everyone else is wrong, and we are correct.
>
> This is why I'd like to discuss and be able to go w/ RI behavior, and in
> either case, WRITE EVERYTHING DOWN so that for diversions from the RI we
> can make it easy for users to see why their code breaks on Harmony when
> it runs everywhere else and for diversions from spec, we can eventually
> come back after some time when we have achieved World Dominance(tm) and
> fix them...
I see I was right that we didn't have an agreement :-)
Geir, I completely understood you point and even agree with you. My
idea (and I believe Tim's guidelines support it) was to avoid copying
of definite RI bugs. Just because I believe that there are no (or
almost no) applications which are based on something which is
definitely bug, not feature.
However your proposal just to be as good as RI does for now, 'mark'
all problems and revise them later definitely makes sense.
Let's say I'm neutral and wait for others opinions.
I'm sure that this is very key question and we have to achieve an
agreement here.
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Anton Avtamonov wrote:
> On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
>> Anton Avtamonov wrote:
>>> Tim, that is excellent! Thank you.
>>>
>>> I have couple of minor questions:
>>>
>>> Am I right with interpretation that the primary "source" is the spec
>>> rather than RI behavior? If the spec is consistent and logical, but
>>> contradicts to the RI behavior we are basing on spec? I'm asking just
>>> because that caused lots of debates last time and I want to make sure
>>> everyone agreed with this statement now.
>> That's what I thought we agreed. If the guide does not make that clear
>> then I am happy to clarify.
>
> Guidelines clearly mentioned that. I could not recall if everyone was
> agree or not :-).
> As I remember there were lots of people who proposed to base on RI
> behavior only (to be as much comatible as possible).
>
> Personally I'm completely agree with guidelines approach.
The problem is that in the real world, we're going to have trouble
defending why everyone else is wrong, and we are correct.
This is why I'd like to discuss and be able to go w/ RI behavior, and in
either case, WRITE EVERYTHING DOWN so that for diversions from the RI we
can make it easy for users to see why their code breaks on Harmony when
it runs everywhere else and for diversions from spec, we can eventually
come back after some time when we have achieved World Dominance(tm) and
fix them...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
> Anton Avtamonov wrote:
> > Tim, that is excellent! Thank you.
> >
> > I have couple of minor questions:
> >
> > Am I right with interpretation that the primary "source" is the spec
> > rather than RI behavior? If the spec is consistent and logical, but
> > contradicts to the RI behavior we are basing on spec? I'm asking just
> > because that caused lots of debates last time and I want to make sure
> > everyone agreed with this statement now.
>
> That's what I thought we agreed. If the guide does not make that clear
> then I am happy to clarify.
Guidelines clearly mentioned that. I could not recall if everyone was
agree or not :-).
As I remember there were lots of people who proposed to base on RI
behavior only (to be as much comatible as possible).
Personally I'm completely agree with guidelines approach.
>
> > Another minor comment regarding to the serialization compatibility:
> > What if serialization form is not specified and the spec states that
> > serialization form will not be compatible with future releases? Does
> > it mean we want to copy the existing serialization form? Or we are
> > going to define our own? Should it be reflected in the guidelines?
>
> I suggest that we copy the current RI form (if we can deduce it
> honestly) to get better interoperability.
+1.
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Anton Avtamonov wrote:
>> Tim, that is excellent! Thank you.
>>
>> I have couple of minor questions:
>>
>> Am I right with interpretation that the primary "source" is the spec
>> rather than RI behavior? If the spec is consistent and logical, but
>> contradicts to the RI behavior we are basing on spec? I'm asking just
>> because that caused lots of debates last time and I want to make sure
>> everyone agreed with this statement now.
>
> That's what I thought we agreed. If the guide does not make that clear
> then I am happy to clarify.
I don't recall that. When Paulex first summarized our discussion, I
thought that we decide those on a case by case basis, as our intention
is to have SDK/JRE that works identically to that from IBM, BEA, Sun...
>
>> Another minor comment regarding to the serialization compatibility:
>> What if serialization form is not specified and the spec states that
>> serialization form will not be compatible with future releases? Does
>> it mean we want to copy the existing serialization form? Or we are
>> going to define our own? Should it be reflected in the guidelines?
>
> I suggest that we copy the current RI form (if we can deduce it
> honestly) to get better interoperability.
+1
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Tim Ellison <t....@gmail.com>.
Anton Avtamonov wrote:
> Tim, that is excellent! Thank you.
>
> I have couple of minor questions:
>
> Am I right with interpretation that the primary "source" is the spec
> rather than RI behavior? If the spec is consistent and logical, but
> contradicts to the RI behavior we are basing on spec? I'm asking just
> because that caused lots of debates last time and I want to make sure
> everyone agreed with this statement now.
That's what I thought we agreed. If the guide does not make that clear
then I am happy to clarify.
> Another minor comment regarding to the serialization compatibility:
> What if serialization form is not specified and the spec states that
> serialization form will not be compatible with future releases? Does
> it mean we want to copy the existing serialization form? Or we are
> going to define our own? Should it be reflected in the guidelines?
I suggest that we copy the current RI form (if we can deduce it
honestly) to get better interoperability.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Anton Avtamonov <an...@gmail.com>.
Tim, that is excellent! Thank you.
I have couple of minor questions:
Am I right with interpretation that the primary "source" is the spec
rather than RI behavior? If the spec is consistent and logical, but
contradicts to the RI behavior we are basing on spec? I'm asking just
because that caused lots of debates last time and I want to make sure
everyone agreed with this statement now.
Another minor comment regarding to the serialization compatibility:
What if serialization form is not specified and the spec states that
serialization form will not be compatible with future releases? Does
it mean we want to copy the existing serialization form? Or we are
going to define our own? Should it be reflected in the guidelines?
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
On 4/24/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> nice. thanks.
>
> Tim Ellison wrote:
> > I've tried to capture in a webpage the compatibility guidelines that we
> > have agreed over the last few weeks.
> >
> > The page is here:
> > http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
> >
> > I'm sure I'll have forgotten something, so additions / corrections /
> > etc. are welcome.
> >
> > Regards,
> > Tim
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [doc] Compatibility guidelines
Posted by Geir Magnusson Jr <ge...@pobox.com>.
nice. thanks.
Tim Ellison wrote:
> I've tried to capture in a webpage the compatibility guidelines that we
> have agreed over the last few weeks.
>
> The page is here:
> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
>
> I'm sure I'll have forgotten something, so additions / corrections /
> etc. are welcome.
>
> Regards,
> Tim
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org