Re: Re: [classlib] compatibility of toString

2006-07-07 Thread Alex Blewitt
On 06/07/06, Geir Magnusson Jr [EMAIL PROTECTED] 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,

Re: Re: [classlib] compatibility of toString

2006-07-07 Thread Alex Blewitt
On 06/07/06, Tim Ellison [EMAIL PROTECTED] 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 :

Re: RE: Re: [classlib] compatibility of toString

2006-07-07 Thread Alex Blewitt
On 07/07/06, Magnusson, Geir [EMAIL PROTECTED] wrote: 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). No kidding. Welcome to the

Re: Re: [classlib] compatibility of toString

2006-07-06 Thread Alex Blewitt
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

Re: [classlib] compatibility of toString

2006-07-06 Thread Geir Magnusson Jr
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

Re: [classlib] compatibility of toString

2006-07-06 Thread Tim Ellison
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

Re: [classlib] compatibility of toString

2006-07-05 Thread Geir Magnusson Jr
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 [EMAIL PROTECTED]: Geir Magnusson Jr wrote:

Re: [classlib] compatibility of toString

2006-07-04 Thread Geir Magnusson Jr
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

Re: [classlib] compatibility of toString

2006-07-04 Thread Richard Liang
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

Re: [classlib] compatibility of toString

2006-07-04 Thread Mikhail Loenko
IIRC Geir was going to ask Sun if we are allowed to copy their exception messages Thanks, Mikhail 2006/7/5, Richard Liang [EMAIL PROTECTED]: 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

Re: [classlib] compatibility of toString

2006-07-03 Thread Tim Ellison
Andrew Zhang wrote: On 7/1/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 01/07/06, Andrew Zhang [EMAIL PROTECTED] 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

Re: [classlib] compatibility of toString

2006-07-03 Thread Anton Luht
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 [EMAIL PROTECTED] wrote: Andrew Zhang wrote: On 7/1/06, Alex Blewitt [EMAIL PROTECTED] wrote: On

Re: [classlib] compatibility of toString

2006-07-03 Thread Geir Magnusson Jr
Tim Ellison wrote: Andrew Zhang wrote: On 7/1/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 01/07/06, Andrew Zhang [EMAIL PROTECTED] 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.

Re: [classlib] compatibility of toString

2006-07-03 Thread Richard Liang
Geir Magnusson Jr wrote: Tim Ellison wrote: Andrew Zhang wrote: On 7/1/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 01/07/06, Andrew Zhang [EMAIL PROTECTED] wrote: Agree. But there are always exceptions. Some toString methods have to contain some key information as

Re: Re: [classlib] compatibility of toString

2006-07-01 Thread Alex Blewitt
On 01/07/06, Andrew Zhang [EMAIL PROTECTED] 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

Re: Re: [classlib] compatibility of toString

2006-07-01 Thread Andrew Zhang
On 7/1/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 01/07/06, Andrew Zhang [EMAIL PROTECTED] 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

[classlib] compatibility of toString

2006-06-30 Thread Alexei Zakharov
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

Re: [classlib] compatibility of toString

2006-06-30 Thread Alex Blewitt
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