You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Alexei Zakharov (JIRA)" <ji...@apache.org> on 2006/07/21 19:57:13 UTC

[jira] Created: (HARMONY-952) [classlib][beans] final clean up of StatementTest (6)

[classlib][beans] final clean up of StatementTest (6)
-----------------------------------------------------

                 Key: HARMONY-952
                 URL: http://issues.apache.org/jira/browse/HARMONY-952
             Project: Harmony
          Issue Type: Improvement
          Components: Classlib
         Environment: winXP
            Reporter: Alexei Zakharov
         Attachments: StatementTest6.patch

Change log:

1. I've found that testExecute_OverloadedMethodsNull is an invalid test in fact, it checks ambiguous behaviour that depends on the order of elements 
returned by Class.getMethods(). I have reworked it and renamed to testExecute_NormalInstanceMethodNull

2. The same thing with testExecute_OverloadedConstructorsNull. Was renamed to testExecute_NormalConstructorNull.

3. Again the same for testExecute_EqualSpecificMethods testExecute_EqualSpecificMethodsException. Fail on RI. In this case the only purpose of these tests is to check this odd implementation-specific behavior of java.lang.Class. IMHO these tests should be removed.

4. testExecute_IntMethodNullParameter fails on RI also, was corrected. NoSuchMethodException should be thrown in this case rather than NullPointerException.

5. testExecute_ClassForName It seems the test class should be in bootclasspath to let this test work correctly. Since this didn't make much difference I replaced StatementTest.class with Statment.class (the last one will be in classpath for sure).

This was the final step in enabling of tests from StatementTest class. Now all tests pass both on RI and on our implementation. We can remove StatementTest from the exclude list.

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

[jira] Updated: (HARMONY-952) [classlib][beans] final clean up of StatementTest (6)

Posted by "Alexei Zakharov (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HARMONY-952?page=all ]

Alexei Zakharov updated HARMONY-952:
------------------------------------

    Attachment: StatementTest6.patch

> [classlib][beans] final clean up of StatementTest (6)
> -----------------------------------------------------
>
>                 Key: HARMONY-952
>                 URL: http://issues.apache.org/jira/browse/HARMONY-952
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: winXP
>            Reporter: Alexei Zakharov
>         Attachments: StatementTest6.patch
>
>
> Change log:
> 1. I've found that testExecute_OverloadedMethodsNull is an invalid test in fact, it checks ambiguous behaviour that depends on the order of elements 
> returned by Class.getMethods(). I have reworked it and renamed to testExecute_NormalInstanceMethodNull
> 2. The same thing with testExecute_OverloadedConstructorsNull. Was renamed to testExecute_NormalConstructorNull.
> 3. Again the same for testExecute_EqualSpecificMethods testExecute_EqualSpecificMethodsException. Fail on RI. In this case the only purpose of these tests is to check this odd implementation-specific behavior of java.lang.Class. IMHO these tests should be removed.
> 4. testExecute_IntMethodNullParameter fails on RI also, was corrected. NoSuchMethodException should be thrown in this case rather than NullPointerException.
> 5. testExecute_ClassForName It seems the test class should be in bootclasspath to let this test work correctly. Since this didn't make much difference I replaced StatementTest.class with Statment.class (the last one will be in classpath for sure).
> This was the final step in enabling of tests from StatementTest class. Now all tests pass both on RI and on our implementation. We can remove StatementTest from the exclude list.

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

[jira] Commented: (HARMONY-952) [classlib][beans] final clean up of StatementTest (6)

Posted by "Alexei Zakharov (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/HARMONY-952?page=comments#action_12423005 ] 
            
Alexei Zakharov commented on HARMONY-952:
-----------------------------------------

Everything is ok, thanks!

> [classlib][beans] final clean up of StatementTest (6)
> -----------------------------------------------------
>
>                 Key: HARMONY-952
>                 URL: http://issues.apache.org/jira/browse/HARMONY-952
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: winXP
>            Reporter: Alexei Zakharov
>         Assigned To: Mikhail Loenko
>         Attachments: StatementTest6.patch
>
>
> Change log:
> 1. I've found that testExecute_OverloadedMethodsNull is an invalid test in fact, it checks ambiguous behaviour that depends on the order of elements 
> returned by Class.getMethods(). I have reworked it and renamed to testExecute_NormalInstanceMethodNull
> 2. The same thing with testExecute_OverloadedConstructorsNull. Was renamed to testExecute_NormalConstructorNull.
> 3. Again the same for testExecute_EqualSpecificMethods testExecute_EqualSpecificMethodsException. Fail on RI. In this case the only purpose of these tests is to check this odd implementation-specific behavior of java.lang.Class. IMHO these tests should be removed.
> 4. testExecute_IntMethodNullParameter fails on RI also, was corrected. NoSuchMethodException should be thrown in this case rather than NullPointerException.
> 5. testExecute_ClassForName It seems the test class should be in bootclasspath to let this test work correctly. Since this didn't make much difference I replaced StatementTest.class with Statment.class (the last one will be in classpath for sure).
> This was the final step in enabling of tests from StatementTest class. Now all tests pass both on RI and on our implementation. We can remove StatementTest from the exclude list.

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

[jira] Assigned: (HARMONY-952) [classlib][beans] final clean up of StatementTest (6)

