harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Spark Shen <smallsmallor...@gmail.com>
Subject Re: [classlib]bug-to-bug compatibility j.u.Formatter
Date Wed, 26 Jul 2006 01:57:13 GMT
Anton Luht 写道:
> Hello,
>> And there are places RI behaves irrational and not compatible with RI.
> You mean RI behaves not compatible with spec? :)
Hi, Anton:
*Irrational* may be not a good word, is *illogical *better?. :-) In some 
places, RI does behave differently from RI.

This can be proved by the test cases Richard and I provided earlier:
public void test_ConstructorLjava_lang_Appendable() {
Formatter formatter = new Formatter((Appendable) null);

*// RI will throw a java.util.FormatterClosedException here, which is 
not compatible with RI
// "If appendable is null, then a StringBuilder will be created", cited 
from spec.
* Appendable out = formatter.out();

assertTrue(out instanceof StringBuilder);

public void 
test_formatLjava_lang_String$Ljava_lang_Object_BigDecimalConversionF() {
f = new Formatter(Locale.US);
f.format("%f", new BigDecimal("5.0E9"));
*// error on RI
// RI throw ArrayIndexOutOfBoundsException
// This behavior here is illogical.
* assertEquals("5000000000.000000", f.toString());

IMHO, following RI under these situations may not be a good choice. 
Since there seems no ubiquitous opinion about
how to deal with these differences, record them down, as Richard had 
suggested, may be a better choice.

That's the reason why some test cases do not pass on RI (Sun 5.0.7) as 
Nathan pointed out eailer. The reason is the test cases chooses to
follow Spec, but not RI's specific, sometimes odd behavior on these 

Best regards

Spark Shen
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

View raw message