Re: [testing] harmonytest.org new features
Great Job. ;-) Anton Luht wrote: Hello, Yesterday I've deployed a new version to harmonytest.org New features include: - packages/suites/tests tree-like navigation (as in local JUnit html results).Tree navigation populated to old results, too. - the first page only includes 50 latest test runs, link to archive search added (includes search by uploader's name - request by Tony Wu) - filter diff results by test name (request by Alexei Fedotov) - detection of crashes - sometimes when suite crashes, there is an empty TEST-suite-name.xml file in the run results. If such file is found, all tests from this suite (detected from previous runs) are marked as crashed in this run. Bugs fixed: - duplicates in the results (if any) are merged (bug report by Tony Wu - test count on the site was bigger than real one) - there was a problem in uploading large files - ~ 5Mb - the results were not imported - playing with the configuration solved this problem - at least my test 11Mb file that broke the upload now uploads correctly. Please report bugs and send feature requests. -- Richard Liang China Software Development Lab, IBM
Re: Harmony passes all tests of Maven 2.0.4
Cool ;-) Leo Li wrote: Hi, all: Harmony classlib at revision 473150 passes all tests of Maven 2.0.4 on windows xp, redhat enterprise 4, unbuntu 6.0.6 and suse 10. As for drlvm, it passes on windows xp but fails on redhat linux enterprise 4. If somebody can reproduce it, I will report it as a application-oriented bug to jira. For detailed information, pls refer to http://wiki.apache.org/harmony/Apache_Maven. -- Richard Liang China Software Development Lab, IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Tim Ellison wrote: Richard Liang wrote: Tim Ellison wrote: Richard Liang wrote: On 11/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. Yes, I just run testNG successfully by appending suncompat.jar and luni-kernel-stubs.jar to bootclasspath ;-) Why do you need to put the stubs on the bootclasspath? and there is a sun.misc.Unsafe in the DRLVM kernel.jar so I expect you are using that. Sorry ;-) I'm using IBM VME which does not include org.apache.harmony.kernel.vm.Objects and org.apache.harmony.kernel.vm.Threads. I will try it with DRLVM. I'm still confused. If you are using stubs that do not actually implement Objects and Threads do you mean that we need Unsafe for TestNG but it doesn't actually use it? I feel that I'm missing something here. Maybe it's true that Unsafe is not actually used because I only tried the simplest test scenario which does not use parallel running ;-) Regards, Tim -- Richard Liang China Software Development Lab, IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Richard Liang wrote: Tim Ellison wrote: Richard Liang wrote: Tim Ellison wrote: Richard Liang wrote: On 11/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. Yes, I just run testNG successfully by appending suncompat.jar and luni-kernel-stubs.jar to bootclasspath ;-) Why do you need to put the stubs on the bootclasspath? and there is a sun.misc.Unsafe in the DRLVM kernel.jar so I expect you are using that. Sorry ;-) I'm using IBM VME which does not include org.apache.harmony.kernel.vm.Objects and org.apache.harmony.kernel.vm.Threads. I will try it with DRLVM. I'm still confused. If you are using stubs that do not actually implement Objects and Threads do you mean that we need Unsafe for TestNG but it doesn't actually use it? I feel that I'm missing something here. Maybe it's true that Unsafe is not actually used because I only tried the simplest test scenario which does not use parallel running ;-) And yes, when I try to run the tests with annotation @Test(threadPoolSize = 3, invocationCount = 10, timeOut = 1), the tests hang. I guess the reason is that I use the stubs of Objects and Threads. ;-) Best regards, Richard Regards, Tim -- Richard Liang China Software Development Lab, IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Richard Liang wrote: Richard Liang wrote: Tim Ellison wrote: Richard Liang wrote: Tim Ellison wrote: Richard Liang wrote: On 11/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. Yes, I just run testNG successfully by appending suncompat.jar and luni-kernel-stubs.jar to bootclasspath ;-) Why do you need to put the stubs on the bootclasspath? and there is a sun.misc.Unsafe in the DRLVM kernel.jar so I expect you are using that. Sorry ;-) I'm using IBM VME which does not include org.apache.harmony.kernel.vm.Objects and org.apache.harmony.kernel.vm.Threads. I will try it with DRLVM. I'm still confused. If you are using stubs that do not actually implement Objects and Threads do you mean that we need Unsafe for TestNG but it doesn't actually use it? I feel that I'm missing something here. Maybe it's true that Unsafe is not actually used because I only tried the simplest test scenario which does not use parallel running ;-) And yes, when I try to run the tests with annotation @Test(threadPoolSize = 3, invocationCount = 10, timeOut = 1), the tests hang. I guess the reason is that I use the stubs of Objects and Threads. ;-) Update: Same tests pass on RI and Harmony with DRLVM. Best regards, Richard Best regards, Richard Regards, Tim -- Richard Liang China Software Development Lab, IBM
Re: [general] Sun will take GPL License?
Leo Li wrote: Is it a good news for Harmony? It should be a good news if Sun chooses Apache License, Version 2.0. ;-) On 11/9/06, Andrew Zhang [EMAIL PROTECTED] wrote: http://www.crn.com/sections/breakingnews/breakingnews.jhtml;?articleId=193600331 -- Best regards, Andrew Zhang -- Richard Liang China Software Development Lab, IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Tim Ellison wrote: Richard Liang wrote: On 11/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. Yes, I just run testNG successfully by appending suncompat.jar and luni-kernel-stubs.jar to bootclasspath ;-) Why do you need to put the stubs on the bootclasspath? and there is a sun.misc.Unsafe in the DRLVM kernel.jar so I expect you are using that. Sorry ;-) I'm using IBM VME which does not include org.apache.harmony.kernel.vm.Objects and org.apache.harmony.kernel.vm.Threads. I will try it with DRLVM. We need to agree on the extensions to the luni kernel classes so that we can implement them in the IBM VME too (and then share the Unsafe in suncompat). Regards, Tim -- Richard Liang China Software Development Lab, IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Paulex Yang wrote: Richard Liang wrote: On 11/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 11/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... What's left for j.u.c? I lost track of that Saga, IIRC. I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. Yes, I just run testNG successfully by appending suncompat.jar and luni-kernel-stubs.jar to bootclasspath ;-) So you mean we can start the TestNG migration work at any time? No for current IBM VME; Maybe yes for drlvm (I will try it today ;-) ) -Nathan [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/ Ignore it, I'm all for TestNG...:) geir Paulex - being desperate -- Richard Liang China Software Development Lab, IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
On 11/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 11/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... What's left for j.u.c? I lost track of that Saga, IIRC. I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. Yes, I just run testNG successfully by appending suncompat.jar and luni-kernel-stubs.jar to bootclasspath ;-) -Nathan [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/ Ignore it, I'm all for TestNG...:) geir Paulex - being desperate -- Richard Liang China Development Lab, IBM
Re: [classlib][tests] Junit best practice
On 11/2/06, Tony Wu [EMAIL PROTECTED] wrote: hey guys, I found there're same problem for assertSame like assertEquals. should use assertNull, assertSame\s*\((.*,\s*null\s*|\s*null\s*,.*)\)\s*; should use assertFalse, assertSame\s*\((.*,\s*false\s*|\s*false\s*,.*)\)\s*; should use assertTrue, assertSame\s*\((.*,\s*true\s*|\s*true\s*,.*)\)\s*; last argument should not be a constant, assertSame\s*\(.*,\s*([^]*|'[^']'|[+-]?\d+[0-9a-fA-FLlPp]*|[A-Z_]*)\s*\)\s*; I'll update my checklist if no one object. Please go for it ;-) On 10/25/06, Mark Hindess [EMAIL PROTECTED] wrote: Earlier in the year we discussed junit best practice. For example, making sure assertEquals calls have the expected and actual arguments in the correct order to avoid getting confusing failure messages. Robert posted a script a week or so ago, to look for some of junit issues but it didn't handle asserts that spanned multiple lines so, unfortunately, it was missing the majority of them. I had a script that I'd thrown together one evening that would handle multi-line asserts but annoyingly (because it read the whole file at once) couldn't report the line number of the potential issue as Robert's script did. Inspired by Robert's post, I looked at my script again. I've now fixed it to report line numbers, added a little bit of documentation and attached it to a JIRA: https://issues.apache.org/jira/browse/HARMONY-1960 It finds quite a lot of potential problems (I've appended a summary of the findings below). (There will be a few false positives but hopefully not too many.) It would be nice to fix these issues - I fixed several hundred while testing the script - but more importantly we should make sure we avoid adding any new issues. Improvements to the script would be most welcome. Regards, Mark. Types of issue identified 4949 should possibly use assertEquals 815 actual may be a constant 437 consider using separate asserts for each '' component 330 exception may be left to junit 135 actual *may* be a constant 48 should be fail (always false) 40 should be fail (always true) 20 expected is null - should use assertNull 12 consider using separate asserts for each '||' component 8 expected is false - should use assertFalse 7 expected is true - should use assertTrue 1 should use assertNotNull Number of Issues by module 1907 luni 1440 swing 699 math 611 security 335 text 322 awt 222 sound 186 nio 178 jndi 123 archive 118 auth 117 crypto 116 logging 91 nio_char 87 print 74 regex 68 concurrent 45 beans 41 x-net 21 sql 1 rmi -- Tony Wu China Software Development Lab, IBM -- Richard Liang China Development Lab, IBM
Re: [classlib][tests] Junit best practice
Awesome. I just plan to review our junit tests, now it seems your tool has done what I want ;-) I highly recommend we read this article JUnit best practices[1] in javaworld. [1] http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html On 10/25/06, Mark Hindess [EMAIL PROTECTED] wrote: Earlier in the year we discussed junit best practice. For example, making sure assertEquals calls have the expected and actual arguments in the correct order to avoid getting confusing failure messages. Robert posted a script a week or so ago, to look for some of junit issues but it didn't handle asserts that spanned multiple lines so, unfortunately, it was missing the majority of them. I had a script that I'd thrown together one evening that would handle multi-line asserts but annoyingly (because it read the whole file at once) couldn't report the line number of the potential issue as Robert's script did. Inspired by Robert's post, I looked at my script again. I've now fixed it to report line numbers, added a little bit of documentation and attached it to a JIRA: https://issues.apache.org/jira/browse/HARMONY-1960 It finds quite a lot of potential problems (I've appended a summary of the findings below). (There will be a few false positives but hopefully not too many.) It would be nice to fix these issues - I fixed several hundred while testing the script - but more importantly we should make sure we avoid adding any new issues. Improvements to the script would be most welcome. Regards, Mark. Types of issue identified 4949 should possibly use assertEquals 815 actual may be a constant 437 consider using separate asserts for each '' component 330 exception may be left to junit 135 actual *may* be a constant 48 should be fail (always false) 40 should be fail (always true) 20 expected is null - should use assertNull 12 consider using separate asserts for each '||' component 8 expected is false - should use assertFalse 7 expected is true - should use assertTrue 1 should use assertNotNull Number of Issues by module 1907 luni 1440 swing 699 math 611 security 335 text 322 awt 222 sound 186 nio 178 jndi 123 archive 118 auth 117 crypto 116 logging 91 nio_char 87 print 74 regex 68 concurrent 45 beans 41 x-net 21 sql 1 rmi -- Richard Liang China Development Lab, IBM
Re: [announcement] Apache Board approved Apache Harmony as a Top Level Project of the ASF
Congratulations and we need to hold a celebration. ;-) On 10/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I am happy to report that the Apache Board was willing to consider our proposal and voted to accept it at today's board meeting. As stated in the Incubation vote, this is a necessary condition for graduation from the Incubator. Therefore, upon a successful outcome of the Incubator PMC vote, we are Apache Harmony, project of the Apache Software Foundation! Congratulations to everyone! When the vote is complete, we'll get to work on the transition activities, but until then, just give yourself a well-deserved pat on the back. Thanks all! geir -- Richard Liang China Development Lab, IBM
Re: [general] Announcing newest members of the Harmony PPMC
Congratulations! ;-) On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As progress towards our goal of having all committers on the PPMC, the Harmony PPMC is proud to announce it's newest members : Nathan Beyer Paulex Yang Weldon Washburn Please join us in congratulating them (and then tell them to get back to work...) :) The Harmony PPMC -- Richard Liang China Development Lab, IBM
Re: [vote] Graduate Apache Harmony podling from the Incubator
+ 1. ;-) Best regards, Richard On 10/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of when a community gets organized enough to vote itself out of the Incubator, it's appropriate. So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it hosted by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Development Lab, IBM
Re: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
On 10/17/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Richard, I've filed JIRA issue [1] for this problem. To my mind, we should just remove these locale dependent assertions. On the other hand there will be only a few tests left after then. Any other suggestions? If the behavior is depended on the (default) locale setting of java, we could do like this: Locale defaultLocale = Locale.getDefault(); Locale.setDefault(Locale.US); test.. Locale.setDefault(defaultLocale); But it seems that the behavior is depended on the locale setting of OS, this solution does not work. ;-) I agree we remove the locale dependent assertions temporarily. Best regards, Richard Regards, Alexey. P.S. See also related issue [2]: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:. [1] https://issues.apache.org/jira/browse/HARMONY-1893 [2] https://issues.apache.org/jira/browse/HARMONY-1892 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- Richard Liang China 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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][swing] Non-bug difference HARMONY-1745?
On 10/13/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hello, Can HARMONY-1745 be treated as non-bug difference? In short, in Harmony implementation method j.s.t.CompositeView.getView(int n) throws ArrayIndexOutOfBoundsException unless the parameter n is in the range [0, getViewCount() - 1]. Yet the RI throws the same exception in some cases, and it doesn't throw any exception and silently returns null in other cases where n is outside the range mentioned above. It seems the RI always accepts getViewCount() as valid parameter value. Shall we bother to fix it or can we leave the code as is? IMHO, it's a bug of RI. We could leave the code as it and change the components of Harmony-1745 to Non-bug differences from RI. Best regards, Richard. Thank you in advance for your comments, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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]
[classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- Richard Liang China 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: [testing] test suite layout, testNG, and more
On 10/11/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/9/06, Richard Liang [EMAIL PROTECTED] wrote: On 10/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: What is the status of our discussions about new test suite layout? Long ago we decided not to move existing tests until we finish with that discussion but the discussion seems to be either dead or in coma It's not dead ;-) We are waiting for the completion of j.u.concurrent so that we could run a pilot and continue our discussion. Looking forward to ... btw, Harmony may also benifit from failure and rerun feature of TestNG. I believe developers will like it! Sure ;-) Does it make sense to continue putting the tests in order (according to the old model) and relayout them as soon as we finish the discussion? Yes, it does make sense. Before we draw any new conclusion about TestNG, I suggest we follow our existing testing conventions/guidelines. Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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] -- Best regards, Andrew Zhang -- Richard Liang China 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: [General]Do we need an instruction of trying HDK on applications?
On 10/11/06, Tony Wu [EMAIL PROTECTED] wrote: Hi all, I have not found a guideline or instruction for trying hdk on applications. And I think something like how to try harmony on applications will do some help for those who have interest in this job. These days I'm struggling on running Apache Ant on Harmony and get some experience. Let me post these points as a start :) Please correct me if I am wrong. Download the application code, record its revision.(If a stable version is preferred here?) Verify latest hdk via, 1. If there are tests of the application, run the tests on RI and Harmony and record the difference. 2. If there are examples supplied, try to get them working on harmony to see if there is unexpected behavior. 3. Do some simple trial like real customer following the application's installation/user-guide. Post what and how you did on harmony wiki, http://wiki.apache.org/harmony/ClassLibrary Dive into the result to find if it is a bug of Harmony. Raise JIRA or post on mailing list if necessary. something needs attention, 1.Make sure you are running right JDK. 2.Record any special settingssteps on harmony wiki. Suggestions? Comments? Additions? IMHO, it should be very helpful to users. ;-) -- Tony Wu 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] -- Richard Liang China 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] [tests] Can anyone explain what these are for?
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
I've seen a few and I've deleted any that I've come across. I would
say feel free to delete them too. I've also been deleting empty setup
and teardown methods too.
Please do not simply delete them. Maybe that means we are lack of the
test for some methods, for example getInetAddress.
-Nathan
On 10/10/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
These could be a result of copy/paste tests creation.
And I'm curious why it was written for the first time. :)
SY, Alexey
2006/10/10, Mark Hindess [EMAIL PROTECTED]:
I've come across a couple of tests with things like:
public void test_getInetAddress() {
assertTrue(Used to test, true);
}
Can anyone explain why we have these?
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China 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] [tests] Can anyone explain what these are for?
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Perhaps, but there are much better ways of determining that. From just
reading the test code to code coverage tools.
From my analysis, these were part of the large test contribution and
indicated that there wasn't an explicit test for that method. In most
cases, there were tests for these methods, either in other classes or
in other methods of the class.
Nathan, I agree ;-)
-Nathan
On 10/10/06, Richard Liang [EMAIL PROTECTED] wrote:
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
I've seen a few and I've deleted any that I've come across. I would
say feel free to delete them too. I've also been deleting empty setup
and teardown methods too.
Please do not simply delete them. Maybe that means we are lack of the
test for some methods, for example getInetAddress.
-Nathan
On 10/10/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
These could be a result of copy/paste tests creation.
And I'm curious why it was written for the first time. :)
SY, Alexey
2006/10/10, Mark Hindess [EMAIL PROTECTED]:
I've come across a couple of tests with things like:
public void test_getInetAddress() {
assertTrue(Used to test, true);
}
Can anyone explain why we have these?
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China 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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China 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: [testing] test suite layout, testNG, and more
On 10/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: What is the status of our discussions about new test suite layout? Long ago we decided not to move existing tests until we finish with that discussion but the discussion seems to be either dead or in coma It's not dead ;-) We are waiting for the completion of j.u.concurrent so that we could run a pilot and continue our discussion. Does it make sense to continue putting the tests in order (according to the old model) and relayout them as soon as we finish the discussion? Yes, it does make sense. Before we draw any new conclusion about TestNG, I suggest we follow our existing testing conventions/guidelines. Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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]
Fwd: [icu-support] ICU4J ICU4JNI 3.6 Release
Hello, If there is no objection, I will try to upgrade our nio charset provider to icu4jni 3.6. Best regards, Richard -- Forwarded message -- From: Ram Viswanadha [EMAIL PROTECTED] Date: Sep 30, 2006 8:22 AM Subject: [icu-support] ICU4J ICU4JNI 3.6 Release To: [EMAIL PROTECTED], [EMAIL PROTECTED], ICU support mailing list [EMAIL PROTECTED] Dear Friends of ICU, We are pleased to announce the release of ICU4J and ICU4JNI 3.6. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.6.html API references of ICU4J can be found at http://icu.sourceforge.net/apiref/icu4j/ API references can ICU4JNI be found at http://icu.sourceforge.net/apiref/icu4jni/ -- Best Regards, Ram Viswanadha ICU - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ icu-support mailing list - [EMAIL PROTECTED] To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-support -- Richard Liang China 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][nio] How to fix read-only problem? (Re: [classlib][io][nio] Sync issue of java.io.FileOutputStream and java.nio.channels.FileChannel)
On 10/3/06, Andrew Zhang [EMAIL PROTECTED] wrote:
There are two ways to fix this problem:
1. Add a read-only flag in FileDescriptor. The default value is false. Set
the flag to true in FileInputStream and RandomeAccessFile(r).
2. Determine the fd in native code whether the fd is read-only.
Solution 1 judges the fd in java code, but has to remove native
from FileDescriptor#sync() signature. While solution 2 seems nature, and
solves the problem thoroughly, but requires more codes. If we adopt solution
2, we should add a new portable native mehtod like isReadOnly(int fd). Where
should we put the method? in port? or OSFileSystemWin32/Linux? Any
suggestions and comments?
Andrew,
I prefer to solution 2. IMHO, we may put the method in portlib if necessary.
Best regards,
Richard
Thanks!
On 9/19/06, Andrew Zhang [EMAIL PROTECTED] wrote:
I just found another bug of sync. Harmony throws SyncFailedException when
fd is read-only while RI returns silently. Spec doesn't explictly describe
the behaviour in such case[1]. But, it seems intended behaviour of RI,
because it requires additional check before invoke os sync. Following test
reproduces the bug:
public void testSyncReadOnly() throws Exception {
String TESTFILE = tempFile;
try {
FileOutputStream fos = new FileOutputStream(TESTFILE);
fos.write(something.getBytes());
fos.close();
RandomAccessFile raf = new RandomAccessFile(TESTFILE, rw);
raf.getFD().sync();
raf.close();
FileInputStream fis = new FileInputStream(TESTFILE);
fis.getFD().sync();
fis.close();
} finally {
new File(TESTFILE).delete();
}
}
I'll file a JIRA to record this bug soon!
[1] SyncFailedException - Thrown when the buffers cannot be flushed, or
because the system cannot guarantee that all the buffers have been
synchronized with physical media.
On 9/19/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello,
One Apache Derby test[1] fails on Harmony. It seems that RI always
sync the FileOutputStream and FileChannel after each write, which
is
different from Harmony. But there is no explicit description in Java
Spec. Shall we follow RI? Thanks a lot.
The following test cases could demonstrate this issue.
public void testFile() {
File derbyLog = new File(d:\\, derby1.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
fos.write(0x41);
assertEquals(1, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
public void testFileChannel() {
File derbyLog = new File(d:\\, derby2.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
FileChannel fc = fos.getChannel();
fc.write (ByteBuffer.wrap(new byte[]{0x41, 0x42}));
assertEquals(2, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
Interesting. I think we'd better follow RI although it's
implementation
dependent. Otherwise, it breaks existing application.
To make test more interesting, I wrote a similar test:
public void testFile() throws Exception {
File derbyLog = File.createTempFile(test, log);
derbyLog.deleteOnExit();
RandomAccessFile fos = new RandomAccessFile(derbyLog, rws);
for (int i = 0; i 1000; i++) {
fos.write(0x41);
assertEquals(1 + i, derbyLog.length());
}
}
Run it and you'll be surprised. :-)
Wow! It tooks RI 0.381 seconds, while 21.761 seconds for Harmony. We
shall improve our performance!
Let's have a more further study about this issue.
[1]
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/logStream.java?view=co
--
Richard Liang
China 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]
--
Andrew Zhang
China Software Development Lab, IBM
--
Richard Liang
China 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]
--
Andrew Zhang
China Software Development Lab, IBM
--
Best regards,
Andrew
Re: [classlib][test] fail statements omitted in many exception catching test cases
I have raised some JIRAs for SQL. Could any one have a look at them?
Thanks a lot.
http://issues.apache.org/jira/browse/HARMONY-1616
http://issues.apache.org/jira/browse/HARMONY-1619
http://issues.apache.org/jira/browse/HARMONY-1642
http://issues.apache.org/jira/browse/HARMONY-1643
Best regards,
Richard
On 9/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Great job, Robert. ;-)
I will have a look at sql.
On 9/28/06, Rui Hu [EMAIL PROTECTED] wrote:
Great Mark!
I've merged your code into my script. The script can be downloaded at [1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
On 9/27/06, Mark Hindess [EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly stricter
on matching context around 'catch'/'fail', by handling comments slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java +208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu [EMAIL PROTECTED] wrote:
--090601000506020908060004
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=GB2312
Hi All,
In our unit test of classlib, there are huge number of test cases about
excep
tion 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 Har
mony 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 r
450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of
above s
tyle.
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\FileIn
putStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOu
tputStreamTest.java:35
more..
*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? Pl
s. share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
--090601000506020908060004
Content-Type: text/plain;
name=result.txt
Content-Disposition: inline;
filename=result.txt
Content-Transfer-Encoding: quoted-printable
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF=
ileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
aterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
aterTest.java
:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10=
99\1105\1106\1113\1114\1120
Re: [classlib][test] fail statements omitted in many exception catching test cases
\BasicDesktopIconUITest.java:120 .\swing\src\test\api\java\common\javax\swing\plaf\basic\BasicTextUITest.java:186\206\259\285\341\346 .\swing\src\test\api\java\common\javax\swing\RepaintManagerTest.java:631 .\swing\src\test\api\java\common\javax\swing\SwingUtilitiesTest.java:1586\1587\1588 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_AbstractElementTest.java:183 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_AbstractElement_MASNoLockTest.java:70\79\88\97\106\115\124 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_BranchElementTest.java:153 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_ContentTest.java:105 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_FilterTest.java:195\231\238\273\280\287\294 .\swing\src\test\api\java\common\javax\swing\text\BoxView_WithChildrenTest.java:403 .\swing\src\test\api\java\common\javax\swing\text\CompositeView_NextNSVisPosTest.java:143 .\swing\src\test\api\java\common\javax\swing\text\DefaultCaretTest.java:585 .\swing\src\test\api\java\common\javax\swing\text\DefaultEditorKitRTest.java:163 .\swing\src\test\api\java\common\javax\swing\text\FlowView_FlowStrategyTest.java:330\331\345\346 .\swing\src\test\api\java\common\javax\swing\text\GapContent_GapVectorTest.java:148 .\swing\src\test\api\java\common\javax\swing\text\JTextComponentTest.java:288\463\472\922\923 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent_AccessibleJTextComponentTest.java:265\274\285\297\312\320\509\510 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent_AccessibleJTextComponent_variousTextTest.java:69\74 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent_IMLocationTest.java:159 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent_MultithreadedTest.java:160 .\swing\src\test\api\java\common\javax\swing\text\PasswordViewTest.java:161 .\swing\src\test\api\java\common\javax\swing\text\StringContentTest.java:60 .\swing\src\test\api\java\common\javax\swing\text\UtilitiesTest.java:655\721\737\773\782\863\936\951\989\1004 .\swing\src\test\api\java\common\javax\swing\text\ViewTest.java:481 .\swing\src\test\api\java\common\javax\swing\text\View_ChangesTest.java:1043 .\swing\src\test\api\java\common\javax\swing\Timer_MultithreadedTest.java:57 .\swing\src\test\api\java\common\javax\swing\UIDefaultsTest.java:215 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\AttributeListTest.java:131 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\ContentModelTest.java:141\148\155\162\169\176\183\189\195\201\212\217\222\228\235\241\247\254 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\DTDTest.java:114\119\124 .\text\src\test\java\org\apache\harmony\text\tests\java\text\CollatorTest.java:113 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DataFormatFieldTest.java:217 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DecimalFormatSymbolsTest.java:421 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DecimalFormatTest.java:1515 .\text\src\test\java\org\apache\harmony\text\tests\java\text\MessageFormatTest.java:147 .\text\src\test\java\org\apache\harmony\text\tests\java\text\RuleBasedCollatorTest.java:263\275 .\x-net\src\test\api\java\org\apache\harmony\xnet\tests\javax\net\ssl\SSLEngineTest.java:64 .\x-net\src\test\api\java\org\apache\harmony\xnet\tests\javax\net\ssl\SSLSocketTest.java:44\89\108 .\x-net\src\test\impl\java.injected\javax\net\ServerSocketFactoryTest.java:64\69\74 .\x-net\src\test\impl\java.injected\javax\net\SocketFactoryTest.java:64\69\74\79 .\x-net\src\test\impl\java.injected\javax\net\ssl\SSLServerSocketFactoryTest.java:50 .\x-net\src\test\impl\java.injected\javax\net\ssl\SSLSocketFactoryTest.java:50 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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][math]three tests fail, anyone else see this?
On 9/27/06, Tim Ellison [EMAIL PROTECTED] wrote:
Let me take a look -- I applied that patch.
It seems that Paulex had fixed this issue. ;-)
Best regards,
Richard
Regards,
Tim
Stepan Mishura wrote:
Yes, is see failures. I guess that a cause may be math module
internalization.
Thanks,
Stepan.
On 9/27/06, Paulex Yang wrote:
Anyone else see these test errors of BigDecimalConstructorsTest?
testConstrDoubleNaNFailureImproper exception message
expected:...e... but was:...y...
testConstrDoublePosInfinityFailureImproper exception message
expected:...e... but was:...y...
testConstrDoubleNegInfinityFailureImproper exception message
expected:...e... but was:...y...
I believe it is caused by the patch of i18n message properties, it
returns Infinity or NaN, I've updated it at revision r450333, but is
it necessary to verify exception message so strictly like this?
code
try {
new BigDecimal(a);
fail(NumberFormatException has not been caught);
} catch (NumberFormatException e) {
assertEquals(Improper exception message, Infinite or NaN,
e.getMessage());
}
/code
--
Paulex Yang
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]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China 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][test] fail statements omitted in many exception catching test cases
\common\javax\swing\text\DefaultEditorKitRTest.jav= a:163 .\swing\src\test\api\java\common\javax\swing\text\FlowView=5FFlowStrategyTe= st.java:330\331\345\346 .\swing\src\test\api\java\common\javax\swing\text\GapContent=5FGapVectorTes= t.java:148 .\swing\src\test\api\java\common\javax\swing\text\JTextComponentTest.java:2= 88\463\472\922\923 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent=5FAccessib= leJTextComponentTest.java:265\274\285\297\312\320\509\510 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent=5FAccessib= leJTextComponent=5FvariousTextTest.java:69\74 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent=5FIMLocati= onTest.java:159 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent=5FMultithr= eadedTest.java:160 .\swing\src\test\api\java\common\javax\swing\text\PasswordViewTest.java:161 .\swing\src\test\api\java\common\javax\swing\text\StringContentTest.java:60 .\swing\src\test\api\java\common\javax\swing\text\UtilitiesTest.java:655\72= 1\737\773\782\863\936\951\989\1004 .\swing\src\test\api\java\common\javax\swing\text\ViewTest.java:481 .\swing\src\test\api\java\common\javax\swing\text\View= 5FChangesTest.java:1= 043 .\swing\src\test\api\java\common\javax\swing\Timer= 5FMultithreadedTest.java= :57 .\swing\src\test\api\java\common\javax\swing\UIDefaultsTest.java:215 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\AttributeLi= stTest.java:131 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\ContentMode= lTest.java :141\148\155\162\169\176\183\189\195\201\212\217\222\228\235\241\= 247\254 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\DTDTest.jav= a:114\119\124 .\text\src\test\java\org\apache\harmony\text\tests\java\text\CollatorTest.j= ava:113 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DataFormatFiel= dTest.java:217 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DecimalFormatS= ymbolsTest.java:421 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DecimalFormatT= est.java:1515 .\text\src\test\java\org\apache\harmony\text\tests\java\text\MessageFormatT= est.java:147 .\text\src\test\java\org\apache\harmony\text\tests\java\text\RuleBasedColla= torTest.java:263\275 .\x-net\src\test\api\java\org\apache\harmony\xnet\tests\javax\net\ssl\SSLEn= gineTest.java:64 .\x-net\src\test\api\java\org\apache\harmony\xnet\tests\javax\net\ssl\SSLSo= cketTest.java:44\89\108 .\x-net\src\test\impl\java.injected\javax\net\ServerSocketFactoryTest.java:= 64\69\74 .\x-net\src\test\impl\java.injected\javax\net\SocketFactoryTest.java:64\69\= 74\79 .\x-net\src\test\impl\java.injected\javax\net\ssl\SSLServerSocketFactoryTes= t.java:50 .\x-net\src\test\impl\java.injected\javax\net\ssl\SSLSocketFactoryTest.java= :50= --090601000506020908060004 Content-Type: text/plain; charset=us-ascii - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --090601000506020908060004-- -- Robert Hu China Software Development Lab, IBM -- Richard Liang China 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][awt] Non bug??? RI AffineTransform.transform(...) throws ArrayIndexOutOfBoundsException while Harmony doesn't
On 9/27/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Hi all
RI implementation of AffineTransform of transform(float[], int,
float[], int, int) and transform(double[], int, double[], int, int)
methods throws ArrayIndexOutOfBoundsException if offset is out of
bounds and number of points to transform is zero. Harmony doesn't
throw any exception. Spec doesn't say about any exceptions.
RI use System.arraycopy(...) (see track trace) which throws this
exception. But Harmony doesn't use System.arraycopy(...) so we have
difference in behavior.
I see two possibilities
1. Stay as non-bug. If number of points is zero then logically we have
to do nothing w/o exceptions.
2. Follow RI. In this case we have to add checks like this
if (srcOff src.length || dstOff dst.length) {
throw new ArrayIndexOutOfBoundsException(...);
}
it looks a bit strange from my point of view.
I vote for non-bug.
Comments?
Hello Denis,
According to our Compatibility Guidelines[1], I suggest we follow RI
for this issue though you may feel uncomfortable about the additional
code ;-)
[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Best regards,
Richard
2006/9/27, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] RI AffineTransform.transform(...) throws
ArrayIndexOutOfBoundsException while Harmony doesn't
-
Key: HARMONY-1606
URL: http://issues.apache.org/jira/browse/HARMONY-1606
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of AffineTransform of transform(float[], int, float[], int,
int) and transform(double[], int, double[], int, int) methods throws
ArrayIndexOutOfBoundsException if offsets are out of buffer bounds and number of
points to transform is zero. Harmony doesn't throw any exception. Spec doesn't say
about any exceptions.
As you see from stack trace RI call System.arraycopy(...) which throws
exception because of offset is really out of bounds. But Harmony implementation
doesn't use System.arraycopy(...) so we have difference in behavior.
=== Test.java ===
import java.awt.geom.AffineTransform;
public class Test {
static public void main(String[] args) {
AffineTransform t = new AffineTransform();
try {
t.transform(new float[] {}, 1, new float[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
try {
t.transform(new double[] {}, 1, new double[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
}
}
= RI ===
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2308)
at Test.main(Test.java:10)
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2421)
at Test.main(Test.java:15)
Harmony ===
nothing
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Denis M. Kishenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China 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][awt] Fonts with negative size.
Agree. We may follow Java 6.0 Spec.
Richard.
On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Guys, I found something in the Java 6.0 documentation.
If you look at the TextAttribute spec there is a note for the SIZE
field, attribute key for the font size:
Attribute key for the font size. Values are instances of *Number*. The
default value is 12pt.
This corresponds to the size parameter to the Font constructor.
Very large or small sizes will impact rendering performance, and the
rendering system might not render text at these sizes. *Negative sizes are
illegal and result in the default size*.
For this reason I suggest to use default size (12pt) if font has negative
size parameter. Any thoughts?
I believe negative-sized fonts support was erroneous in Java 5.0 and
in the earlier versions of Java.
Regards,
Ilya.
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It seems like returning negative metrics is somewhat logical. If the
font is rotated by -Pi then all offsets becomes negative, but their
absolute values are equal to the positive ones.
I'll try to give an example. E.g. if descent was, say, 10 and one
needed to offset 10 pt from the origin (baseline) to the bottom of the
black box then if -pi rotation is applied to the font, one need to
offset -10 pt from the baseline since black box is upside down.
Yes, RI failed to be consistent with this on heavyweight components as
it was noted in the evaluation. But is this bug still there in the RI?
And if RI is inconsistent with the drawing of negative-sized fonts it
is still consistent with the negative metrics, right?
IMHO, the ideal behavior in all situations would be the following:
If the font has negative size we assume that it has all the same
metrics as the positive font, but the metrics which has a direction
(like ascent, descent, etc.) are with the different sign. The font is
drawn as it was rotated by -pi angle.
Personaly my opinion is that this is a bug, not non-bug diff.
I'd suggest to choose between these options:
1. Fix metrics and rendering, close this issue.
2. Fix metrics, open a new jira for the rendering of the negative-sized
fonts.
3. Fix nothing, open a new jira or add an evaluation to this one
both for the rendering and for the metrics. This means that we want to
have them together.
For the rendering part, why not just add a transform if the size of
the font is negative?
On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It was evaluated as not a bug. But it is clear from its evaluation
that negative-sized fonts are treated as positive sized but rotated
around their origin, say with implicit transform. I'd suggest to
follow this behavior.
I agree, that the behavior of the negative-sized fonts on RI is looks
like
the behavior of positive ones with -Pi rotation. However, if we look at
the
font metrics, bounds - we can see negative values for height, width
values...I'm not sure they have any sence without additional
documentation
that we can't find in the spec.
Moreover bug evaluation says that RI handles negative-sized fonts for
components in different ways depending on the platform. And it's
behavior
unlike the drawing on the frame surface. What is to add - metrics for
all
these various cases are the same, it means that RI has erroneous
behavior in
some way.
I would suggest not to follow the RI and mark it as non-bug difference
as
the RI hasn't any clear documentation on this problem and it's
behavior erroneous and depends on the platform or component type.
Thanks,
Ilya.
On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there
is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative
size
can be
created on RI.
Unfortunately spec keep silence about fonts with negative
sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = +
localFont.getLineMetrics(,
new
FontRenderContext(null, false, false
Re: [classlib][awt] Fonts with negative size.
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(, new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = + localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks quite strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543,w=-5.46875
,h=-5.7495117]
Actually, I dont see any sence in negative height and width metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen, you can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to choose only
positive sized fonts. Also I've looked on the GDI LOGFONT structure
description in MSDN and I've seen there again that we deal with absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because the spec does not explicitly
describe the requirement of font size.
I suggest we follow RI.
Best regards,
Richard
Thanks,
Ilya.
--
--
Ilya Okomin
Intel Middleware Products Division
--
Richard Liang
China 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][logging] In applying the LogManager patch...
On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: ... as suggested by Nikolay, I did run the tests $ cd modules/logging $ ant test and it was endless stacktraces, both before and after I made the modification. How do I know if I broke anything? I'm going to go forward with the patch as I don't see any harm, since Logger.global is supposed to be set via getLogger(global) anyway, so subsequent settings shouldn't harm. I got the same stacktraces, and it said BUILD SUCCESSFUL in the end. ;-) After a quick looking through the test (SocketHandlerTest), I found that some tests try to verify some expected exception, in the mean while the exceptions are delegated to ErrorManager which reports the exception to System.err. Running the test on RI, we will also see some error messages (not stacktraces) I guess you broke nothing ;-) Best regards, Richard geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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][awt] Fonts with negative size.
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(, new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = +
localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks quite strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543,w=-5.46875
,h=-5.7495117]
Actually, I dont see any sence in negative height and width metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen, you can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to choose only
positive sized fonts. Also I've looked on the GDI LOGFONT structure
description in MSDN and I've seen there again that we deal with absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because the spec does not explicitly
describe the requirement of font size.
I suggest we follow RI.
Best regards,
Richard
Thanks,
Ilya.
--
--
Ilya Okomin
Intel Middleware Products Division
--
Richard Liang
China 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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China 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: [doc] Why do we have boxes drawn around source now?
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Is this new? We now have boxes drawn around the shaded box on a source document snippet... Maybe because we now have unified site.css (HARMONY-1384[1]) to make our pages more beautiful ;-) [1] http://issues.apache.org/jira/browse/HARMONY-1384 Best regards, Richard geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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: [doc] Why do we have boxes drawn around source now?
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Sep 21, 2006, at 10:06 PM, Richard Liang wrote:
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Is this new? We now have boxes drawn around the shaded box on a
source document snippet...
Maybe because we now have unified site.css (HARMONY-1384[1]) to make
our pages more beautiful ;-)
I know how they are getting there. I don't know why... they gotta
go...
Do you want to remove the section of site.css?
pre {
background: #F3F5F7;
border: thin solid;
border-color: #828DA6;
padding: 12pt;
font-size: 11.0pt;
font-family: Courier;
margin-right: 10pt;
margin-left: 25pt;
}
Best regards,
Richard
geir
[1] http://issues.apache.org/jira/browse/HARMONY-1384
Best regards,
Richard
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--
Richard Liang
China 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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China 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: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 19, 2006, at 2:13 AM, Richard Liang wrote: On 9/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? I dunno, but I don't think that would be a reason to stuff jetty.jar in svn. I agree that we should not put jetty into Harony svn. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/19/06, Richard Liang wrote: On 9/18/06, Geir Magnusson Jr. wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? I'd use it as 'support.jar' - so it is downloaded to 'depends', copied by the build to 'deploy/build/test' and added as external jar in Eclipse. Yes. It's reasonable. Let's have a try ;-) Andrew? Thanks, Stepan. 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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] -- Richard Liang China 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: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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][io][nio] Sync issue of java.io.FileOutputStream and java.nio.channels.FileChannel
On 9/19/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello,
One Apache Derby test[1] fails on Harmony. It seems that RI always
sync the FileOutputStream and FileChannel after each write, which is
different from Harmony. But there is no explicit description in Java
Spec. Shall we follow RI? Thanks a lot.
The following test cases could demonstrate this issue.
public void testFile() {
File derbyLog = new File(d:\\, derby1.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
fos.write(0x41);
assertEquals(1, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
public void testFileChannel() {
File derbyLog = new File(d:\\, derby2.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
FileChannel fc = fos.getChannel();
fc.write(ByteBuffer.wrap(new byte[]{0x41, 0x42}));
assertEquals(2, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
Richard, we're fooled by derbyLog.length(). :-) That's the root of evil!
Harmony uses FindFirstFile to get file attribute, which may not be latest
information of file. MSND points out In rare cases, file attribute
information on NTFS file systems may not be current at the time you call
this function. That's why the test failed against Harmony. If using
GetFileAttributeEx instead, the test passes against Harmony. :-) But I
don't think the test is theoretically stable, since the file is not opened
with sync flag. :-) We could use RandomAccessFile(file,rwd(s)) for
test. Let's file a JIRA and fix it!
Thank you very much, Andrew. I have raised a JIRA [1] for this issue.
[1] https://issues.apache.org/jira/browse/HARMONY-1497
[1]
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/logStream.java?view=co
--
Richard Liang
China 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]
--
Andrew Zhang
China Software Development Lab, IBM
--
Richard Liang
China 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]
[classlib][io][nio] Sync issue of java.io.FileOutputStream and java.nio.channels.FileChannel
Hello,
One Apache Derby test[1] fails on Harmony. It seems that RI always
sync the FileOutputStream and FileChannel after each write, which is
different from Harmony. But there is no explicit description in Java
Spec. Shall we follow RI? Thanks a lot.
The following test cases could demonstrate this issue.
public void testFile() {
File derbyLog = new File(d:\\, derby1.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
fos.write(0x41);
assertEquals(1, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
public void testFileChannel() {
File derbyLog = new File(d:\\, derby2.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
FileChannel fc = fos.getChannel();
fc.write(ByteBuffer.wrap(new byte[]{0x41, 0x42}));
assertEquals(2, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
[1]
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/logStream.java?view=co
--
Richard Liang
China 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: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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][io][nio] Sync issue of java.io.FileOutputStream and java.nio.channels.FileChannel
On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello,
One Apache Derby test[1] fails on Harmony. It seems that RI always
sync the FileOutputStream and FileChannel after each write, which is
different from Harmony. But there is no explicit description in Java
Spec. Shall we follow RI? Thanks a lot.
The following test cases could demonstrate this issue.
public void testFile() {
File derbyLog = new File(d:\\, derby1.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
fos.write(0x41);
assertEquals(1, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
public void testFileChannel() {
File derbyLog = new File(d:\\, derby2.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
FileChannel fc = fos.getChannel();
fc.write(ByteBuffer.wrap(new byte[]{0x41, 0x42}));
assertEquals(2, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
Interesting. I think we'd better follow RI although it's implementation
dependent. Otherwise, it breaks existing application.
To make test more interesting, I wrote a similar test:
public void testFile() throws Exception {
File derbyLog = File.createTempFile(test, log);
derbyLog.deleteOnExit();
RandomAccessFile fos = new RandomAccessFile(derbyLog, rws);
for (int i = 0; i 1000; i++) {
fos.write(0x41);
assertEquals(1 + i, derbyLog.length());
}
}
Run it and you'll be surprised. :-)
Wow! It tooks RI 0.381 seconds, while 21.761 seconds for Harmony. We
shall improve our performance!
Let's have a more further study about this issue.
[1]
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/logStream.java?view=co
--
Richard Liang
China 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]
--
Andrew Zhang
China Software Development Lab, IBM
--
Richard Liang
China 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
Hello,
I have raised a bug for icu[1], not sure whether it will be fixed in
icu4j 3.6. :-)
[1] http://bugs.icu-project.org/cgi-bin/icu-bugs/incoming?findid=5391
On 9/12/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello,
I will clarify this issue with ICU team. ;-)
Best regards,
Richard
Tony Wu wrote:
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').
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;noBreak 0020N;NON-BREAKING SPACE
2007;FIGURE SPACE;Zs;0;WS;noBreak 0020N;
202F;NARROW NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;
FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;N;BYTE ORDER MARK
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?
--
Richard Liang
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]
--
Richard Liang
China 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][TestNG] Use tweaked TestNG
On 9/13/06, Mark Hindess [EMAIL PROTECTED] wrote: On 12 September 2006 at 14:44, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Richard, If this tweaking doesn't affect visible TestNG user interface then I see nothing bad about converting the sample module. Especially in case if we have volunteers who cannot stand without it any longer :) Another question is, where should we keep this tweaked version? Is there any place from which it can be downloaded during the build or we should keep tweaked jar in svn or ... Either of the options you mention would break the as long as we do not re-distributed it requirement that Cedric placed on the tweaked version. The only sane option would be to distribute the tweaking mechanism via svn (or a jar). I think I'd prefer waiting 'til we can run TestNG without tweaking. Agree ;-) Hope we complete j.u.concurrent soon ;-) BTW, I'm still volunteering to convert beans. Excellent! -Mark. 2006/9/12, Richard Liang [EMAIL PROTECTED]: Hello, I have been discussing with the author of TestNG (Cedric) about Harmony using a tweaked TestNG which does not require java.util.concurrent. The feedback is we could use the tweaked TestNG as long as we do not re-distributed it. So now it's possible to deploy TestNG in Harmony. What do you think we take a simple module (prefs?) to run a pilot? Or let's waiting for the completion of j.u.concurrent. Thanks a lot. Best regards, -- Richard Liang China Development Lab, IBM -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Excellent ;-) Only a few comments. Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. 0. Explicitly address: what is the expected behavior, and what's the actual behavior of Harmony? Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. We could also suggest some requirements for patch: e.g., avoid using absolute path, provide a shell if necessary, 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more And make sure all tests pass ;-) 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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
Hello,
I will clarify this issue with ICU team. ;-)
Best regards,
Richard
Tony Wu wrote:
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').
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;noBreak 0020N;NON-BREAKING SPACE
2007;FIGURE SPACE;Zs;0;WS;noBreak 0020N;
202F;NARROW NO-BREAK SPACE;Zs;0;CS;noBreak 0020N;
FEFF;ZERO WIDTH NO-BREAK SPACE;Cf;0;BN;N;BYTE ORDER MARK
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?
--
Richard Liang
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]
[classlib][TestNG] Use tweaked TestNG
Hello, I have been discussing with the author of TestNG (Cedric) about Harmony using a tweaked TestNG which does not require java.util.concurrent. The feedback is we could use the tweaked TestNG as long as we do not re-distributed it. So now it's possible to deploy TestNG in Harmony. What do you think we take a simple module (prefs?) to run a pilot? Or let's waiting for the completion of j.u.concurrent. Thanks a lot. Best regards, -- Richard Liang China 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: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/12/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/11/06, Alexei Zakharov wrote: Hi all, One more note (seems it already was said sorry if I repeat): the test without any marks should be run in all configurations (i.e. we have 'default' group but declaration of this group may be missed). I'd like to point your attention on the previous discussion about default groups : http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] I am still for using os.any since it is more self-descriptive and the build script will be simpler with os.any. This is not a good argument for using os.any. Even more it may sound like we are going to choose wrong tool - why we have to add os.any to 99% of classlib tests? just because the harness can not do without it? Yes. And we have found a way to avoid os.any ;-) It will be nice to hear more arguments for using defaults because it seems the arguments that were gathered in that old thread hasn't been taken into account by participants of this thread. As I understand arguments in the old thread - TestNG makes us to use os.any annotation otherwise we have to do a lot of tricks to run tests, right? IMO a test annotation should be used as red flag for developer, for example * state.broken - hey, i'm broken fix me please * os.win - i'm valid only for Windows, don't try to run me on Linux So a test's annotation should point out that the test is a special one. But if most of tests will contain a similar block of annotations then nobody will looked at them. Does this make sense? Yes. It really makes sense. We do not want to involve developers in unnecessary effort. Thanks, Stepan. Thanks, 2006/9/5, Vladimir Ivanov [EMAIL PROTECTED]: One more note (seems it already was said sorry if I repeat): the test without any marks should be run in all configurations (i.e. we have 'default' group but declaration of this group may be missed). thanks, Vladimir On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: OK, let's return back to the usage model. If I understood it correctly, before the commit of any changes each developer run *all* tests (at least all which we have now) on all available to him platforms. In this context seems we don't need in any 'level' group (while 'stress' tests require reasonable time to pass). Seems, that platform group also can be deleted (at present time we have 10 platform-dependent tests and this amount should not increase dramatically so the platform-detection can be included to the each such test). Also cpu groups can be deleted (while we have not cpu-dependent test). At the end we need only state groups to support test exclusion on the 'one-element' level (while we have unresolved entries in the current exclude list). So, after small update of unit (aka integration, aka regression etc) tests and resolution of all entries in the exclude list we don't need any groups and pure JUnit covers all our needs :) On the other side, if we define some groups it will nice to define *all* reasonable groups at the begin of the process. thanks, Vladimir By the way, our regression tests are 'classic' regression tests that demonstrate some issues which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail- archives.apache.org/mod_mbox/incubator
Re: [classlib][TestNG] Use tweaked TestNG
On 9/12/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Richard, If this tweaking doesn't affect visible TestNG user interface then I see nothing bad about converting the sample module. Especially in case if we have volunteers who cannot stand without it any longer :) I only redirect the concurrency support from java.util.concurrent to backport-util-concurrent which is used by TestNG for java14. It should not influence the UI. I will try the Eclipse plugin. ;-) Another question is, where should we keep this tweaked version? Is there any place from which it can be downloaded during the build or we should keep tweaked jar in svn or ... Temporarily, we will keep it in Harmony SVN. BTW, I'm still volunteering to convert beans. Great Thanks a lot. Regards, 2006/9/12, Richard Liang [EMAIL PROTECTED]: Hello, I have been discussing with the author of TestNG (Cedric) about Harmony using a tweaked TestNG which does not require java.util.concurrent. The feedback is we could use the tweaked TestNG as long as we do not re-distributed it. So now it's possible to deploy TestNG in Harmony. What do you think we take a simple module (prefs?) to run a pilot? Or let's waiting for the completion of j.u.concurrent. Thanks a lot. Best regards, -- Richard Liang China Development Lab, IBM -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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][security] problem processing SHA signatures in JBoss installer manifest
After two-day struggling with JarFile, ObjectInputStream and
MessageDigest, in the end, I have identified the root cause. And now I
have two panda-eyes[1] ;-)
It seems a bug of
org.apache.harmony.security.provider.crypto.SHA1Impl. As I have no
idea about SHA1. Could any one have a look at this problem?
The following test case passes on RI, but fails on Harmony.
public void testUpdate() throws NoSuchAlgorithmException {
byte[] bytes = { 0x6e, 0x61, 0x6d, 0x65};
MessageDigest sha1 = MessageDigest.getInstance(SHA1);
byte[] digest1 = sha1.digest();
byte b = 0x04;
sha1.update(b);
for (int i = 0; i bytes.length; i++) {
sha1.update(bytes[i]);
}
byte[] digest2 = sha1.digest();
sha1.reset();
byte[] digest3 = sha1.digest();
assertTrue(MessageDigest.isEqual(digest1, digest3));
sha1.update(b);
sha1.update(bytes, 0, bytes.length);
byte[] digest4 = sha1.digest();
assertTrue(MessageDigest.isEqual(digest2, digest4));
}
[1]http://www.panda.org.cn/zhuye/bbe.jpg
Best regards,
Richard
On 9/11/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I was trying the latest snapshot with the JBoss installer (4.0.1) and
found a problem processing the SHA signatures int the jar manifest.
I've entered a JIRA - HARMONY-1412
I will have a look at it. ;-)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
--
Richard Liang
China 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: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/11/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
One more note (seems it already was said sorry if I repeat): the test
without any marks should be run in all configurations (i.e. we have
'default' group but declaration of this group may be missed).
I'd like to point your attention on the previous discussion about
default groups :
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
I am still for using os.any since it is more self-descriptive and
the build script will be simpler with os.any. It will be nice to
hear more arguments for using defaults because it seems the arguments
that were gathered in that old thread hasn't been taken into account
by participants of this thread.
I have not any strong objection about os.any. And actually I had
ever proposed to define the default group because we could not
include tests with annotation @Test which belong to no groups. Now it
isn't a problem as we already have a solution for them. To facilitate
writing test cases, we annotate the unit tests which are designed to
pass on all platforms (os + arch) with @Test.
If we use os.any and arch.any, then the default annotation would
be @Test(groups={os.any, arch.any})
Could any other give more comments? Thanks a lot.
Best regards,
Richard
Thanks,
2006/9/5, Vladimir Ivanov [EMAIL PROTECTED]:
One more note (seems it already was said sorry if I repeat): the test
without any marks should be run in all configurations (i.e. we have
'default' group but declaration of this group may be missed).
thanks, Vladimir
On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
OK, let's return back to the usage model.
If I understood it correctly, before the commit of any changes each
developer run *all* tests (at least all which we have now) on all available
to him platforms. In this context seems we don't need in any 'level' group
(while 'stress' tests require reasonable time to pass).
Seems, that platform group also can be deleted (at present time we have
10 platform-dependent tests and this amount should not increase
dramatically so the platform-detection can be included to the each such
test).
Also cpu groups can be deleted (while we have not cpu-dependent test).
At the end we need only state groups to support test exclusion on the
'one-element' level (while we have unresolved entries in the current exclude
list).
So, after small update of unit (aka integration, aka regression etc) tests
and resolution of all entries in the exclude list we don't need any groups
and pure JUnit covers all our needs :)
On the other side, if we define some groups it will nice to define *all*
reasonable groups at the begin of the process.
thanks, Vladimir
By the way, our regression tests are 'classic' regression tests that
demonstrate some issues which were not resolved by initial code. But it
provides less coverage than 'regression tests' + unit tests, of cause.
On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote:
On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote:
If you've got fast and slow tests, then have a group for fast and
slow
tests. Then you can choose to just run the fast tests, and any
automated build system can handle running the slow tests.
IMHO, fast or slow may not be the key point. The question is
whether we
have any requirements to run only the regression tests.
No, probably not the key point, but (a) groups don't have to be
mutually exclusive (so you can decorate it with whatever groups you
want)
I agree. For example, os.win and os.linux are not mutually exclusive.
Thanks a lot.
and (b) it might be useful for an automated build system to run
fast tests first, followed by slow (or non-fast) tests.
That makes sense through we have not clear requirement currently.
Mind you, I don't know what's going to happen with an automated
test'n'build
system; so it might not make sense to do it at this point.
Really? ;-) We could also discuss whether it's feasible to move to
TestNG. As you may know, there are already several threads about
TestNG JUnit. Here I just review the open questions one by one so
that we have sufficient preparation.
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
[2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
[3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
Best regards,
Richard
Alex.
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I was trying the latest snapshot with the JBoss installer (4.0.1) and found a problem processing the SHA signatures int the jar manifest. I've entered a JIRA - HARMONY-1412 I will have a look at it. ;-) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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][sql] Another confusing behavior: java.sql.Timestamp
Hello,
I have raised Harmony-1400[1] for this issue. Thanks a lot.
[1]http://issues.apache.org/jira/browse/HARMONY-1400
Best regards,
Richard.
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
1) What should it do?
When calculating nanos value, underflow may occur if the given time is
near Long.MIN_VALUE. In fact, I'm also not sure what it should do. Just
notice that RI handles the underflow situation in a special/confusing
way, while Harmony does not have any handling.
2) if it's just a single value, why not fix it and never have to deal
w/ it again? Is it an easy fix?
Yes, the fix is quite easy. Do you mean we shall follow RI?
Thanks a lot.
Richard.
geir
Anton Luht wrote:
Hello,
I don't think we should bother about single value which is very
unlikely to happpen in real data.
On 8/29/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
RI's java.sql.Timestamp(long time) behaves confusing when the
parameter time is in Long.MIN_VALUE. Shall we follow RI?
Output of the following sample is:
time: -9223372036854775808
time: 9223372036854775192
timestamp: 292278994-08-17 15:12:55.192
timestamp: 292278994-08-17 15:12:55.192
=
import java.sql.Timestamp;
public class TimeStampTest {
public static void main(String[] args) {
long time = Long.MIN_VALUE;
long time2 = 9223372036854775192l;
Timestamp timestamp = new Timestamp(time);
Timestamp timestamp2 = new Timestamp(time2);
System.out.println(time: + time);
System.out.println(time: + time2);
System.out.println(timestamp: + timestamp);
System.out.println(timestamp: + timestamp2);
}
}
--
Richard Liang
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
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]
--
Richard Liang
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
On 9/8/06, Robert Hu [EMAIL PROTECTED] wrote: 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? IMHO, the icu4j_3.4.4 which supports Unicode 4.1 will meet our requirement. Best regards, Richard - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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][TestNG] groups of Harmony test
On 9/6/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: On 9/6/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir Ivanov wrote: Do we really need in it? At present time tests were designed for win/unix only. I thought at least we have interest to port Harmony to these platforms[1]. [1] http://incubator.apache.org/harmony/roadmap.html#Porting%20Matrix Yes, but I don't sure that we will have unique java API tests for all of them. In any case, if we define groups set it should include names for all defined platforms. We proposed to use os+arch to define platform. Best regards, Richard thanks, Vladimir -- Paulex Yang 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] -- Richard Liang 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: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
On 9/7/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Would there be any objections to asking the automated builds (that send
messages to the commit list) to use either the latest Sun compiler (5.0_8)
or the Eclipse compiler?
Sun compiler (5.0_8) also has some unexpected behavior. See[1]
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200608.mbox/[EMAIL
PROTECTED]
Best regards,
Richard
There are a number of places that use ReferenceQueues and Reference, but
can't be generified because of a bug in the Sun compilers prior to 5.0_8. At
the end of this email is an example of code that causes a compiler error in
previous releases. This issue does not affect the Eclipse compiler. I've run
a full rebuild as of revision 440796 and everything compiles fine with both
the Eclipse compiler and Sun 5.0_8 compiler.
-Nathan
private static final ReferenceQueueObject cacheQueue = new
ReferenceQueueObject();
private static final class CacheEntry extends WeakReferenceObject {
String key;
CacheEntry(Object jar, String key, ReferenceQueueObject queue) {
super(jar, queue);
this.key = key;
}
}
// ... code using the queue
CacheEntry entry;
// This cast fails on Sun 5.0_7 and prior compilers
while ((entry = (CacheEntry)cacheQueue.poll()) != null) {
jarCache.remove(entry.key);
}
// . more code
--
Richard Liang
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: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: On 9/5/06, Andrew Zhang [EMAIL PROTECTED] wrote: ... How to define platform? Get platform information in test code? Yes. It is just one line of code. For example, from Support_Exec.java class: boolean onUnix = File.separatorChar == '/'; Yes, it does work sometimes, but ... How to differentiate AIX, solaris, linux, unix, windows and etc... Do we really need in it? At present time tests were designed for win/unix only. Yes. In the future, Harmony will support more platforms. We may have more platform-dependent test cases. In any case, I don't against the groups but if we define 'general' groups set it should include 'regression' group too. If there's a public API or can be retrieved from system property, it may work. The public API does not specify exact names for platforms (java is platform independent :) ) so these ways are equals (but for impl tests it will works fine). thanks, Vladimir thanks, Vladimir In this context seems we don't need in any 'level' group (while 'stress' tests require reasonable time to pass). Seems, that platform group also can be deleted (at present time we have 10 platform-dependent tests and this amount should not increase dramatically so the platform-detection can be included to the each such test). Also cpu groups can be deleted (while we have not cpu-dependent test). At the end we need only state groups to support test exclusion on the 'one-element' level (while we have unresolved entries in the current exclude list). So, after small update of unit (aka integration, aka regression etc) tests and resolution of all entries in the exclude list we don't need any groups and pure JUnit covers all our needs :) On the other side, if we define some groups it will nice to define *all* reasonable groups at the begin of the process. Yes. We should figure out all possible groups. And it can be consolidated during applying TestNG. Agree. thanks, Vladimir thanks, Vladimir By the way, our regression tests are 'classic' regression tests that demonstrate some issues which were not resolved by initial code. But it provides less coverage than 'regression tests' + unit tests, of cause. On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail- archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM
Re: [classlib][text] ChoiceFormat pattern parser compatibility
On 9/5/06, Denis Kishenko [EMAIL PROTECTED] wrote: People what do you think about HARMONY-1110? Problem is we have to reproduce behavior of ChoiceFormat pattern parser without specification. There is only one example in Java doc which doesn't allow understand when RI assumes that pattern is incorrect. According the sample in sepc, the rule is very straightforward except there's no explicit description about expcetional cases. IMHO, 2#ok #ab and 2#ok ab are illegal patterns, we shall follow RI. I'm a bit confused about 2|, it's illegal too. But maybe we could also follow RI if it's not too hard to follow RI. ;-) Best regards, Richard Thanks -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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][text] ChoiceFormat pattern parser compatibility
Wow, How many examples do you have? ;-)
As ChoiceFormat is a format engine, it's impossible to list all the
exceptional cases.
IMHO, maybe we could 1) *guess* the rules behind RI's strange behavior
by adding more test cases. 2) try our best to implement the rules of
RI. 3) And then, leave this issue as bug-driven, that is, if there are
user applications fail due to the difference between RI and Harmony,
we fix our code.
Does it make sense? Thanks a lot.
Best regards,
Richard
On 9/5/06, Denis Kishenko [EMAIL PROTECTED] wrote:
One more example of strange RI behaviour
-
import java.text.*;
public class Test {
static void test(String pattern) {
System.err.print([ + pattern + ] );
try {
System.err.println(new ChoiceFormat(pattern).toPattern());
} catch (Exception e) {
System.err.println(e);
}
}
public static void main(String[] args) {
test(|||);
test(2#a|||);
test(1);
}
}
- Output
RI
[|||] 0.0#|0.0#|0.0#
[2#a|||] 2.0#a|2.0#|2.0#
[1] 1.0|1.0|1.0|1.0
Harmony
[|||]
[2#a|||]
[1]
2006/9/5, Richard Liang [EMAIL PROTECTED]:
On 9/5/06, Denis Kishenko [EMAIL PROTECTED] wrote:
People what do you think about HARMONY-1110?
Problem is we have to reproduce behavior of ChoiceFormat pattern parser
without
specification. There is only one example in Java doc which doesn't
allow understand when RI assumes that pattern is incorrect.
According the sample in sepc, the rule is very straightforward except
there's no explicit description about expcetional cases.
IMHO, 2#ok #ab and 2#ok ab are illegal patterns, we shall follow
RI. I'm a bit confused about 2|, it's illegal too. But maybe we
could also follow RI if it's not too hard to follow RI. ;-)
Best regards,
Richard
Thanks
--
Denis M. Kishenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
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]
--
Denis M. Kishenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
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][TestNG] groups of Harmony test
Mikhail Loenko wrote:
Hi Vladimir
Could you please decribe for what purpose it will be used?
I mean why one might have to either exclude or run only regression tests?
If running all tests takes up much time, running all regression test
(for one particular version) may be a convenient way to verify the
correctness of bug-fixing.
Best regards,
Richard.
Thanks,
Mikhail
2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
Yes, I do. While tests can have more than one group it will enough.
thanks, Vladimir
Richard
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei
Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO,
most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the
groups. e.g
.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that
is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
because
of bugs of tests or implementation. We need to fix the bugs of
tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail
on one
specific platform. A test may be in more than one of the
groups. e.g
.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a
convenient
way
to indicate that a test is platform-specific. e.g., If we
support 10
platforms, and one test are designed for 9 platforms except for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for
Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the
verification
of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we
may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to
figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG
to add
a
new option -groups for its JUnitConverter which allow us to
specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your
comments
or suggestion. ;-)
--
Richard Liang
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]
--
Richard Liang
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
Re: Re: [classlib][TestNG] groups of Harmony test
On 9/4/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:
I sent my reply this afternoon, but I have not received it. (it seems
there
is something wrong with my smtp server). So I send it again. :-)
On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote:
IMNSO it doesn't make sense to arbitrarily partition the tests based
on a moniker, such as 'integration test', 'unit test', 'regression
test' etc. For one thing, developers are generally not good at
agreeing on the difference between them :-)
This is really a problem, however it might be simpler than we imagine. We
are open to any discussion. ;-) Anyway, developers are required to write
unit tests.
If you've got fast and slow tests, then have a group for fast and slow
tests. Then you can choose to just run the fast tests, and any
automated build system can handle running the slow tests.
IMHO, fast or slow may not be the key point. The question is whether we
have any requirements to run only the regression tests.
I think your first proposal looks fine. Platform + os + state + api/impl
information are enough for all tests. We have to assure all tests pass on
every platform.
Thanks a lot. Well, I agree :-). TestNG annotations are most helpful
to us in the management of unit tests that are prone to change. For
example, some unit tests suddenly break on a particular platform. or
we may want to exclude some tests temporarily.
Here I just try to list all the possible facets, so that we could
have more thorough discussion.
Best regards,
Richard
For quick run, developers can use their own short approach, like run single
test in IDE... It's not business of TestNG. :-)
Best regards,
Richard
Alex.
On 04/09/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
Hi Vladimir
Could you please decribe for what purpose it will be used?
I mean why one might have to either exclude or run only regression
tests?
If running all tests takes up much time, running all regression test
(for one particular version) may be a convenient way to verify the
correctness of bug-fixing.
Thanks Richard. It is exactly what I want to say :)
On the other hand may be all proposed groups need similar explanation
(smt.
like use-case for group)?
thanks, Vladimir
Best regards,
Richard.
Thanks,
Mikhail
2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
Yes, I do. While tests can have more than one group it will
enough.
thanks, Vladimir
Richard
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the
related
threads which posted by George, Vladimir Ivanov and Alexei
Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the
following
4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform.
IMHO,
most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for
one
specific platform. A test may be in more than one of the
groups. e.g
.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive,
that
is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every
platform,
because
of bugs of tests or implementation. We need to fix the
bugs
of
tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only
fail
on one
specific platform. A test may be in more than one of the
groups. e.g
.,
@Test(groups={state.broken.linux.IA32,
os.broken.linux.IA64
})
**state.broken.platform id group may be used as a
convenient
way
to indicate that a test is platform-specific. e.g., If we
support 10
platforms, and one test are designed for 9 platforms
except
for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs
Re: [classlib][TestNG] groups of Harmony test
On 9/4/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Well, my question was for what particular reason? for example?
Tio verify correctness of bug-fixing IMHO all the unit, intergration,
api, and
regression tests should be run
Running all tests are always good to verify our code quality. And I
think this is what we have been doing. But what will we do if it takes
us 24 hours to run all Harmony tests? Anyway, running regression tests
could provide some confidence to our bug-fixing. We may consider it as
another option. :-)
I prefer to run all tests in one module instead. :) Although it can not
guarentee all tests would pass, it's less likey to break build system
frequently. If the fix causes other module fails, it shows the lack of
tests in its module. And we should add the corresponding test in the module.
Running all tests for one module is practical for most cases (except luni).
Currently, Harmony regression test is a test for certain Harmony jira issue.
So IMHO, running all regression tests for certain issue doesn't make sense.
Yes, Harmony regression test is not the so-called regression test
which aim to verify that no unwanted changes were introduced to one
part of the system as a
result of making changes to another part of the system.
I agree that we may not want to run all the regression test. If
there is no objection I will remove level.regression
But whether using annotation to mark regression test is another story. At
least, it doesn't have any disadvantages compared with comment way, does it?
We may use @Test(description=Regression: Harmony-).
Best regards,
Richard
Thanks,
Mikhail
2006/9/4, Richard Liang [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Hi Vladimir
Could you please decribe for what purpose it will be used?
I mean why one might have to either exclude or run only regression
tests?
If running all tests takes up much time, running all regression test
(for one particular version) may be a convenient way to verify the
correctness of bug-fixing.
Best regards,
Richard.
Thanks,
Mikhail
2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
Yes, I do. While tests can have more than one group it will enough.
thanks, Vladimir
Richard
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the
related
threads which posted by George, Vladimir Ivanov and Alexei
Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the
following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO,
most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for
one
specific platform. A test may be in more than one of the
groups. e.g
.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive,
that
is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every
platform,
because
of bugs of tests or implementation. We need to fix the bugs
of
tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only
fail
on one
specific platform. A test may be in more than one of the
groups. e.g
.,
@Test(groups={state.broken.linux.IA32,
os.broken.linux.IA64})
**state.broken.platform id group may be used as a
convenient
way
to indicate that a test is platform-specific. e.g., If we
support 10
platforms, and one test are designed for 9 platforms except
for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the
Java
Specification
*type.impl* - groups of tests which are tests for
Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase
Re: [classlib][security] Exception compatibility
On 9/4/06, Boris Kuznetsov [EMAIL PROTECTED] wrote: Usually Harmony behavior is compared with RI behavior. But in security area RI behavior depends on provider. With different providers RI behave differently. For example, RI passes incorrect method arguments to provider. In such cases provider may throw exception (e.g. DigestException or IllegalArgumentException) or some RuntimeException (e.g. ArrayIndexOutOfBoundsException) may be thrown during the execution. Here is example. There are number of methods with arguments like (byte[] buf, int offset, int len). RI doesn't check if offset and len are negative but Harmony does, so we have difference in behavior (see Harmony-1120, 1148): on combination RI + provider application gets provider specific exception, but on Harmony + provider - IllegalArgumentException (as in other invalid parameters cases). So we have two options: 1. Fix Harmony (remove negative parameters checks) 2. Don't fix. Throw IllegalArgumentException for invalid parameters. Document as non-bug difference from RI. Note, specification doesn't describe implementation behavior for invalid arguments, but RI also throws IllegalArgumentException if ofsset+len buf.length. So throwing of IllegalArgumentException in Harmony can't break any application. I suggest option 2. Thoughts? According to our Compatibility guidelines[1], I suggest we follow RI for this issue, because the spec does not describe the behavior clearly and it seems that RI's behavior is not so illogical ;-) [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html Best regards, Richard Thanks, Boris - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. [1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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: Re: Re: [classlib][TestNG] groups of Harmony test
On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote: If you've got fast and slow tests, then have a group for fast and slow tests. Then you can choose to just run the fast tests, and any automated build system can handle running the slow tests. IMHO, fast or slow may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) I agree. For example, os.win and os.linux are not mutually exclusive. Thanks a lot. and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. That makes sense through we have not clear requirement currently. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Really? ;-) We could also discuss whether it's feasible to move to TestNG. As you may know, there are already several threads about TestNG JUnit. Here I just review the open questions one by one so that we have sufficient preparation. Alex, I must say sorry if I misunderstood you. I mean here we could discuss anything related to Harmony testing. ;-) Best regards, Richard [1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Best regards, Richard Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM -- Richard Liang 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] ICU4C 3.6 and ICU4J 3.4.5 have been released]
Andrew Zhang wrote: Great news! Hope many bugs in charset/io/util will disappear with latest icu release. For nio-charsets, we have to wait for icu4jni 3.6 which has been delayed for one month. :-( Best regards, Richard On 9/3/06, Richard Liang [EMAIL PROTECTED] wrote: Hello, I will have a look at if there are any problems to move to the new release of ICU. ;-) Best regards, Richard Original Message Subject:[icu-support] ICU4C 3.6 and ICU4J 3.4.5 have been released Date: Fri, 1 Sep 2006 11:45:08 -0700 From: George Rhoten [EMAIL PROTECTED] Reply-To: ICU support mailing list [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] We are pleased to announce that ICU4C 3.6 was released today. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.6.html ICU4J 3.4.5 was also released today. More information about this release can be found on the following ICU download page. http://icu.sourceforge.net/download/3.4.html The ICU4J 3.6 d01 draft release will be available next week. Please stay tuned for more information on that release. George Rhoten IBM Globalization Center of Competency/ICU San José, CA, USA http://www.icu-project.org/ http://icu.sourceforge.net/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ icu-support mailing list - [EMAIL PROTECTED] To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-support -- Richard Liang China Software Development Lab, IBM -- Richard Liang 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][TestNG] groups of Harmony test
Stepan Mishura wrote:
On 8/25/06, Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related threads
which posted by George, Vladimir Ivanov and Alexei Zakharov. All of them
are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.platform id* - group of tests which are designed for one specific
platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests or
implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
If a test is marked as *state.broken.MacOS* then it sounds like the
test/implementation should be fixed. IMO we should use tag
os.platform id
to define explicitly valid platforms for the test so in this
particular case
we should use 9 os.platform ids
Thank you, Stepan. This sounds reasonable, we should explicitly list
the valid platforms.
Best regards,
Richard
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project. e.g.,
harmony/enhanced/SVT (System Verification Test).
Mixing different types of testing into one test-file doesn't look good
for
me. I'd separate such tests by placing into different
directories/packages.
Thanks,
Stepan.
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Well, I think our most of existing tests are in the groups of {os.any,
type.api, level.unit}, and I have asked TestNG to add a new option
-groups for its JUnitConverter which allow us to specify the test
groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments or
suggestion. ;-)
--
Richard Liang
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]
--
Richard Liang
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: [general] jira issues tracking
Geir Magnusson Jr. wrote: Salikh Zakirov wrote: Hi, I have just tried to use JIRA to see how many unapplied patches are there for DRLVM, but couldn't search just for the issues with patch provided. Does anyone know of a good way to find just the issues with patches submitted? If there is no good way, probably subtasks feature of JIRA could be used, e.g., create subtask for each patch submitted. Subtasks are then easily searchable. I have also seen that other projects in JIRA use Patch available status, but I do not know how non-committer could change the issue state, so this does not look like a solution. We could turn this on for non-committers - I see no danger... does anyone? I'm using thunderbird to search all the mails of which subjects start from [jira] Updated: to see how many patches I have submitted :-) But it would be better if we could use the build-in functions of JIRA system. Best regards, Richard geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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]
[classlib][sql] Another confusing behavior: java.sql.Timestamp
Hello All,
RI's java.sql.Timestamp(long time) behaves confusing when the
parameter time is in Long.MIN_VALUE. Shall we follow RI?
Output of the following sample is:
time: -9223372036854775808
time: 9223372036854775192
timestamp: 292278994-08-17 15:12:55.192
timestamp: 292278994-08-17 15:12:55.192
=
import java.sql.Timestamp;
public class TimeStampTest {
public static void main(String[] args) {
long time = Long.MIN_VALUE;
long time2 = 9223372036854775192l;
Timestamp timestamp = new Timestamp(time);
Timestamp timestamp2 = new Timestamp(time2);
System.out.println(time: + time);
System.out.println(time: + time2);
System.out.println(timestamp: + timestamp);
System.out.println(timestamp: + timestamp2);
}
}
--
Richard Liang
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][TestNG] groups of Harmony test
Tony Wu wrote:
I think we can treat something like *os.any*,*type.api* as default
groups.Itwill make our logic more clear and bring convenience to
testcase writing :)
for example, an os.platformid group indicates that it is designed for
paltformid only. If there is no group like os.platformid here,
this is a
*os.any* test.
so if we want to run all *api* tests on *win32* platform which is *not
broken*, we could write the testng.xml like this:
groups
run
include name=.* /
exclude name=type.impl /
exclude name=os\.(?!win\.IA32).* /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello Tony,
It's a good idea. However, we shall define a default group which means
os.any, type.impl, level.unit. Thanks a lot.
Best regards,
Richard
2006/8/29, Vladimir Ivanov [EMAIL PROTECTED]:
Also some tag for regression tests should be added.
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a
convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the
verification of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to
figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to
add a
new option -groups for its JUnitConverter which allow us to
specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your
comments
or suggestion. ;-)
--
Richard Liang
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]
--
Richard Liang
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][TestNG] groups of Harmony test
Richard Liang wrote:
Tony Wu wrote:
I think we can treat something like *os.any*,*type.api* as default
groups.Itwill make our logic more clear and bring convenience to
testcase writing :)
for example, an os.platformid group indicates that it is designed for
paltformid only. If there is no group like os.platformid here,
this is a
*os.any* test.
so if we want to run all *api* tests on *win32* platform which is *not
broken*, we could write the testng.xml like this:
groups
run
include name=.* /
exclude name=type.impl /
exclude name=os\.(?!win\.IA32).* /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello Tony,
It's a good idea. However, we shall define a default group which
means os.any, type.impl, level.unit. Thanks a lot.
And even the default group is not necessary by removing the include
name=.* /
groups
run
exclude name=type.impl /
exclude name=os\.(?!win\.IA32).* /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Richard
Best regards,
Richard
2006/8/29, Vladimir Ivanov [EMAIL PROTECTED]:
Also some tag for regression tests should be added.
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei
Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
because
of bugs of tests or implementation. We need to fix the bugs of
tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on
one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a
convenient way
to indicate that a test is platform-specific. e.g., If we
support 10
platforms, and one test are designed for 9 platforms except for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the
verification of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to
figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to
add a
new option -groups for its JUnitConverter which allow us to
specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your
comments
or suggestion. ;-)
--
Richard Liang
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]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org
Re: [classlib][TestNG] groups of Harmony test
Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
Richard
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to add a
new option -groups for its JUnitConverter which allow us to specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or suggestion. ;-)
--
Richard Liang
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]
--
Richard Liang
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][TestNG] groups of Harmony test
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups.
e.g., @Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
I suggest to separate the CPU arch with OS, they are actually
different things, and we probably will have tests written for all
64bits arch, or for all Linux OS.
Thanks a lot, Paulex. I agree. Separating os and arch make our groups
more flexible. I will update the grouping proposal soon to integrate
your and others' suggestion.
Best regards,
Richard
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups.
e.g., @Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient
way to indicate that a test is platform-specific. e.g., If we support
10 platforms, and one test are designed for 9 platforms except for
MacOS, instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification
of the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to add
a new option -groups for its JUnitConverter which allow us to
specify the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or suggestion. ;-)
--
Richard Liang
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][sql] Another confusing behavior: java.sql.Timestamp
Geir Magnusson Jr. wrote:
1) What should it do?
When calculating nanos value, underflow may occur if the given time is
near Long.MIN_VALUE. In fact, I'm also not sure what it should do. Just
notice that RI handles the underflow situation in a special/confusing
way, while Harmony does not have any handling.
2) if it's just a single value, why not fix it and never have to deal
w/ it again? Is it an easy fix?
Yes, the fix is quite easy. Do you mean we shall follow RI?
Thanks a lot.
Richard.
geir
Anton Luht wrote:
Hello,
I don't think we should bother about single value which is very
unlikely to happpen in real data.
On 8/29/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
RI's java.sql.Timestamp(long time) behaves confusing when the
parameter time is in Long.MIN_VALUE. Shall we follow RI?
Output of the following sample is:
time: -9223372036854775808
time: 9223372036854775192
timestamp: 292278994-08-17 15:12:55.192
timestamp: 292278994-08-17 15:12:55.192
=
import java.sql.Timestamp;
public class TimeStampTest {
public static void main(String[] args) {
long time = Long.MIN_VALUE;
long time2 = 9223372036854775192l;
Timestamp timestamp = new Timestamp(time);
Timestamp timestamp2 = new Timestamp(time2);
System.out.println(time: + time);
System.out.println(time: + time2);
System.out.println(timestamp: + timestamp);
System.out.println(timestamp: + timestamp2);
}
}
--
Richard Liang
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
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][logging] A non bug difference from RI?
Andrew Zhang wrote:
Hi folks,
When SecurityManager is enabled and all file permissions are disabled, RI
fails to new a FileHandler while Harmony allows.
Following test code shows the differences:
public void test_FileHandler() throws Exception {
FileHandler handler = new FileHandler();
SecurityManager originalSecurityManager =
System.getSecurityManager
();
try {
System.setSecurityManager(new MockFileSecurityManager());
handler.publish(new LogRecord(Level.SEVERE, msg));
// SecurityException is thrown here
handler.close();
} finally {
System.setSecurityManager(originalSecurityManager);
}
}
public static class MockFileSecurityManager extends SecurityManager {
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
System.out.println(check + perm.getName());
throw new SecurityException();
}
}
}
FileHandler.close() spec says Throws: SecurityException - if a security
manager exists and if the caller does not have
LoggingPermission(control)., In the code above, control permission is
allowed. The failure stack trace against RI looks like:
java.lang.SecurityException
at com.andrew.LoggingTest$MockFileSecurityManager.checkPermission(
LoggingTest.java:131)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:700)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:401)
at java.io.File.getCanonicalPath(File.java:531)
at java.io.FilePermission$1.run(FilePermission.java:218)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.FilePermission.init(FilePermission.java:212)
at java.io.FilePermission.init(FilePermission.java:264)
at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
at java.io.File.delete(File.java:869)
at java.util.logging.FileHandler.close(FileHandler.java:594)
at com.andrew.LoggingTest.test_FileHandler(LoggingTest.java:121)
...
The output is check C:\Documents and Settings\myaccount\java0.log.lck
It seems RI tries to delete log file.lck file, but has no permission.
.lck file is never mentioned in spec, and should be implementation
detail.
Current Harmony code never tries to lock a temp empty .lck file, so
the test
passes against Harmony.
If we revise the MockSecurityManager a little, to allow .lck file
permission,
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
if (perm.getName().indexOf(.lck) == -1) {
System.out.println(check + perm.getName());
throw new SecurityException();
}
}
}
The test will pass both against RI and Harmony.
So I'd suggest to leave it as non-bug difference from RI.
I agree.
Richard
Any comments? Thank you!
--
Richard Liang
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: [app] xmlbeans
Nathan Beyer wrote: I take it that means the issue is pretty obvious (very easy to recreate). Can you tell us what you did to recreate it and what class in Harmony is at issue? It seems a bug of java.util.ArrayList. I will attach a patch to fix it. Best regards, Richard -Nathan -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 10:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [app] xmlbeans I reproduce the same error on xmlbeans-2.2.0. Jordan Justen wrote: Well, I don't have much details, but here's the stack trace. I figured it wouldn't be to helpful for the list. I don't see this exception with the sun jvm/classes. Anyway, I'll try debug it some... [java] java.lang.NullPointerException [java] at org.apache.xmlbeans.impl.common.NameUtil.splitWords( NameUtil.java:667) [java] at org.apache.xmlbeans.impl.common.NameUtil.lowerCamelCase( NameUtil.java:623) [java] at org.apache.xmlbeans.impl.common.NameUtil.getPackageFromNamespace( NameUtil.java:513) [java] at org.apache.xmlbeans.impl.common.NameUtil.getClassNameFromQName(NameUtil.ja va :328) [java] at org.apache.xmlbeans.impl.common.NameUtil.getClassNameFromQName(NameUtil.ja va :318) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.pickFullJavaClassName( StscJavaizer.java:679) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.assignGlobalJavaNames( StscJavaizer.java:91) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.javaizeAllTypes( StscJavaizer.java:55) [java] at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl( SchemaTypeSystemCompiler.java:313) [java] at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile( SchemaTypeSystemCompiler.java:181) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem( SchemaCompiler.java:952) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile( SchemaCompiler.java:1072) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.main( SchemaCompiler.java:368) On 8/27/06, Nathan Beyer [EMAIL PROTECTED] wrote: Is there a particular issue that you've run into? -Original Message- From: Jordan Justen [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 7:10 PM To: harmony-dev@incubator.apache.org Subject: [app] xmlbeans Has anyone successfully used harmony with xmlbeans ( http://xmlbeans.apache.org/)? Or, does anyone know of any major reasons why it would not be working at this time? I tried it without luck. I'll debug the error if no one knows of any major roadblocks that I'd encounter. Thanks, -Jordan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM
Re: [app] xmlbeans
Richard Liang wrote: Nathan Beyer wrote: I take it that means the issue is pretty obvious (very easy to recreate). Can you tell us what you did to recreate it and what class in Harmony is at issue? It seems a bug of java.util.ArrayList. I will attach a patch to fix it. I have raised a JIRA HARMONY-1293[1] for this issue with patch attached. :-) [1] https://issues.apache.org/jira/browse/HARMONY-1293 Richard. Best regards, Richard -Nathan -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 10:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [app] xmlbeans I reproduce the same error on xmlbeans-2.2.0. Jordan Justen wrote: Well, I don't have much details, but here's the stack trace. I figured it wouldn't be to helpful for the list. I don't see this exception with the sun jvm/classes. Anyway, I'll try debug it some... [java] java.lang.NullPointerException [java] at org.apache.xmlbeans.impl.common.NameUtil.splitWords( NameUtil.java:667) [java] at org.apache.xmlbeans.impl.common.NameUtil.lowerCamelCase( NameUtil.java:623) [java] at org.apache.xmlbeans.impl.common.NameUtil.getPackageFromNamespace( NameUtil.java:513) [java] at org.apache.xmlbeans.impl.common.NameUtil.getClassNameFromQName(NameUtil.ja va :328) [java] at org.apache.xmlbeans.impl.common.NameUtil.getClassNameFromQName(NameUtil.ja va :318) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.pickFullJavaClassName( StscJavaizer.java:679) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.assignGlobalJavaNames( StscJavaizer.java:91) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.javaizeAllTypes( StscJavaizer.java:55) [java] at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl( SchemaTypeSystemCompiler.java:313) [java] at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile( SchemaTypeSystemCompiler.java:181) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem( SchemaCompiler.java:952) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile( SchemaCompiler.java:1072) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.main( SchemaCompiler.java:368) On 8/27/06, Nathan Beyer [EMAIL PROTECTED] wrote: Is there a particular issue that you've run into? -Original Message- From: Jordan Justen [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 7:10 PM To: harmony-dev@incubator.apache.org Subject: [app] xmlbeans Has anyone successfully used harmony with xmlbeans ( http://xmlbeans.apache.org/)? Or, does anyone know of any major reasons why it would not be working at this time? I tried it without luck. I'll debug the error if no one knows of any major roadblocks that I'd encounter. Thanks, -Jordan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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]
[classlib][build] bug of RI 1.5.0_08 compiler
Hello, Our incremental build does not work under the new compiler. 1) ant clean 2) ant 3) modify a piece of code 4) ant Then, lots of compilation error are reported. To make the build pass, call ant clean before the build. Could anyone re-produce this issue? Thanks a lot. Best regards, -- Richard Liang 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][TestNG] groups of Harmony test
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to add a
new option -groups for its JUnitConverter which allow us to specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or suggestion. ;-)
--
Richard Liang
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: [app] ant with ecj
Hello Jordan,
All the boot jars have been add in the javac tasks. Could you please
paste the stack trace? Thanks a lot.
Please refer to modules/luni/build.xml
javac
bootclasspath
fileset dir=${hy.jdk}/jre/lib/boot
include name=**/*.jar /
/fileset
/bootclasspath
Best regards,
Richard
Jordan Justen wrote:
Nathan,
Is there a way to have the javac/ecj task include all of standard harmony
jars without including them in the CLASSPATH environment variable?
Thanks,
-Jordan
On 8/27/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Keep in mind that the execution of the Ant scripts and the
compilation are
two separate things, which means they are using two different
classpaths.
If
the compilation task is complaining about a missing class, then this
means
the class is missing from the classpath of the compiler, not the
classpath
of the executing Ant. You'll need the Eclipse compiler JAR on Ant's
execution classpath to execute the javac task.
This can be confusing when using the Eclipse compiler, since it doesn't
have
any default classpath. Normally when you're using 'javac' from a JDK,
the
classpath of the underlying JRE (all of the java.*, etc classes) is
automatically on the classpath. The Eclipse compiler is not part of a
JDK,
so there is nothing on the classpath by default.
-Nathan
-Original Message-
From: Jordan Justen [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 27, 2006 8:49 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [app] ant with ecj
Richard,
Yes, I also added ecj_3.2.jar to the CLASSPATH.
Ant works fine, but the first time a javac task is encountered, the
compiler
complained that java.lang.Object was not found. I then added
jdk/jre/lib/boot/kernel.jar to CLASSPATH. Now, I see an error that
java.lang.String is not found, so I added luni.jar to CLASSPATH.
etc...
Since ant is basically working (mkdir tasks, delete tasks, java tasks
all
seem to work), I think the harmony jvm is loading these boot
jars, but
it
seems like when the javac task uses ecj, those jars are not visible.
I'm using windows xp, ant 1.6.5, and the latest harmony jdk snapshot.
Thanks again,
-Jordan
On 8/27/06, Richard Liang [EMAIL PROTECTED] wrote:
Jordan Justen wrote:
Hi all.
I'm trying to use ant with the ecj compiler. I override the
compiler
in
build.xml like this:
property name=build.compiler value=
org.eclipse.jdt.core.JDTCompilerAdapter /
This will execute the compiler, but I find I have to add each jar
from
jdk/jre/lib/boot to CLASSPATH or else ecj won't find the standard
classes
during compilation.
This is probably user error, and not related to harmony. :) Does
anyone
know what I might be improperly configuring?
Hello Jordan,
Do you mean the build.compiler property in make/build_java.xml? I
just
give it a try by 1) overriding the compiler as what you have done 2)
adding C:\harmony\workspace\trunk\depends\jars\ecj_3.2\ecj_3.2.jar
into
classpath.
Everything works OK. :-) Could you give more detailed information
about
this issue? Thanks a lot.
Best regards,
Richard
Thanks,
-Jordan
--
Richard Liang
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
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] Sun compiler change?
Nathan Beyer wrote: Is anyone else using the latest Sun JDK, v5.0 Update 8 on Windows? I'm seeing a compilation error in the LUNI that I don't see with 5.0 Update 7. Here's the error I'm getting. compile: [mkdir] Created dir: C:\dev\harmony\enhanced\classlib\trunk\build\classes [javac] Compiling 3173 source files to C:\dev\harmony\enhanced\classlib\trun k\build\classes [javac] C:\dev\harmony\enhanced\classlib\trunk\modules\luni\src\main\java\ja va\util\MiniEnumSet.java:78: inconvertible types [javac] found : java.util.Collectioncapture of ? extends E [javac] required: java.util.EnumSetE [javac] EnumSetE set = (EnumSetE) collection; [javac] ^ Yes, I got the same error using 1.5.0_08. Will have a look at it. :-) Best regards, Richard When I compile in Eclipse 3.2 there's no error. -Nathan -- Richard Liang 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] Sun compiler change?
Richard Liang wrote: Nathan Beyer wrote: Is anyone else using the latest Sun JDK, v5.0 Update 8 on Windows? I'm seeing a compilation error in the LUNI that I don't see with 5.0 Update 7. Here's the error I'm getting. compile: [mkdir] Created dir: C:\dev\harmony\enhanced\classlib\trunk\build\classes [javac] Compiling 3173 source files to C:\dev\harmony\enhanced\classlib\trun k\build\classes [javac] C:\dev\harmony\enhanced\classlib\trunk\modules\luni\src\main\java\ja va\util\MiniEnumSet.java:78: inconvertible types [javac] found : java.util.Collectioncapture of ? extends E [javac] required: java.util.EnumSetE [javac] EnumSetE set = (EnumSetE) collection; [javac] ^ Yes, I got the same error using 1.5.0_08. Will have a look at it. :-) This should be an enhancement/bug-fixing of java compiler. There are bugs in java.util.MiniEnumSet. I will try to fix it later Richard. Best regards, Richard When I compile in Eclipse 3.2 there's no error. -Nathan -- Richard Liang 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]
[classlib][TestNG] groups of Harmony test
Hello All,
Now let's talk about the TestNG groups. I have read the related threads
which posted by George, Vladimir Ivanov and Alexei Zakharov. All of them
are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.platform id* - group of tests which are designed for one specific
platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests or
implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project. e.g.,
harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Well, I think our most of existing tests are in the groups of {os.any,
type.api, level.unit}, and I have asked TestNG to add a new option
-groups for its JUnitConverter which allow us to specify the test
groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments or
suggestion. ;-)
--
Richard Liang
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]
[classlib][TestNG] How to handle bootclasspath tests
Hello All,
I'm investigating the possibilities of migrating Harmony tests from
JUnit/Directory layout to TestNG while reviewing all the related thread
in mailing list. And I will try to answer the open issues. To make
things simple, I will post the issues one by one. ;-)
Question: How to handle bootclasspath tests?
IMHO, I'm not sure whether it is a good idea to use TestNG groups to
differentiate the bootclasspath tests and classpath tests.
If we put bootclasspath and classpath tests in the same directory,
and use TestNG groups to differentiate them. When we want to run the
bootclasspath tests, we have to put all tests in bootclasspath
including the classpath tests. I don't think it's a good approach. And
I cannot find any ways to compile the java sources from one directory
into several different directories (ANT or Eclipse). So I suggest we put
bootclasspath tests and classpath tests into different directories.
But if we think putting all tests into bootclasspath is not a problem,
we may have a workaround: running bootclasspath and classpath tests in
separate tasks. I mean:1) Running bootclasspath tests with all tests
in bootclasspath 2) running all classpath tests with all tests in classpath
Please correct me if I'm wrong.
Here is sample of how to launch TestNG in ANT:
testng outputDir=${testng.report.dir}
sourcedir=${test.src.dir}
haltOnfailure=true
verbose=3
jvm=${HarmonyVM}/bin/java
bootclasspath
pathelement path=../bin/tests.boot /
/bootclasspath
classpath
pathelement path=../bin/tests /
/classpath
xmlfileset dir=. includes=suite.xml /
/testng
Thanks for reading this far. ;-)
--
Richard Liang
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][TestNG] How to handle bootclasspath tests
Mark Hindess wrote:
On 24 August 2006 at 13:58, Oliver Deakin [EMAIL PROTECTED]
wrote:
Richard Liang wrote:
Hello All,
I'm investigating the possibilities of migrating Harmony tests from
JUnit/Directory layout to TestNG while reviewing all the related
thread in mailing list. And I will try to answer the open issues. To
make things simple, I will post the issues one by one. ;-)
Question: How to handle bootclasspath tests?
IMHO, I'm not sure whether it is a good idea to use TestNG groups to
differentiate the bootclasspath tests and classpath tests.
If we put bootclasspath and classpath tests in the same directory,
and use TestNG groups to differentiate them. When we want to run the
bootclasspath tests, we have to put all tests in bootclasspath
including the classpath tests. I don't think it's a good approach.
And I cannot find any ways to compile the java sources from one
directory into several different directories (ANT or Eclipse). So I
suggest we put bootclasspath tests and classpath tests into different
directories.
Agreed - this is a fairly simple separation, and there is good reason to
do it.
My vote's for keeping bootclasspath and classpath tests physically separate.
Yes, I think this is the best way to handle this distinction too.
There are going to be more than enough groups. I thought about some
more earlier while trying the awt tests... we should identify which
tests require a display to run and which may be run headless.
That's a good point, Mark. Just thinking about whether we could skip the
tests which require a display when there is no display available. If
someone try to run Harmony tests on a Linux server, the awt/swing tests
shall be skipped. Any ideas?
I will open another thread to discuss TestNG groups :-)
Best regards,
Richard
Regards,
Mark.
But if we think putting all tests into bootclasspath is not a
problem, we may have a workaround: running bootclasspath and
classpath tests in separate tasks. I mean:1) Running bootclasspath
tests with all tests in bootclasspath 2) running all classpath tests
with all tests in classpath
Please correct me if I'm wrong.
Here is sample of how to launch TestNG in ANT:
testng outputDir=${testng.report.dir}
sourcedir=${test.src.dir}
haltOnfailure=true
verbose=3
jvm=${HarmonyVM}/bin/java
bootclasspath
pathelement path=../bin/tests.boot /
/bootclasspath
classpath
pathelement path=../bin/tests /
/classpath
xmlfileset dir=. includes=suite.xml /
/testng
Thanks for reading this far. ;-)
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
Re: [testing] metadata approach
Oliver Deakin wrote:
Paulex Yang wrote:
Just a wild thought, because TestNG support both jre142 and jdk5, so
there must be some way to make it run with annotation but without
concurrent, just have a look at the layout of TestNG[1] source code
from its v4.1 release, seems if we replace the
src/jdk15/org/testng/internal/thread/*.java with
src/jdk14/org/testng/internal/thread/*.java, and rebuild it, there is
chance to create a customized version based
edu.emory.mathcs.util.concurrent as workaround. If no one
objection(say, legal consideration), I can try this thought.
That's interesting - I don't know about the legal considerations, but
I'd like
to hear how your experimentation goes!
Hello Oliver,
I have tried Paulex's solution, and I can launch simple TestNG test
using HarmonyVM. But I doubt if this is necessary. Maybe we will have
concurrent soon :-)
Nathan, could you share some information about concurrent?
Best regards,
Richard
Regards,
Oliver
[1] http://testng.org/testng-4.1.zip
Alexei Zakharov wrote:
Hi Oliver,
But is j.u.c actually required to be in the runtime under test? I was
thinking
that j.u.c was only required for the VM actually running the harness,
and all
that gets run on the VM under test is the actual test method. If this
was true,
then we could run TestNG with the RI (which has j.u.c) and use the
jvm option to specify the Harmony VM (which would not need j.u.c).
I afraid we cannot do like that. At least I was not successful last
time I tried to run tests using the jvm=harmony option. As far as
I understand TestNG requires j.u.c for running every single test
method because parallel running can be specified on the method level.
I mean in TestNG you can write something like this:
@Test(threadPoolSize = 7, invocationCount = 29)
This means that this method should be invoked from different threads.
And it seems that TestNG needs j.u.c to implement multithreading.
Yes agreed, it is good to make group membership explicit as it
facilitates
inclusion/exclusion of groups, and makes it obvious which group tests
belong to. Perhaps the same should be done for api tests, so we have a
type.api group?
So you suggest to add @Test (groups={os.any, type.api}) to every api
test (that runs on every platform) without any defaults at all?
I thought I had sent a mail out on this in the original thread, but
I guess
I never did (unless Thunderbird is hiding mail from me again!).
Just checked - there is no such mail in my gmail box, at least in the
[classlib] Testing conventions - a proposal thread.
So, for example, if we were on a Windows x86 32bit machine, the Ant
scripts would run test groups os.shared, os.windows,
os.windows.x86
and (if we ever get any 32/64bit specific tests)
os.windows.x86.32bit,
or something similar.
Well, I like it in general. The only thing I still feel uncomfortable
with is os.shared. When some code is shared among different
platforms it makes sense. But here we have a test shared by several
OSes. Does this sound natural? But I don't feel strongly about that
and will not object if everybody likes this.
With Best Regards,
--
Richard Liang
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][text] Bidi returns directional runs in visual order rather than in logical
Sorry for my late reply, Alexey.
I'm discussing this issue with ICU team, and have not drawn any conclusion till now.
Richard.
Ivanov, Alexey A wrote:
Hello Richard,
Have you taken a look at this issue?
Thanks,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006 12:12 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][text] Bidi returns directional runs in visual
order
rather than in logical
Hello Ivanov,
I will have a look at this issue, and will give my feedback later.
Thanks a lot.
Best regards,
Richard.
Ivanov, Alexey A wrote:
All,
I'd like to attract more attention to this problem because this
incompatibility makes many tests in javax.swing.text package fail.
The
implementation of jx.s.t.AbstractDocument depends on j.t.Bidi.
The root of the problem lies in ICU library. Here we have two
options:
1. Fix the Bidi implementation, to be more precise its counterpart in
ICU;
2. Fix AbstractDocument to handle such illogical run order.
Can text guys comment on this issue?
I decided to cite the test case from the JIRA:
public class Test {
public static final String LTR = \u0061\u0062; // these are
ab
public static final String RTL = \u05DC\u05DD;
public static final String newLine = \n;
public static final String defText = LTR + newLine
+ RTL + LTR + RTL;
public static void main(String[] args) {
Bidi bi = new Bidi(defText,
Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Runs: );
final int count = bi.getRunCount();
for (int i = 0; i count; i++) {
System.out.println(i + : + bi.getRunLevel(i)
+ [ + bi.getRunStart(i)
+ , + bi.getRunLimit(i)
+ ]);
}
}
}
Thank you in advance.
--
Alexey A. Ivanov
Intel Middleware Product Division
P.S. Shall I add compatibility to the subject line?
-Original Message-
From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 01, 2006 3:27 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][text] Bidi returns directional runs in visual
order
rather than in logical
Hi all.
Harmony implementation of java.text.Bidi returns directional runs
(getRunStart(), getRunLimit(), getRunLevel()) in visual order if
paragraph reading order is Right-to-Left. I mean the first run is at
the
end of character buffer, and the last is at the beginning. I'd
expect
directional runs are enumerated in the order of the characters in
the
buffer, i.e. the logical order.
I've created a JIRA issue for this:
https://issues.apache.org/jira/browse/HARMONY-1028
Another difference from the RI is that in Harmony the text is
divided
into paragraphs before directional analysis, which is not done in
the
RI
despite the Unicode Bidirectional Algorithm [1] requires it.
The output of the test case when run on Harmony:
0: 0 [0, 3]
1: 1 [7, 9]
2: 2 [5, 7]
3: 1 [3, 5]
However, I'd expect the following output:
0: 0 [0, 3]
1: 1 [3, 5]
2: 2 [5, 7]
3: 1 [7, 9]
The output of the test case when run on the RI:
0: 0 [0, 3]
1: 1 [3, 5]
2: 0 [5, 7]
3: 1 [7, 9]
Any thoughts?
[1] http://www.unicode.org/reports/tr9/
Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Richard Liang
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]
--
Richard Liang
China Software Development Lab, IBM
Re: [classlib][compatiblity](Re: [jira] Created: (HARMONY-1241) [classlib][util] unexpected IllegalArgumentException for java.util.SimpleTimeZone(13 params))
Paulex Yang wrote:
Seems both Harmony and RI's behavior violates spec, which says:
The mode specifies either wall_time or standard_time or UTC_time.
and |IAE cid:part1.04040504.00010409@gmail.com| - if the month,
day, dayOfWeek, time more, or time parameters are out of range for the
start or end rule, or if a time mode value is invalid.
IIUC, it means only the three constants wall_time(0), standard_time(1)
and UTC_time(2) are valid values for startTimeMode/endTimeMode, but
interesting facts are: RI accepts any values from Integer.MIN_VALUE to
MAX_VALUE, while Harmony accepts 1-4 and throws exception for others.
Further, seems RI doesn't validate some other parameters as spec,too
(startDayOfWeek or so).
I suggest to follow RI in this case, but like to listen to others.
+1 to follow RI.
Vladimir Ivanov (JIRA) wrote:
[classlib][util] unexpected IllegalArgumentException for
java.util.SimpleTimeZone(13 params)
Key: HARMONY-1241
URL: http://issues.apache.org/jira/browse/HARMONY-1241
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
The method java.util.SimpleTimeZone.SimpleTimeZone(int rawOffset,
String ID, int startMonth, int startDay, int startDayOfWeek, int
startTime, int startTimeMode, int endMonth, int endDay, int
endDayOfWeek, int endTime, int endTimeMode, int dstSavings) for
correct parameters throws IllegalArgumentException on Harmony.
=== test.java =
import java.util.SimpleTimeZone;
import java.util.TimeZone;
import java.util.Calendar;
public class test {
public static void main(String args[]) {
System.out.println(DST_OFFSET = + Calendar.DST_OFFSET);
System.out.println(res = + new SimpleTimeZone(
TimeZone.LONG,
Europe/Paris,
SimpleTimeZone.STANDARD_TIME,
SimpleTimeZone.STANDARD_TIME,
SimpleTimeZone.UTC_TIME,
SimpleTimeZone.WALL_TIME,
SimpleTimeZone.WALL_TIME,
TimeZone.SHORT,
SimpleTimeZone.STANDARD_TIME,
TimeZone.LONG,
SimpleTimeZone.UTC_TIME,
SimpleTimeZone.STANDARD_TIME,
TimeZone.LONG));
}
}
===
Output:
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp .
-showversion test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC: System optimized over throughput (initial strategy
singleparpar))
DST_OFFSET = 16
res =
java.util.SimpleTimeZone[id=Europe/Paris,offset=1,dstSavings=1,useDaylight=true,startYear=0,startMode=2,startMonth=1,startDay=1,startDayOfWeek=2
,startTime=0,startTimeMode=0,endMode=2,endMonth=0,endDay=1,endDayOfWeek=1,endTime=2,endTimeMode=1]
C:\tmp\tmp17C:\harmony\classlib1.5\deploy\jdk\jre\bin\java.exe -cp .
-showversion test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors, as applicable.
DST_OFFSET = 16
Exception in thread main java.lang.IllegalArgumentException: DST
offset: 0
at java.util.SimpleTimeZone.init(SimpleTimeZone.java:216)
at test.main(test.java:8)
--
Richard Liang
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] Compatibility: Default buf size of BufferedOutputStream
Vijay Yellapragada wrote:
Hi,
Buffer Size is definitely implementation dependent.
The test should be re done so that it doesn't assume the size of the
buffer.
Yes. Just thinking about if there are any user applications depending on
this behavior :-)
A simple way to structure the test would be :-
- Create a Sub class of BufferedOutputStream.
- Since count and buf have protected access in BufferedOutputStream,
subclassing will allow us to get access to those values.
Once you have the sub class it is now straight forward to determine
the default size of the buffer and the test becomes much simpler in
fact...
Hope that helps..
It really helps. Thanks a lot.
Thanks,
Vijay
Andrew Zhang wrote:
I think it's implementation detail. Any default buffer size is
acceptable as
long as complying with spec.
Of course, if Harmony's default size is equal with RI's by accident,
it's
good. :)
So the problem is test, not implementation code. I suggest modify the
test
even if we fix our default size in the code.
And if some applications are heaviliy dependent on the default size and
refuse to fix their code, I guess they won't become popular. :)
Applications
can take the advantage of the default size, but not to be dependent
on them.
:)
On 8/17/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
One test case tests.api.java.io.BufferedOutputStreamTest.test_write$BII
fails on RI (passes on Harmony) because the default buf size between RI
and Harmony are different. The default buf size is not specified in the
Java Specification. If we can detect what the default buf size of
RI is
by some test cases, shall we use the same default buf size as RI? Any
comments? Thanks a lot.
public void test_write$BII() {
// Test for method void java.io.BufferedOutputStream.write(byte
[], int,
// int)
try {
os = new java.io.BufferedOutputStream(
baos = new java.io.ByteArrayOutputStream());
os.write(fileString.getBytes(), 0, 500);
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertEquals(Bytes written, not buffered, 0,
bais.available());
os.flush();
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertEquals(Bytes not written after flush, 500,
bais.available());
os.write(fileString.getBytes(), 500, 513);
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertTrue(Bytes not written when buffer full,
bais.available() = 1000);
byte[] wbytes = new byte[1013];
bais.read(wbytes, 0, 1013);
assertTrue(Incorrect bytes written,
fileString.substring(0, 1013)
.equals(new String(wbytes, 0, wbytes.length)));
} catch (java.io.IOException e) {
fail(Flush test failed);
}
}
--
Richard Liang
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]
--
Richard Liang
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] Compatibility: Default buf size of BufferedOutputStream
Stepan Mishura wrote:
On 8/17/06, Richard Liang wrote:
Hello All,
One test case tests.api.java.io.BufferedOutputStreamTest.test_write$BII
fails on RI (passes on Harmony) because the default buf size between RI
and Harmony are different. The default buf size is not specified in the
Java Specification. If we can detect what the default buf size of RI is
by some test cases, shall we use the same default buf size as RI? Any
comments? Thanks a lot.
At first glance, the test is wrong - it shouldn't rely on default buffer
size and it should explicitly specify what the buffer size is by using:
BufferedOutputStream(OutputStream out, int size)
Parameters:
out - the underlying output stream.
size - the buffer size.
Yes, we can fix the test case this way. Here I just want to confirm that
the default buf size is implementation detail, we are free to be
different with RI.
I will raise a JIRA to fix this test.
Thanks a lot.
Thanks,
Stepan.
public void test_write$BII() {
// Test for method void java.io.BufferedOutputStream.write(byte
[], int,
// int)
try {
os = new java.io.BufferedOutputStream(
baos = new java.io.ByteArrayOutputStream());
os.write(fileString.getBytes(), 0, 500);
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertEquals(Bytes written, not buffered, 0,
bais.available());
os.flush();
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertEquals(Bytes not written after flush, 500,
bais.available());
os.write(fileString.getBytes(), 500, 513);
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertTrue(Bytes not written when buffer full,
bais.available() = 1000);
byte[] wbytes = new byte[1013];
bais.read(wbytes, 0, 1013);
assertTrue(Incorrect bytes written,
fileString.substring(0, 1013)
.equals(new String(wbytes, 0, wbytes.length)));
} catch (java.io.IOException e) {
fail(Flush test failed);
}
}
--
Richard Liang
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]
--
Richard Liang
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] Enable tests.api.java.net.DatagramSocketTest?
Tim Ellison wrote: Andrew Zhang wrote: Hi folks, After applying Harmony-1024, tests.api.java.net.DatagramSocketTest passes against Harmony on my machine. Before enabling it, I'd like to hear more feedbacks from community. Would you please provide your test result on running DatagramSocketTest against Harmony? Thank you very much in advance! Did you mean HARMONY-1024? that's a JNDI issue. Hello Tim, I think it should be HARMONY-1204 :-) Richard Regards, Tim -- Richard Liang China Software Development Lab, IBM
[classlib][luni] Compatibility: Default buf size of BufferedOutputStream
Hello All,
One test case tests.api.java.io.BufferedOutputStreamTest.test_write$BII
fails on RI (passes on Harmony) because the default buf size between RI
and Harmony are different. The default buf size is not specified in the
Java Specification. If we can detect what the default buf size of RI is
by some test cases, shall we use the same default buf size as RI? Any
comments? Thanks a lot.
public void test_write$BII() {
// Test for method void java.io.BufferedOutputStream.write(byte
[], int,
// int)
try {
os = new java.io.BufferedOutputStream(
baos = new java.io.ByteArrayOutputStream());
os.write(fileString.getBytes(), 0, 500);
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertEquals(Bytes written, not buffered, 0,
bais.available());
os.flush();
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertEquals(Bytes not written after flush, 500,
bais.available());
os.write(fileString.getBytes(), 500, 513);
bais = new java.io.ByteArrayInputStream(baos.toByteArray());
assertTrue(Bytes not written when buffer full,
bais.available() = 1000);
byte[] wbytes = new byte[1013];
bais.read(wbytes, 0, 1013);
assertTrue(Incorrect bytes written,
fileString.substring(0, 1013)
.equals(new String(wbytes, 0, wbytes.length)));
} catch (java.io.IOException e) {
fail(Flush test failed);
}
}
--
Richard Liang
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: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
sums up my thoughts. Allow me to quote myself: paste Jetty or equivalent is a good basis for such local server stubs. It is fast, it is lightweight, Fast and lightweight as what? I saw sometimes ago java server that has jar size 4k. And jetty-6.0.0beta6.jar is 423k size. Not sure of your point here. Is there some test file footprint benchmark that is at risk here ? If there is a better, faster, more lightweight server that would suit our purposes then let's hear about it so that we can investigate whether or not it may be used with our network tests. it can be started and stopped very simply from within Ant (so that it only runs for the duration of a specified batch of unit tests) and may also be completely controlled from Java test code so that we can configure its behaviour for any test case from within that test case. Good. It's architecture means that we do not have to run it as a complete web server but can stub out any aspect of its runtime behaviour we wish in order to suit the purposes of the test(s). What about 'chunked response'? Can a testcase force jetty server to send it a chunked response? Yes. The API provides options to do this. Chunks are encoded as per RFC2616. Best regards, George I don't really understand why such network tests making use of a small, embedded server running locally would need to be considered as outside of the normal test flow. /paste Because I consider adding jetty server as precedent for adding other dependencies to the normal test flow. I believe that normal test flow should be fast and lightweight as much as possible. Each additional dependency or configuration step adds a brick(even it light) to developer's large. As the result classlib test suite may become very slow and hard to configure. All I want is to understand - do we really need jettyserver inside it. Thanks, Stepan. We are not talking about an external server here and we are not talking about developers having to carry out complex configuration manoeuvres when running the tests. That is something that nobody wants. The motivation here is purely to get more of the java.net tests out of the excludes sin bin. Best regards, George Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM -- Richard Liang 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: svn commit: r424890 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/io/BufferedInputStream.java test/java/tests/api/java/io/BufferedInputStreamTest.java
Richard Liang wrote:
Vladimir Ivanov wrote:
No, this test will be fail if the issue 667 returns back :)
I see. Thanks a lot. I will try to provide a patch to fix this issue.
Harmony-1140 was raised. And Paulex had applied my patch. Thanks a lot.
Best regards,
Richard
Richard
Thanks, Vladimir
On 8/10/06, Richard Liang [EMAIL PROTECTED] wrote:
Paulex Yang wrote:
Oops, it's my fault that missed to find this. Would you mind to
provide a patch for this? or I'll fix it myself.
let me fix it. But I'm not sure if Vladimir Ivanov has any concerns
about this issue.
Richard.
Richard Liang wrote:
Hello Paulex,
It seems that the test case is invalid, because the tests will
always
pass whether buf.close() throws IOException or not.
+try {
+buf.close();
+} catch (IOException e) {
+//expected
+} }
Please have a look at the following tests which passes on RI, but
fails on Harmony.
public void test_close() throws IOException {//regression
for
HARMONY-667
BufferedInputStream buf = new BufferedInputStream(null, 5);
buf.close();
}
Thanks a lot.
Best regards,
Richard.
[EMAIL PROTECTED] wrote:
Author: pyang
Date: Sun Jul 23 20:29:14 2006
New Revision: 424890
URL: http://svn.apache.org/viewvc?rev=424890view=rev
Log:
Fix for HARMONY-667 (
[classlib][io]java.io.BufferedInputStream.skip(int n) unexpected
NPE)
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java?rev=424890r1=424889r2=424890view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
Sun Jul 23 20:29:14 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its
licensors, as applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its
licensors, as applicable
* * Licensed under the Apache License, Version 2.0 (the
License);
* you may not use this file except in compliance with the
License.
@@ -109,6 +109,9 @@
* If an error occurs attempting to close this
stream.
*/
public synchronized void close() throws IOException {
+if(null == in){
+throw new
IOException(org.apache.harmony.luni.util.Msg.getString(K0059));
+}
super.close();
buf = null;
}
@@ -311,6 +314,9 @@
* occurs.
*/
public synchronized long skip(long amount) throws
IOException {
+if(null == in){
+throw new
IOException(org.apache.harmony.luni.util.Msg.getString(K0059));
+}
if (amount 1)
return 0;
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java?rev=424890r1=424889r2=424890view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
Sun Jul 23 20:29:14 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its
licensors, as applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its
licensors, as applicable
* * Licensed under the Apache License, Version 2.0 (the
License);
* you may not use this file except in compliance with the
License.
@@ -120,6 +120,14 @@
// Test for method void
java.io.BufferedInputStream.close()
new BufferedInputStream(isFile);
new BufferedInputStream(isFile);
+ +//regression for HARMONY-667
+BufferedInputStream buf = new BufferedInputStream(null,
5);
+try {
+buf.close();
+} catch (IOException e) {
+//expected
+} }
/**
@@ -310,6 +318,14 @@
} catch (java.io.IOException e) {
fail(Exception during skip test);
}
+
+//regression
Re: [classlib][summary] Exception throwing compatibility
Harmony-1170 has been raised to reflect our conclusion. I have attached a patch for site/xdocs/subcomponents/classlibrary/compat.xml Best regards, Richard Richard Liang wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- Richard Liang 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][String] Request for fixing bug in String(byte[] bytes, int offset, int length, String charsetName)
Geir Magnusson Jr wrote:
Never worry if there will be an objection to you raising a JIRA and
providing a patch.Just Do It!
Thanks a lot, Geir.
HARMONY-1157 was raised. And Tim had applied my patch.
Best regards,
Richard
:)
geir
Richard Liang wrote:
Hello All,
The constructor String(byte[] bytes, int offset, int length, String
charsetName) has the same bug as Harmony-487[1]. When the charsetName
is , RI throws UnsupportedEncodingException, but Harmony throws
IllegalCharsetNameException.
If there is no objection, I will raise a JIRA and provide a patch for
this issue. Thanks a lot.
The following test passes on RI, but fails on Harmony:
try {
String str = new String(new byte[] {0x41, 0x42}, 0, 2, );
fail(Should throw UnsupportedEncodingException);
} catch (UnsupportedEncodingException e) {
//expected
}
[1]http://issues.apache.org/jira/browse/HARMONY-487
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
[classlib][String] Request for fixing bug in String(byte[] bytes, int offset, int length, String charsetName)
Hello All,
The constructor String(byte[] bytes, int offset, int length, String
charsetName) has the same bug as Harmony-487[1]. When the charsetName
is , RI throws UnsupportedEncodingException, but Harmony throws
IllegalCharsetNameException.
If there is no objection, I will raise a JIRA and provide a patch for
this issue. Thanks a lot.
The following test passes on RI, but fails on Harmony:
try {
String str = new String(new byte[] {0x41, 0x42}, 0, 2, );
fail(Should throw UnsupportedEncodingException);
} catch (UnsupportedEncodingException e) {
//expected
}
[1]http://issues.apache.org/jira/browse/HARMONY-487
--
Richard Liang
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][summary] Exception throwing compatibility
Vladimir Ivanov wrote: On 8/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/8/9, Richard Liang [EMAIL PROTECTED]: If the spec does not specify which exception is thrown, I think RI *is* compliant with the specification. Am I wrong? I wanted to separate cases when the spec is not clear enough and RI's behavior either hard to reproduce or odd. For example if sqrt(-2) threw exception1, sqrt(-5) threw exception2 and sqrt(-187) threw exception3 The real example is issue 1114 :) Great catch ;-) I have updated the wiki page. Best regards, Richard Thanks, Vladimir Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang 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: svn commit: r424890 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/io/BufferedInputStream.java test/java/tests/api/java/io/BufferedInputStreamTest.java
Vladimir Ivanov wrote:
No, this test will be fail if the issue 667 returns back :)
I see. Thanks a lot. I will try to provide a patch to fix this issue.
Richard
Thanks, Vladimir
On 8/10/06, Richard Liang [EMAIL PROTECTED] wrote:
Paulex Yang wrote:
Oops, it's my fault that missed to find this. Would you mind to
provide a patch for this? or I'll fix it myself.
let me fix it. But I'm not sure if Vladimir Ivanov has any concerns
about this issue.
Richard.
Richard Liang wrote:
Hello Paulex,
It seems that the test case is invalid, because the tests will always
pass whether buf.close() throws IOException or not.
+try {
+buf.close();
+} catch (IOException e) {
+//expected
+} }
Please have a look at the following tests which passes on RI, but
fails on Harmony.
public void test_close() throws IOException {//regression for
HARMONY-667
BufferedInputStream buf = new BufferedInputStream(null, 5);
buf.close();
}
Thanks a lot.
Best regards,
Richard.
[EMAIL PROTECTED] wrote:
Author: pyang
Date: Sun Jul 23 20:29:14 2006
New Revision: 424890
URL: http://svn.apache.org/viewvc?rev=424890view=rev
Log:
Fix for HARMONY-667 (
[classlib][io]java.io.BufferedInputStream.skip(int n) unexpected
NPE)
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java?rev=424890r1=424889r2=424890view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
Sun Jul 23 20:29:14 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its
licensors, as applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its
licensors, as applicable
* * Licensed under the Apache License, Version 2.0 (the
License);
* you may not use this file except in compliance with the License.
@@ -109,6 +109,9 @@
* If an error occurs attempting to close this
stream.
*/
public synchronized void close() throws IOException {
+if(null == in){
+throw new
IOException(org.apache.harmony.luni.util.Msg.getString(K0059));
+}
super.close();
buf = null;
}
@@ -311,6 +314,9 @@
* occurs.
*/
public synchronized long skip(long amount) throws IOException {
+if(null == in){
+throw new
IOException(org.apache.harmony.luni.util.Msg.getString(K0059));
+}
if (amount 1)
return 0;
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java?rev=424890r1=424889r2=424890view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
Sun Jul 23 20:29:14 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its
licensors, as applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its
licensors, as applicable
* * Licensed under the Apache License, Version 2.0 (the
License);
* you may not use this file except in compliance with the License.
@@ -120,6 +120,14 @@
// Test for method void java.io.BufferedInputStream.close()
new BufferedInputStream(isFile);
new BufferedInputStream(isFile);
+ +//regression for HARMONY-667
+BufferedInputStream buf = new BufferedInputStream(null, 5);
+try {
+buf.close();
+} catch (IOException e) {
+//expected
+} }
/**
@@ -310,6 +318,14 @@
} catch (java.io.IOException e) {
fail(Exception during skip test);
}
+
+//regression for HARMONY-667
+BufferedInputStream buf = new BufferedInputStream(null, 5);
+try {
+buf.skip(10
Re: [classlib][summary] Exception throwing compatibility
Tim Ellison wrote: We don't have such a JIRA category: If we decide to follow RI, we will raise an Non-bug differences from Spec JIRA. Do you think we need this category to record Harmony's complying-with-RI behavior while breaking the spec? Thanks a lot. Best regards, Richard Do you really need the section starting: We consider RI is compliant with the Java Specification, if RI... Regards, Tim Richard Liang wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- Richard Liang China Software Development Lab, IBM