Posted by "Mikhail Loenko (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HARMONY-952?page=all ]

Mikhail Loenko reassigned HARMONY-952:
--------------------------------------

    Assignee: Mikhail Loenko

> [classlib][beans] final clean up of StatementTest (6)
> -----------------------------------------------------
>
>                 Key: HARMONY-952
>                 URL: http://issues.apache.org/jira/browse/HARMONY-952
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: winXP
>            Reporter: Alexei Zakharov
>         Assigned To: Mikhail Loenko
>         Attachments: StatementTest6.patch
>
>
> Change log:
> 1. I've found that testExecute_OverloadedMethodsNull is an invalid test in fact, it checks ambiguous behaviour that depends on the order of elements 
> returned by Class.getMethods(). I have reworked it and renamed to testExecute_NormalInstanceMethodNull
> 2. The same thing with testExecute_OverloadedConstructorsNull. Was renamed to testExecute_NormalConstructorNull.
> 3. Again the same for testExecute_EqualSpecificMethods testExecute_EqualSpecificMethodsException. Fail on RI. In this case the only purpose of these tests is to check this odd implementation-specific behavior of java.lang.Class. IMHO these tests should be removed.
> 4. testExecute_IntMethodNullParameter fails on RI also, was corrected. NoSuchMethodException should be thrown in this case rather than NullPointerException.
> 5. testExecute_ClassForName It seems the test class should be in bootclasspath to let this test work correctly. Since this didn't make much difference I replaced StatementTest.class with Statment.class (the last one will be in classpath for sure).
> This was the final step in enabling of tests from StatementTest class. Now all tests pass both on RI and on our implementation. We can remove StatementTest from the exclude list.

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

[jira] Resolved: (HARMONY-952) [classlib][beans] final clean up of StatementTest (6)

Posted by "Mikhail Loenko (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HARMONY-952?page=all ]

Mikhail Loenko resolved HARMONY-952.
------------------------------------

    Resolution: Fixed

fixed in revision 424952
Alexei please check that it fully resolves the issue

> [classlib][beans] final clean up of StatementTest (6)
> -----------------------------------------------------
>
>                 Key: HARMONY-952
>                 URL: http://issues.apache.org/jira/browse/HARMONY-952
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: winXP
>            Reporter: Alexei Zakharov
>         Assigned To: Mikhail Loenko
>         Attachments: StatementTest6.patch
>
>
> Change log:
> 1. I've found that testExecute_OverloadedMethodsNull is an invalid test in fact, it checks ambiguous behaviour that depends on the order of elements 
> returned by Class.getMethods(). I have reworked it and renamed to testExecute_NormalInstanceMethodNull
> 2. The same thing with testExecute_OverloadedConstructorsNull. Was renamed to testExecute_NormalConstructorNull.
> 3. Again the same for testExecute_EqualSpecificMethods testExecute_EqualSpecificMethodsException. Fail on RI. In this case the only purpose of these tests is to check this odd implementation-specific behavior of java.lang.Class. IMHO these tests should be removed.
> 4. testExecute_IntMethodNullParameter fails on RI also, was corrected. NoSuchMethodException should be thrown in this case rather than NullPointerException.
> 5. testExecute_ClassForName It seems the test class should be in bootclasspath to let this test work correctly. Since this didn't make much difference I replaced StatementTest.class with Statment.class (the last one will be in classpath for sure).
> This was the final step in enabling of tests from StatementTest class. Now all tests pass both on RI and on our implementation. We can remove StatementTest from the exclude list.

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

[jira] Closed: (HARMONY-952) [classlib][beans] final clean up of StatementTest (6)

Posted by "Mikhail Loenko (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HARMONY-952?page=all ]

Mikhail Loenko closed HARMONY-952.
----------------------------------


verified

> [classlib][beans] final clean up of StatementTest (6)
> -----------------------------------------------------
>
>                 Key: HARMONY-952
>                 URL: http://issues.apache.org/jira/browse/HARMONY-952
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: winXP
>            Reporter: Alexei Zakharov
>         Assigned To: Mikhail Loenko
>         Attachments: StatementTest6.patch
>
>
> Change log:
> 1. I've found that testExecute_OverloadedMethodsNull is an invalid test in fact, it checks ambiguous behaviour that depends on the order of elements 
> returned by Class.getMethods(). I have reworked it and renamed to testExecute_NormalInstanceMethodNull
> 2. The same thing with testExecute_OverloadedConstructorsNull. Was renamed to testExecute_NormalConstructorNull.
> 3. Again the same for testExecute_EqualSpecificMethods testExecute_EqualSpecificMethodsException. Fail on RI. In this case the only purpose of these tests is to check this odd implementation-specific behavior of java.lang.Class. IMHO these tests should be removed.
> 4. testExecute_IntMethodNullParameter fails on RI also, was corrected. NoSuchMethodException should be thrown in this case rather than NullPointerException.
> 5. testExecute_ClassForName It seems the test class should be in bootclasspath to let this test work correctly. Since this didn't make much difference I replaced StatementTest.class with Statment.class (the last one will be in classpath for sure).
> This was the final step in enabling of tests from StatementTest class. Now all tests pass both on RI and on our implementation. We can remove StatementTest from the exclude list.

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