[classlib][test] "fail" statements omitted in many exception catching test cases
Hi All,
In our unit test of classlib, there are huge number of test cases about
exception catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail("Expected an exception");*
} catch (SomeException e){
// Expected
}
If we omit the "fail" statement, the test case is wrong because the
exception-throwing checking is disabled.
I've found that the "fail" statement is omitted in many test cases of our
Harmony classlib. So I set some rules to find out all lines of code related
with it. If a line of code comform all the 5 rules, it may be a bug:
1.in a "*Test.java" file
2.does not start with "//"
3.contains "catch"
4.its previous line does not contains "fail"
5.its next line contains "//" or "}"
Then I found out 1711 lines of code in 309 files comform all the 5 rules in
r450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above
style.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711(line
number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileInputStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOutputStreamTest.java:35
..
*I must say frankly that it's hard to find out all bugs of this kind without
any "victims" automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs? Pls.
share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarFileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\1099\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipFileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipInputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallbackTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTest.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionTest.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermissionTest.java:267\386
.\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\257\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
.\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java:2404
.\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialTest.java:169\179\189
.\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.java:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\1125\1133\1141\1142\1151\1152\1161\1162
.\auth\src\test\java\common\org\apache\harmony\auth\login\DefaultConfigParserTest.java:79\182
.\awt\src\test\api\java\common\java\awt\color\ICC_ProfileRTest.java:37
.\awt\src\test\api\java\common\java\awt\ComponentTest.java:751
.\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711
.\awt\src\test\api\java\windows\org\apache\harmony\awt\tests\java\awt\WinFontTest.java:427
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251\1388
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334
.\concurrent\standard\src\test\java\AbstractExecutorServiceTest.java:215\235\253\306\311\340\341\353\389\403\418\436\454\473\488\521\541\562\578\595\610\628\646\665\680\697\730\750\771
.\concurrent\standard\src\test\java\AbstractQueuedSynchronizerTest.java:76\92\162\365\514\531\631\645\660\677\692\709\724\741\756\976\1007\1039\1236\1260
.\concurrent\standard\src\test\java\AbstractQueueTest.java:62\74\94\115\128\1
Re: [classlib]volunteer to supply patches for old JIRAs
Andrew Zhang 写道: On 9/13/06, Tony Wu <[EMAIL PROTECTED]> wrote: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Great! Is there anyone alse has interest and would like to work with me? Let me see whether I can contribute something. I'll take a look at those opened jiras which is related to nio/net/charset. -- Tony Wu China Software Development Lab, IBM Good! I want to contribute something too, and I think there are many volunteers. To avoid redundant work, I think one can simply add a comment to his/her interested JIRA to indicate that he/she is working on it. OK? :-) -- Robert Hu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni]difference between RI and ICU
Tony Wu 写道:
I encounter a problem when implement isWhiteSpace(int) in j.l.Character.
There is a difference between RI and ICU.
RI spec says,
It is a Unicode szpace character (SPACE_SEPARATOR, LINE_SEPARATOR, or
PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0',
'\u2007', '\u202F').
Anyway, spec is our first rule to follow.
but ICU spec says,
It is a Unicode space separator (category "Zs"), but is not a no-break
space (\u00A0 or \u202F or \uFEFF).
RI excludes U+2007 however ICU excludes U+FEFF
And I looked up the definition of these 4 related characters on
unicode.org:
00A0;NO-BREAK SPACE;Zs;0;CS; 0020N;NON-BREAKING SPACE
2007;FIGURE SPACE;Zs;0;WS; 0020N;
202F;NARROW NO-BREAK SPACE;Zs;0;CS; 0020N;
FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;N;BYTE ORDER MARK
So cool... :-)
I consider it is a bug of ICU because the U+FEFF is not in category
*Zs* as
ICU spec described. And I purposed to report that to ICU team.
Should I handle the U+2007 by ourselves to follow RI or just document
this
problem in testcase?
IMO, it's natural to follow RI, and the challenge is to fix it
gracefully with ICU implementation.
--
Robert Hu
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Upgrade java.lang.Math java.lang.StrictMath
Tony Wu 写道: Great news! go ahead :) On 9/11/06, Spark Shen <[EMAIL PROTECTED]> wrote: Hi All: There are some newly added methods of class java.lang.Math/java.lang.StrictMath in JDK 1.5(compared with JDK 1.4), but not implemented in Harmony. They are * *method* java.lang.Math.expm1(double): missing in harmony * *method* java.lang.Math.hypot(double, double): missing in harmony * *method* java.lang.Math.log1p(double): missing in harmony * *method* java.lang.Math.signum(double): missing in harmony * *method* java.lang.Math.signum(float): missing in harmony * *method* java.lang.Math.ulp(double): missing in harmony * *method* java.lang.Math.ulp(float): missing in harmony * *method* java.lang.StrictMath.expm1(double): missing in harmony * *method* java.lang.StrictMath.hypot(double, double): missing in harmony * *method* java.lang.StrictMath.log10(double): missing in harmony * *method* java.lang.StrictMath.log1p(double): missing in harmony * *method* java.lang.StrictMath.signum(double): missing in harmony * *method* java.lang.StrictMath.signum(float): missing in harmony * *method* java.lang.StrictMath.ulp(double): missing in harmony * *method* java.lang.StrictMath.ulp(float): missing in harmony I'd like to implement them if no one objects. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Great! And I just notice that you have already put up HARMONY-1415, HARMONY-1399, HARMONY-1388 about these two classes. They look good. :-) -- Robert Hu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni]upgrade java.lang.Character to 5.0
Tony Wu 写道: Hi all, I have looked through the java.lang.Character and found there were several methods missing in Harmony. I'll try to implement these methods if no one objects :) All of these methods are coming with Supplementary Character Support of Tiger. That is, we should handle the character whose code point is after U+ in our code. After doing some research, I found there're two ways to achieve: 1.Maintain a HashMap contains the information of supplementary character and retrieve from it when these methods were invoked. 2.Delegate these methods to ICU4J, which provides extensions to the java.lang.Character class. What's your opinion? Any suggestion are welcome :) This task is to update current implementation of java.lang.Character, about some new feature of J2SE 5.0, it's important to reduce the risk of changing such a core class. The "HashMap" method may introduce more complexity and more maintenance effort into Harmony development, so I think delegating to ICU4J is the better choice. The only concern is that: does the ICU4J we currently using meet our need perfectly? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Add me in
Please
