You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexei Zakharov <al...@gmail.com> on 2006/06/30 17:14:45 UTC
[classlib] compatibility of toString
Hi community!
While looking through some of java.beans tests I found many places
where exact output of toString() method is being tested. Moreover, the
test patterns differ from the output generated by RI's toString's.
IMHO there is no much sense in testing of toString() since normally
users do not rely on it's output. However, I'd like to listen to
opinions. Does compatibility testing of toString() make sense to
anybody?
--
Alexei Zakharov,
Intel Middleware Product 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: [classlib] compatibility of toString
Posted by Anton Luht <an...@gmail.com>.
Hello,
One special case: I'd suggest to test that if you specify some text as
an constructor argument to a subclass of Throwable, then toString()
contains that text.
On 7/3/06, Tim Ellison <t....@gmail.com> wrote:
> Andrew Zhang wrote:
> > On 7/1/06, Alex Blewitt <al...@gmail.com> wrote:
> >>
> >> On 01/07/06, Andrew Zhang <zh...@gmail.com> wrote:
> >> >
> >> > Agree. But there are always exceptions. Some "toString" methods have to
> >> > contain some key information as spec required, for example, the size or
> >> > index.
> >>
> >> Can you give examples of where the spec specifically mandates the
> >> return values of either size or index?
> >
> >
> > What I mean is in some cases, toString returns a string is not enough.
> > e.g. "Harmony is Great" obviously doesn't comply with spec
> > AbstractCollection.toString() as you mentioned below.
> > Another example is CharBuffer.toString(). The spec says:
> > "Returns a string containing the characters in this buffer.
> > The first character of the resulting string will be the character at this
> > buffer's position, while the last character will be the character at index
> > limit() - 1. Invoking this method does not change the buffer's position. "
> >
> > Therefore, for these special cases, tests for toString are useful. Of
> > course, instead of comparing Harmony's toString return value with RI's, the
> > test should verify whether Harmony's toString value complys with spec. The
> > test should not look like:
> > assertEquals(RI_TOSTRING, instance.toString());
> > For CharBuffer.toString, the test may be written as following:
> > assertEquals(the character at this bufer's position, the first character of
> > toString);
> > ....
> >
> > For most other cases, IMO, Harmony doesn't need to keep the same return
> > value as RI's.
> >
> > Thanks!
>
> Yep, if the spec tells you what the format of the string should be then
> follow it (since apps may be dependent upon it), otherwise I'd be
> inclined to invent your own useful string representation.
>
> Regards.
> Tim
>
> >> BTW, are these toString information (RI) copyrighted?
> >>
> >> I don't believe they can be copyrighted. However, the only way to tell
> >> if the RI and Harmony return the same results would be to execute both
> >> and compare them, and I believe that such reverse engineering would be
> >> outside the remit of Harmony.
> >
> >
> > Agree.
> >
> > I doubt that the TCK would test for such
> >> features exactly, without specifying them. For example, the
> >> AbstractCollection and AbstractMap does specify what it should return:
> >>
> >>
> >> http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractCollection.html#toString()
> >>
> >>
> >> http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractMap.html#toString()
> >>
> >>
> >> I think you'd find it difficult to explain why (in all cases)
> >> toString() returned exactly the same value as the RI without such
> >> detailed comments as to their format :-)
> >>
> >> Alex.
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
--
Regards,
Anton Luht,
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: Re: [classlib] compatibility of toString
Posted by Alex Blewitt <al...@gmail.com>.
On 06/07/06, Tim Ellison <t....@gmail.com> wrote:
>
> Here here; if only the API was printOn(OutputStream) then we'd all be
> happy(er).
I suspect that it's hear, hear, at least there (in Parliament). :-)
Alex.
---------------------------------------------------------------------
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: [classlib] compatibility of toString
Posted by Tim Ellison <t....@gmail.com>.
Alex Blewitt wrote:
> IMNSHO I don't think we should by default copy the toString()
> behaviour from the RI, unless mandated by the spec in JavaDoc.
> Frankly, the toString() has always been undefined, and I'm sick off
> Java developers saying "Well, yes, but I always expect it to be
> [name='value',name='other value']" and then writing toString() methods
> that do exactly the same.
>
> toString() was never meant to be a dump of the object's fields and
> values. It was meant to be a string representation of the object. And
> it's an insanely ineffecient measure to dump out all of an object's
> fields using toString() anyway, because of all the wasted
> concatenation that goes on when you have nested objects.
>
> It would be much better if Java developers on the whole got over the
> fascination with toString() and its format, and used better mechanisms
> for writing out debug state (e.g. dump(Writer) *) if they needed -- or
> better yet, just used a debugger.
>
> Alex.
>
> * Why everyone wants to stream toString() values is beyond me. If you
> just write the output to a stream in the first place, you get the
> concatenation for free without having to do all that expensive memory
> manipuation.
Here here; if only the API was printOn(OutputStream) then we'd all be
happy(er).
Regards,
Tim
> On 06/07/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> Yep. No answer yet. I pinged them for an update, and also asked the
>> toString() question.
>>
>> geir
>>
>> Mikhail Loenko wrote:
>> > IIRC Geir was going to ask Sun if we are allowed to copy their
>> > exception messages
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/7/5, Richard Liang <ri...@gmail.com>:
>> >>
>> >>
>> >> Geir Magnusson Jr wrote:
>> >> > Richard Liang wrote:
>> >> >
>> >> >> Geir Magnusson Jr wrote:
>> >> >>
>> >> >>> Tim Ellison wrote:
>> >> >>>
>> >> >>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>> Yep, if the spec tells you what the format of the string should
>> >> be then
>> >> >>>> follow it (since apps may be dependent upon it), otherwise I'd be
>> >> >>>> inclined to invent your own useful string representation.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>> This idea scares me. I think people do depend on toString() when
>> >> >>> writing apps, and tend to shove that kind of thing to log files
>> >> and such
>> >> >>> on server apps. To have our outptut different from Sun's, BEA's,
>> >> IBM's,
>> >> >>> Apple's seens like we're asking for trouble.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >> Hello Geir,
>> >> >>
>> >> >> IMHO, as long as the method does not give confusing message to
>> >> >> developers, we are not required to have the same behavior. You may
>> >> want
>> >> >> to refer to the spec of java.lang.Object.toString:
>> >> >> ...
>> >> >> In general, the toString method returns a string that "textually
>> >> >> represents" this object. The result should be a concise but
>> >> informative
>> >> >> representation that is easy for **a person to read**.
>> >> >> ...
>> >> >>
>> >> >
>> >> > Sure, but that doesn't mean that it would be reasonable to randomly
>> >> > change the output of a given Class's toString() as long as it
>> would be
>> >> > easy for a person to read :)
>> >> >
>> >> > I know that's not what you are advocating, and I certainly agree
>> >> that no
>> >> > one should depend on toString() output like that, but I also know
>> that
>> >> > in production systems *I* have done it, and I'm sure others have as
>> >> well.
>> >> >
>> >> >
>> >> >> And there are some cases that we even cannot follow RI.
>> >> >> e.g.,
>> >> >> URLConnection conn = new
>> >> URL("http://www.apache.org").openConnection();
>> >> >> System.out.println(conn.toString());
>> >> >>
>> >> >> The code above will print
>> >> >> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org"
>> >> >>
>> >> >> Any comments? Thanks a lot.
>> >> >>
>> >> >
>> >> > Well, we could actually print that if that was our impl of
>> >> URLConnection
>> >> > for HTTP, but still, I think
>> >> >
>> >> >
>> "org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org"
>> >> >
>> >> > would be more reasonable than
>> >> >
>> >> > "Implementing Class : org.apache.harmony.whatever.HttpURLConnection,
>> >> > Target URI : http://www.apache.org"
>> >> >
>> >> > or something like that, even thought the second is perfectly good.
>> >> >
>> >> > All I'm saying is that unless the output from the RI's toString() is
>> >> > particularly brain-dead, it doesn't seem to be too much of a
>> bother to
>> >> > be similar.
>> >> >
>> >> >
>> >> Agree. And in fact, it's easier to have the same output as RI's if we
>> >> are allowed. :-) Could we think this rule also apply to the message
>> when
>> >> an exception is thrown?
>> >>
>> >> Any comments? Thanks a lot.
>> >>
>> >> Best regards,
>> >> Richard
>> >>
>> >> > Just my $0.02
>> >> >
>> >> > geir
>> >> >
>> >> >
>> >> >> Best regards,
>> >> >> Richard
>> >> >>
>> >> >>> 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
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > 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
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> Richard Liang
>> >> China Software Development Lab, IBM
>> >>
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: Re: [classlib] compatibility of toString
Posted by Alex Blewitt <al...@gmail.com>.
On 06/07/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
> Alex Blewitt wrote:
> > IMNSHO I don't think we should by default copy the toString()
> > behaviour from the RI, unless mandated by the spec in JavaDoc.
>
> Ok. Good rant, and I agree with it, but I still don't see a reason here
> why we shouldn't, other than to .... teach people a lesson?
If people are relying on one implementation that's undocumented
behaviour, then it's bad code. It may well fail on any other system
(inc. embedded systems, or other OS, or even between different
versions).
But the real reason is one of defense; how can you say that you've
implemented a clean-room version of the code from the spec, when all
the toString() results are identical with a proprietary implementation
that you have no way of knowing what the result should be, except by
running the propetary version to find out? Obviously, some cases it
will be obvious (e.g. we can guess what a java.net.URL looks like) but
in most cases it won't be (e.g. java.net.URLConnection).
I say that we follow the spec, and if the spec doesn't list an
explicit format, we use our own. If it is amazingly obvious (e.g. a
Point may be printed (1,2)) and it happens to correspond with the Sun
RI, then great, but we shouldn't be striving to be the same in all
cases.
Alex.
---------------------------------------------------------------------
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: [classlib] compatibility of toString
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Alex Blewitt wrote:
> IMNSHO I don't think we should by default copy the toString()
> behaviour from the RI, unless mandated by the spec in JavaDoc.
> Frankly, the toString() has always been undefined, and I'm sick off
> Java developers saying "Well, yes, but I always expect it to be
> [name='value',name='other value']" and then writing toString() methods
> that do exactly the same.
>
> toString() was never meant to be a dump of the object's fields and
> values. It was meant to be a string representation of the object. And
> it's an insanely ineffecient measure to dump out all of an object's
> fields using toString() anyway, because of all the wasted
> concatenation that goes on when you have nested objects.
>
> It would be much better if Java developers on the whole got over the
> fascination with toString() and its format, and used better mechanisms
> for writing out debug state (e.g. dump(Writer) *) if they needed -- or
> better yet, just used a debugger.
Ok. Good rant, and I agree with it, but I still don't see a reason here
why we shouldn't, other than to .... teach people a lesson?
geir
>
> Alex.
>
> * Why everyone wants to stream toString() values is beyond me. If you
> just write the output to a stream in the first place, you get the
> concatenation for free without having to do all that expensive memory
> manipuation.
>
> On 06/07/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> Yep. No answer yet. I pinged them for an update, and also asked the
>> toString() question.
>>
>> geir
>>
>> Mikhail Loenko wrote:
>> > IIRC Geir was going to ask Sun if we are allowed to copy their
>> > exception messages
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/7/5, Richard Liang <ri...@gmail.com>:
>> >>
>> >>
>> >> Geir Magnusson Jr wrote:
>> >> > Richard Liang wrote:
>> >> >
>> >> >> Geir Magnusson Jr wrote:
>> >> >>
>> >> >>> Tim Ellison wrote:
>> >> >>>
>> >> >>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>> Yep, if the spec tells you what the format of the string should
>> >> be then
>> >> >>>> follow it (since apps may be dependent upon it), otherwise I'd be
>> >> >>>> inclined to invent your own useful string representation.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>> This idea scares me. I think people do depend on toString() when
>> >> >>> writing apps, and tend to shove that kind of thing to log files
>> >> and such
>> >> >>> on server apps. To have our outptut different from Sun's, BEA's,
>> >> IBM's,
>> >> >>> Apple's seens like we're asking for trouble.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >> Hello Geir,
>> >> >>
>> >> >> IMHO, as long as the method does not give confusing message to
>> >> >> developers, we are not required to have the same behavior. You may
>> >> want
>> >> >> to refer to the spec of java.lang.Object.toString:
>> >> >> ...
>> >> >> In general, the toString method returns a string that "textually
>> >> >> represents" this object. The result should be a concise but
>> >> informative
>> >> >> representation that is easy for **a person to read**.
>> >> >> ...
>> >> >>
>> >> >
>> >> > Sure, but that doesn't mean that it would be reasonable to randomly
>> >> > change the output of a given Class's toString() as long as it
>> would be
>> >> > easy for a person to read :)
>> >> >
>> >> > I know that's not what you are advocating, and I certainly agree
>> >> that no
>> >> > one should depend on toString() output like that, but I also know
>> that
>> >> > in production systems *I* have done it, and I'm sure others have as
>> >> well.
>> >> >
>> >> >
>> >> >> And there are some cases that we even cannot follow RI.
>> >> >> e.g.,
>> >> >> URLConnection conn = new
>> >> URL("http://www.apache.org").openConnection();
>> >> >> System.out.println(conn.toString());
>> >> >>
>> >> >> The code above will print
>> >> >> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org"
>> >> >>
>> >> >> Any comments? Thanks a lot.
>> >> >>
>> >> >
>> >> > Well, we could actually print that if that was our impl of
>> >> URLConnection
>> >> > for HTTP, but still, I think
>> >> >
>> >> >
>> "org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org"
>> >> >
>> >> > would be more reasonable than
>> >> >
>> >> > "Implementing Class : org.apache.harmony.whatever.HttpURLConnection,
>> >> > Target URI : http://www.apache.org"
>> >> >
>> >> > or something like that, even thought the second is perfectly good.
>> >> >
>> >> > All I'm saying is that unless the output from the RI's toString() is
>> >> > particularly brain-dead, it doesn't seem to be too much of a
>> bother to
>> >> > be similar.
>> >> >
>> >> >
>> >> Agree. And in fact, it's easier to have the same output as RI's if we
>> >> are allowed. :-) Could we think this rule also apply to the message
>> when
>> >> an exception is thrown?
>> >>
>> >> Any comments? Thanks a lot.
>> >>
>> >> Best regards,
>> >> Richard
>> >>
>> >> > Just my $0.02
>> >> >
>> >> > geir
>> >> >
>> >> >
>> >> >> Best regards,
>> >> >> Richard
>> >> >>
>> >> >>> 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
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > 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
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> Richard Liang
>> >> China Software Development Lab, IBM
>> >>
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: Re: [classlib] compatibility of toString
Posted by Alex Blewitt <al...@gmail.com>.
IMNSHO I don't think we should by default copy the toString()
behaviour from the RI, unless mandated by the spec in JavaDoc.
Frankly, the toString() has always been undefined, and I'm sick off
Java developers saying "Well, yes, but I always expect it to be
[name='value',name='other value']" and then writing toString() methods
that do exactly the same.
toString() was never meant to be a dump of the object's fields and
values. It was meant to be a string representation of the object. And
it's an insanely ineffecient measure to dump out all of an object's
fields using toString() anyway, because of all the wasted
concatenation that goes on when you have nested objects.
It would be much better if Java developers on the whole got over the
fascination with toString() and its format, and used better mechanisms
for writing out debug state (e.g. dump(Writer) *) if they needed -- or
better yet, just used a debugger.
Alex.
* Why everyone wants to stream toString() values is beyond me. If you
just write the output to a stream in the first place, you get the
concatenation for free without having to do all that expensive memory
manipuation.
On 06/07/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Yep. No answer yet. I pinged them for an update, and also asked the
> toString() question.
>
> geir
>
> Mikhail Loenko wrote:
> > IIRC Geir was going to ask Sun if we are allowed to copy their
> > exception messages
> >
> > Thanks,
> > Mikhail
> >
> > 2006/7/5, Richard Liang <ri...@gmail.com>:
> >>
> >>
> >> Geir Magnusson Jr wrote:
> >> > Richard Liang wrote:
> >> >
> >> >> Geir Magnusson Jr wrote:
> >> >>
> >> >>> Tim Ellison wrote:
> >> >>>
> >> >>>
> >> >>>>>
> >> >>>>>
> >> >>>> Yep, if the spec tells you what the format of the string should
> >> be then
> >> >>>> follow it (since apps may be dependent upon it), otherwise I'd be
> >> >>>> inclined to invent your own useful string representation.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>> This idea scares me. I think people do depend on toString() when
> >> >>> writing apps, and tend to shove that kind of thing to log files
> >> and such
> >> >>> on server apps. To have our outptut different from Sun's, BEA's,
> >> IBM's,
> >> >>> Apple's seens like we're asking for trouble.
> >> >>>
> >> >>>
> >> >>>
> >> >> Hello Geir,
> >> >>
> >> >> IMHO, as long as the method does not give confusing message to
> >> >> developers, we are not required to have the same behavior. You may
> >> want
> >> >> to refer to the spec of java.lang.Object.toString:
> >> >> ...
> >> >> In general, the toString method returns a string that "textually
> >> >> represents" this object. The result should be a concise but
> >> informative
> >> >> representation that is easy for **a person to read**.
> >> >> ...
> >> >>
> >> >
> >> > Sure, but that doesn't mean that it would be reasonable to randomly
> >> > change the output of a given Class's toString() as long as it would be
> >> > easy for a person to read :)
> >> >
> >> > I know that's not what you are advocating, and I certainly agree
> >> that no
> >> > one should depend on toString() output like that, but I also know that
> >> > in production systems *I* have done it, and I'm sure others have as
> >> well.
> >> >
> >> >
> >> >> And there are some cases that we even cannot follow RI.
> >> >> e.g.,
> >> >> URLConnection conn = new
> >> URL("http://www.apache.org").openConnection();
> >> >> System.out.println(conn.toString());
> >> >>
> >> >> The code above will print
> >> >> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org"
> >> >>
> >> >> Any comments? Thanks a lot.
> >> >>
> >> >
> >> > Well, we could actually print that if that was our impl of
> >> URLConnection
> >> > for HTTP, but still, I think
> >> >
> >> > "org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org"
> >> >
> >> > would be more reasonable than
> >> >
> >> > "Implementing Class : org.apache.harmony.whatever.HttpURLConnection,
> >> > Target URI : http://www.apache.org"
> >> >
> >> > or something like that, even thought the second is perfectly good.
> >> >
> >> > All I'm saying is that unless the output from the RI's toString() is
> >> > particularly brain-dead, it doesn't seem to be too much of a bother to
> >> > be similar.
> >> >
> >> >
> >> Agree. And in fact, it's easier to have the same output as RI's if we
> >> are allowed. :-) Could we think this rule also apply to the message when
> >> an exception is thrown?
> >>
> >> Any comments? Thanks a lot.
> >>
> >> Best regards,
> >> Richard
> >>
> >> > Just my $0.02
> >> >
> >> > geir
> >> >
> >> >
> >> >> Best regards,
> >> >> Richard
> >> >>
> >> >>> 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
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >> >
> >> >
> >> >
> >>
> >> --
> >> Richard Liang
> >> China Software Development Lab, IBM
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
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: [classlib] compatibility of toString
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Yep. No answer yet. I pinged them for an update, and also asked the
toString() question.
geir
Mikhail Loenko wrote:
> IIRC Geir was going to ask Sun if we are allowed to copy their
> exception messages
>
> Thanks,
> Mikhail
>
> 2006/7/5, Richard Liang <ri...@gmail.com>:
>>
>>
>> Geir Magnusson Jr wrote:
>> > Richard Liang wrote:
>> >
>> >> Geir Magnusson Jr wrote:
>> >>
>> >>> Tim Ellison wrote:
>> >>>
>> >>>
>> >>>>>
>> >>>>>
>> >>>> Yep, if the spec tells you what the format of the string should
>> be then
>> >>>> follow it (since apps may be dependent upon it), otherwise I'd be
>> >>>> inclined to invent your own useful string representation.
>> >>>>
>> >>>>
>> >>>>
>> >>> This idea scares me. I think people do depend on toString() when
>> >>> writing apps, and tend to shove that kind of thing to log files
>> and such
>> >>> on server apps. To have our outptut different from Sun's, BEA's,
>> IBM's,
>> >>> Apple's seens like we're asking for trouble.
>> >>>
>> >>>
>> >>>
>> >> Hello Geir,
>> >>
>> >> IMHO, as long as the method does not give confusing message to
>> >> developers, we are not required to have the same behavior. You may
>> want
>> >> to refer to the spec of java.lang.Object.toString:
>> >> ...
>> >> In general, the toString method returns a string that "textually
>> >> represents" this object. The result should be a concise but
>> informative
>> >> representation that is easy for **a person to read**.
>> >> ...
>> >>
>> >
>> > Sure, but that doesn't mean that it would be reasonable to randomly
>> > change the output of a given Class's toString() as long as it would be
>> > easy for a person to read :)
>> >
>> > I know that's not what you are advocating, and I certainly agree
>> that no
>> > one should depend on toString() output like that, but I also know that
>> > in production systems *I* have done it, and I'm sure others have as
>> well.
>> >
>> >
>> >> And there are some cases that we even cannot follow RI.
>> >> e.g.,
>> >> URLConnection conn = new
>> URL("http://www.apache.org").openConnection();
>> >> System.out.println(conn.toString());
>> >>
>> >> The code above will print
>> >> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org"
>> >>
>> >> Any comments? Thanks a lot.
>> >>
>> >
>> > Well, we could actually print that if that was our impl of
>> URLConnection
>> > for HTTP, but still, I think
>> >
>> > "org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org"
>> >
>> > would be more reasonable than
>> >
>> > "Implementing Class : org.apache.harmony.whatever.HttpURLConnection,
>> > Target URI : http://www.apache.org"
>> >
>> > or something like that, even thought the second is perfectly good.
>> >
>> > All I'm saying is that unless the output from the RI's toString() is
>> > particularly brain-dead, it doesn't seem to be too much of a bother to
>> > be similar.
>> >
>> >
>> Agree. And in fact, it's easier to have the same output as RI's if we
>> are allowed. :-) Could we think this rule also apply to the message when
>> an exception is thrown?
>>
>> Any comments? Thanks a lot.
>>
>> Best regards,
>> Richard
>>
>> > Just my $0.02
>> >
>> > geir
>> >
>> >
>> >> Best regards,
>> >> Richard
>> >>
>> >>> 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
>> >>>
>> >>>
>> >>>
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > 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
>> >
>> >
>> >
>>
>> --
>> Richard Liang
>> China Software Development Lab, IBM
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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: [classlib] compatibility of toString
Posted by Mikhail Loenko <ml...@gmail.com>.
IIRC Geir was going to ask Sun if we are allowed to copy their
exception messages
Thanks,
Mikhail
2006/7/5, Richard Liang <ri...@gmail.com>:
>
>
> Geir Magnusson Jr wrote:
> > Richard Liang wrote:
> >
> >> Geir Magnusson Jr wrote:
> >>
> >>> Tim Ellison wrote:
> >>>
> >>>
> >>>>>
> >>>>>
> >>>> Yep, if the spec tells you what the format of the string should be then
> >>>> follow it (since apps may be dependent upon it), otherwise I'd be
> >>>> inclined to invent your own useful string representation.
> >>>>
> >>>>
> >>>>
> >>> This idea scares me. I think people do depend on toString() when
> >>> writing apps, and tend to shove that kind of thing to log files and such
> >>> on server apps. To have our outptut different from Sun's, BEA's, IBM's,
> >>> Apple's seens like we're asking for trouble.
> >>>
> >>>
> >>>
> >> Hello Geir,
> >>
> >> IMHO, as long as the method does not give confusing message to
> >> developers, we are not required to have the same behavior. You may want
> >> to refer to the spec of java.lang.Object.toString:
> >> ...
> >> In general, the toString method returns a string that "textually
> >> represents" this object. The result should be a concise but informative
> >> representation that is easy for **a person to read**.
> >> ...
> >>
> >
> > Sure, but that doesn't mean that it would be reasonable to randomly
> > change the output of a given Class's toString() as long as it would be
> > easy for a person to read :)
> >
> > I know that's not what you are advocating, and I certainly agree that no
> > one should depend on toString() output like that, but I also know that
> > in production systems *I* have done it, and I'm sure others have as well.
> >
> >
> >> And there are some cases that we even cannot follow RI.
> >> e.g.,
> >> URLConnection conn = new URL("http://www.apache.org").openConnection();
> >> System.out.println(conn.toString());
> >>
> >> The code above will print
> >> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org"
> >>
> >> Any comments? Thanks a lot.
> >>
> >
> > Well, we could actually print that if that was our impl of URLConnection
> > for HTTP, but still, I think
> >
> > "org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org"
> >
> > would be more reasonable than
> >
> > "Implementing Class : org.apache.harmony.whatever.HttpURLConnection,
> > Target URI : http://www.apache.org"
> >
> > or something like that, even thought the second is perfectly good.
> >
> > All I'm saying is that unless the output from the RI's toString() is
> > particularly brain-dead, it doesn't seem to be too much of a bother to
> > be similar.
> >
> >
> Agree. And in fact, it's easier to have the same output as RI's if we
> are allowed. :-) Could we think this rule also apply to the message when
> an exception is thrown?
>
> Any comments? Thanks a lot.
>
> Best regards,
> Richard
>
> > Just my $0.02
> >
> > geir
> >
> >
> >> Best regards,
> >> Richard
> >>
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> >
>
> --
> Richard Liang
> China Software Development Lab, IBM
>
>
>
---------------------------------------------------------------------
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: [classlib] compatibility of toString
Posted by Richard Liang <ri...@gmail.com>.
Geir Magnusson Jr wrote:
> Richard Liang wrote:
>
>> Geir Magnusson Jr wrote:
>>
>>> Tim Ellison wrote:
>>>
>>>
>>>>>
>>>>>
>>>> Yep, if the spec tells you what the format of the string should be then
>>>> follow it (since apps may be dependent upon it), otherwise I'd be
>>>> inclined to invent your own useful string representation.
>>>>
>>>>
>>>>
>>> This idea scares me. I think people do depend on toString() when
>>> writing apps, and tend to shove that kind of thing to log files and such
>>> on server apps. To have our outptut different from Sun's, BEA's, IBM's,
>>> Apple's seens like we're asking for trouble.
>>>
>>>
>>>
>> Hello Geir,
>>
>> IMHO, as long as the method does not give confusing message to
>> developers, we are not required to have the same behavior. You may want
>> to refer to the spec of java.lang.Object.toString:
>> ...
>> In general, the toString method returns a string that "textually
>> represents" this object. The result should be a concise but informative
>> representation that is easy for **a person to read**.
>> ...
>>
>
> Sure, but that doesn't mean that it would be reasonable to randomly
> change the output of a given Class's toString() as long as it would be
> easy for a person to read :)
>
> I know that's not what you are advocating, and I certainly agree that no
> one should depend on toString() output like that, but I also know that
> in production systems *I* have done it, and I'm sure others have as well.
>
>
>> And there are some cases that we even cannot follow RI.
>> e.g.,
>> URLConnection conn = new URL("http://www.apache.org").openConnection();
>> System.out.println(conn.toString());
>>
>> The code above will print
>> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org"
>>
>> Any comments? Thanks a lot.
>>
>
> Well, we could actually print that if that was our impl of URLConnection
> for HTTP, but still, I think
>
> "org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org"
>
> would be more reasonable than
>
> "Implementing Class : org.apache.harmony.whatever.HttpURLConnection,
> Target URI : http://www.apache.org"
>
> or something like that, even thought the second is perfectly good.
>
> All I'm saying is that unless the output from the RI's toString() is
> particularly brain-dead, it doesn't seem to be too much of a bother to
> be similar.
>
>
Agree. And in fact, it's easier to have the same output as RI's if we
are allowed. :-) Could we think this rule also apply to the message when
an exception is thrown?
Any comments? Thanks a lot.
Best regards,
Richard
> Just my $0.02
>
> geir
>
>
>> Best regards,
>> Richard
>>
>>> 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
>>>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: [classlib] compatibility of toString
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Richard Liang wrote:
>
>
> Geir Magnusson Jr wrote:
>> Tim Ellison wrote:
>>
>>>>
>>> Yep, if the spec tells you what the format of the string should be then
>>> follow it (since apps may be dependent upon it), otherwise I'd be
>>> inclined to invent your own useful string representation.
>>>
>>>
>>
>> This idea scares me. I think people do depend on toString() when
>> writing apps, and tend to shove that kind of thing to log files and such
>> on server apps. To have our outptut different from Sun's, BEA's, IBM's,
>> Apple's seens like we're asking for trouble.
>>
>>
> Hello Geir,
>
> IMHO, as long as the method does not give confusing message to
> developers, we are not required to have the same behavior. You may want
> to refer to the spec of java.lang.Object.toString:
> ...
> In general, the toString method returns a string that "textually
> represents" this object. The result should be a concise but informative
> representation that is easy for **a person to read**.
> ...
Sure, but that doesn't mean that it would be reasonable to randomly
change the output of a given Class's toString() as long as it would be
easy for a person to read :)
I know that's not what you are advocating, and I certainly agree that no
one should depend on toString() output like that, but I also know that
in production systems *I* have done it, and I'm sure others have as well.
>
> And there are some cases that we even cannot follow RI.
> e.g.,
> URLConnection conn = new URL("http://www.apache.org").openConnection();
> System.out.println(conn.toString());
>
> The code above will print
> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org"
>
> Any comments? Thanks a lot.
Well, we could actually print that if that was our impl of URLConnection
for HTTP, but still, I think
"org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org"
would be more reasonable than
"Implementing Class : org.apache.harmony.whatever.HttpURLConnection,
Target URI : http://www.apache.org"
or something like that, even thought the second is perfectly good.
All I'm saying is that unless the output from the RI's toString() is
particularly brain-dead, it doesn't seem to be too much of a bother to
be similar.
Just my $0.02
geir
>
> Best regards,
> Richard
>> 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
>>
>>
>>
>
---------------------------------------------------------------------
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: [classlib] compatibility of toString
Posted by Richard Liang <ri...@gmail.com>.
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>
>> Andrew Zhang wrote:
>>
>>> On 7/1/06, Alex Blewitt <al...@gmail.com> wrote:
>>>
>>>> On 01/07/06, Andrew Zhang <zh...@gmail.com> wrote:
>>>>
>>>>> Agree. But there are always exceptions. Some "toString" methods have to
>>>>> contain some key information as spec required, for example, the size or
>>>>> index.
>>>>>
>>>> Can you give examples of where the spec specifically mandates the
>>>> return values of either size or index?
>>>>
>>> What I mean is in some cases, toString returns a string is not enough.
>>> e.g. "Harmony is Great" obviously doesn't comply with spec
>>> AbstractCollection.toString() as you mentioned below.
>>> Another example is CharBuffer.toString(). The spec says:
>>> "Returns a string containing the characters in this buffer.
>>> The first character of the resulting string will be the character at this
>>> buffer's position, while the last character will be the character at index
>>> limit() - 1. Invoking this method does not change the buffer's position. "
>>>
>>> Therefore, for these special cases, tests for toString are useful. Of
>>> course, instead of comparing Harmony's toString return value with RI's, the
>>> test should verify whether Harmony's toString value complys with spec. The
>>> test should not look like:
>>> assertEquals(RI_TOSTRING, instance.toString());
>>> For CharBuffer.toString, the test may be written as following:
>>> assertEquals(the character at this bufer's position, the first character of
>>> toString);
>>> ....
>>>
>>> For most other cases, IMO, Harmony doesn't need to keep the same return
>>> value as RI's.
>>>
>>> Thanks!
>>>
>> Yep, if the spec tells you what the format of the string should be then
>> follow it (since apps may be dependent upon it), otherwise I'd be
>> inclined to invent your own useful string representation.
>>
>>
>
> This idea scares me. I think people do depend on toString() when
> writing apps, and tend to shove that kind of thing to log files and such
> on server apps. To have our outptut different from Sun's, BEA's, IBM's,
> Apple's seens like we're asking for trouble.
>
>
Hello Geir,
IMHO, as long as the method does not give confusing message to
developers, we are not required to have the same behavior. You may want
to refer to the spec of java.lang.Object.toString:
...
In general, the toString method returns a string that "textually
represents" this object. The result should be a concise but informative
representation that is easy for **a person to read**.
...
And there are some cases that we even cannot follow RI.
e.g.,
URLConnection conn = new URL("http://www.apache.org").openConnection();
System.out.println(conn.toString());
The code above will print
"sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org"
Any comments? Thanks a lot.
Best regards,
Richard
> 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
>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: [classlib] compatibility of toString
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Andrew Zhang wrote:
>> On 7/1/06, Alex Blewitt <al...@gmail.com> wrote:
>>> On 01/07/06, Andrew Zhang <zh...@gmail.com> wrote:
>>>> Agree. But there are always exceptions. Some "toString" methods have to
>>>> contain some key information as spec required, for example, the size or
>>>> index.
>>> Can you give examples of where the spec specifically mandates the
>>> return values of either size or index?
>>
>> What I mean is in some cases, toString returns a string is not enough.
>> e.g. "Harmony is Great" obviously doesn't comply with spec
>> AbstractCollection.toString() as you mentioned below.
>> Another example is CharBuffer.toString(). The spec says:
>> "Returns a string containing the characters in this buffer.
>> The first character of the resulting string will be the character at this
>> buffer's position, while the last character will be the character at index
>> limit() - 1. Invoking this method does not change the buffer's position. "
>>
>> Therefore, for these special cases, tests for toString are useful. Of
>> course, instead of comparing Harmony's toString return value with RI's, the
>> test should verify whether Harmony's toString value complys with spec. The
>> test should not look like:
>> assertEquals(RI_TOSTRING, instance.toString());
>> For CharBuffer.toString, the test may be written as following:
>> assertEquals(the character at this bufer's position, the first character of
>> toString);
>> ....
>>
>> For most other cases, IMO, Harmony doesn't need to keep the same return
>> value as RI's.
>>
>> Thanks!
>
> Yep, if the spec tells you what the format of the string should be then
> follow it (since apps may be dependent upon it), otherwise I'd be
> inclined to invent your own useful string representation.
>
This idea scares me. I think people do depend on toString() when
writing apps, and tend to shove that kind of thing to log files and such
on server apps. To have our outptut different from Sun's, BEA's, IBM's,
Apple's seens like we're asking for trouble.
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: [classlib] compatibility of toString
Posted by Tim Ellison <t....@gmail.com>.
Andrew Zhang wrote:
> On 7/1/06, Alex Blewitt <al...@gmail.com> wrote:
>>
>> On 01/07/06, Andrew Zhang <zh...@gmail.com> wrote:
>> >
>> > Agree. But there are always exceptions. Some "toString" methods have to
>> > contain some key information as spec required, for example, the size or
>> > index.
>>
>> Can you give examples of where the spec specifically mandates the
>> return values of either size or index?
>
>
> What I mean is in some cases, toString returns a string is not enough.
> e.g. "Harmony is Great" obviously doesn't comply with spec
> AbstractCollection.toString() as you mentioned below.
> Another example is CharBuffer.toString(). The spec says:
> "Returns a string containing the characters in this buffer.
> The first character of the resulting string will be the character at this
> buffer's position, while the last character will be the character at index
> limit() - 1. Invoking this method does not change the buffer's position. "
>
> Therefore, for these special cases, tests for toString are useful. Of
> course, instead of comparing Harmony's toString return value with RI's, the
> test should verify whether Harmony's toString value complys with spec. The
> test should not look like:
> assertEquals(RI_TOSTRING, instance.toString());
> For CharBuffer.toString, the test may be written as following:
> assertEquals(the character at this bufer's position, the first character of
> toString);
> ....
>
> For most other cases, IMO, Harmony doesn't need to keep the same return
> value as RI's.
>
> Thanks!
Yep, if the spec tells you what the format of the string should be then
follow it (since apps may be dependent upon it), otherwise I'd be
inclined to invent your own useful string representation.
Regards.
Tim
>> BTW, are these toString information (RI) copyrighted?
>>
>> I don't believe they can be copyrighted. However, the only way to tell
>> if the RI and Harmony return the same results would be to execute both
>> and compare them, and I believe that such reverse engineering would be
>> outside the remit of Harmony.
>
>
> Agree.
>
> I doubt that the TCK would test for such
>> features exactly, without specifying them. For example, the
>> AbstractCollection and AbstractMap does specify what it should return:
>>
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractCollection.html#toString()
>>
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractMap.html#toString()
>>
>>
>> I think you'd find it difficult to explain why (in all cases)
>> toString() returned exactly the same value as the RI without such
>> detailed comments as to their format :-)
>>
>> Alex.
>>
>> ---------------------------------------------------------------------
>> 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: Re: [classlib] compatibility of toString
Posted by Andrew Zhang <zh...@gmail.com>.
On 7/1/06, Alex Blewitt <al...@gmail.com> wrote:
>
> On 01/07/06, Andrew Zhang <zh...@gmail.com> wrote:
> >
> > Agree. But there are always exceptions. Some "toString" methods have to
> > contain some key information as spec required, for example, the size or
> > index.
>
> Can you give examples of where the spec specifically mandates the
> return values of either size or index?
What I mean is in some cases, toString returns a string is not enough.
e.g. "Harmony is Great" obviously doesn't comply with spec
AbstractCollection.toString() as you mentioned below.
Another example is CharBuffer.toString(). The spec says:
"Returns a string containing the characters in this buffer.
The first character of the resulting string will be the character at this
buffer's position, while the last character will be the character at index
limit() - 1. Invoking this method does not change the buffer's position. "
Therefore, for these special cases, tests for toString are useful. Of
course, instead of comparing Harmony's toString return value with RI's, the
test should verify whether Harmony's toString value complys with spec. The
test should not look like:
assertEquals(RI_TOSTRING, instance.toString());
For CharBuffer.toString, the test may be written as following:
assertEquals(the character at this bufer's position, the first character of
toString);
....
For most other cases, IMO, Harmony doesn't need to keep the same return
value as RI's.
Thanks!
> BTW, are these toString information (RI) copyrighted?
>
> I don't believe they can be copyrighted. However, the only way to tell
> if the RI and Harmony return the same results would be to execute both
> and compare them, and I believe that such reverse engineering would be
> outside the remit of Harmony.
Agree.
I doubt that the TCK would test for such
> features exactly, without specifying them. For example, the
> AbstractCollection and AbstractMap does specify what it should return:
>
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractCollection.html#toString()
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractMap.html#toString()
>
> I think you'd find it difficult to explain why (in all cases)
> toString() returned exactly the same value as the RI without such
> detailed comments as to their format :-)
>
> Alex.
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: Re: [classlib] compatibility of toString
Posted by Alex Blewitt <al...@gmail.com>.
On 01/07/06, Andrew Zhang <zh...@gmail.com> wrote:
>
> Agree. But there are always exceptions. Some "toString" methods have to
> contain some key information as spec required, for example, the size or
> index.
Can you give examples of where the spec specifically mandates the
return values of either size or index?
> BTW, are these toString information (RI) copyrighted?
I don't believe they can be copyrighted. However, the only way to tell
if the RI and Harmony return the same results would be to execute both
and compare them, and I believe that such reverse engineering would be
outside the remit of Harmony. I doubt that the TCK would test for such
features exactly, without specifying them. For example, the
AbstractCollection and AbstractMap does specify what it should return:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractCollection.html#toString()
http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractMap.html#toString()
I think you'd find it difficult to explain why (in all cases)
toString() returned exactly the same value as the RI without such
detailed comments as to their format :-)
Alex.
---------------------------------------------------------------------
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: [classlib] compatibility of toString
Posted by Andrew Zhang <zh...@gmail.com>.
On 7/1/06, Alex Blewitt <al...@gmail.com> wrote:
>
> I'd say that (like hashCode()) there's not a lot of point in testing
> the exact output, only behaviour. In other words, if it returns a
> String, that should be good enough. There's nothing in the spec to say
> what it should be -- all of the toString() methods could return
> "Harmony is Great!" and it'd still be within spec.
Agree. But there are always exceptions. Some "toString" methods have to
contain some key information as spec required, for example, the size or
index. However, it's still difficult to test the string information.
Generally speaking, I totally agree with you that "if it returns a String,
that should be good enough.".
BTW, are these toString information (RI) copyrighted?
Thanks!
> I suspect that tests that look at the exact output for toString() are
> being done because it may be a quick-and-dirty way of testing all
> properties set in a JavaBean-esque way.
>
> OTOH there are some things that probably are worth testing -- IIRC the
> XxxList implementations return [...] when the list grows beyond a
> certain size (1000?) to avoid doing an insane amount of toString
> calculation. That's the kind of property that I would expect to be
> tested in that particular test case.
>
> Alex.
>
> On 30/06/06, Alexei Zakharov <al...@gmail.com> wrote:
> > Hi community!
> >
> > While looking through some of java.beans tests I found many places
> > where exact output of toString() method is being tested. Moreover, the
> > test patterns differ from the output generated by RI's toString's.
> >
> > IMHO there is no much sense in testing of toString() since normally
> > users do not rely on it's output. However, I'd like to listen to
> > opinions. Does compatibility testing of toString() make sense to
> > anybody?
> >
> > --
> > Alexei Zakharov,
> > Intel Middleware Product 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] compatibility of toString
Posted by Alex Blewitt <al...@gmail.com>.
I'd say that (like hashCode()) there's not a lot of point in testing
the exact output, only behaviour. In other words, if it returns a
String, that should be good enough. There's nothing in the spec to say
what it should be -- all of the toString() methods could return
"Harmony is Great!" and it'd still be within spec.
I suspect that tests that look at the exact output for toString() are
being done because it may be a quick-and-dirty way of testing all
properties set in a JavaBean-esque way.
OTOH there are some things that probably are worth testing -- IIRC the
XxxList implementations return [...] when the list grows beyond a
certain size (1000?) to avoid doing an insane amount of toString
calculation. That's the kind of property that I would expect to be
tested in that particular test case.
Alex.
On 30/06/06, Alexei Zakharov <al...@gmail.com> wrote:
> Hi community!
>
> While looking through some of java.beans tests I found many places
> where exact output of toString() method is being tested. Moreover, the
> test patterns differ from the output generated by RI's toString's.
>
> IMHO there is no much sense in testing of toString() since normally
> users do not rely on it's output. However, I'd like to listen to
> opinions. Does compatibility testing of toString() make sense to
> anybody?
>
> --
> Alexei Zakharov,
> Intel Middleware Product 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