JCK1.4: api/java_beans/Statement/index.html#execute

JDK : JDK1.4.0-rc-b89
JCK : JCK1.4-b14
Platform[s] : RedHat Linux 7.1, RedHat Linux 6.2
                (The test passes under Windows OS)
switch/Mode : -client -Xmixed -Xfuture
JCK test owner : http://javaweb.eng/jck/usr/owners.jto
Failing Test : api/java_beans/Statement/index.html#execute [Statement2012, Statement2021]

JavaTM 2 Platform Std. Ed. v1.4.0 Specification reads about java.beans.Statement.execute() method:
...
The execute method finds a method whose name is the same as the methodName property, and invokes the method on the
      target. When the target's class defines many methods with the given name the implementation should choose the most
      specific method using the algorithm specified in the Java Language Specification (15.11). The dynamic class of the
      target and arguments are used in place of the compile-time type information and, like the java.lang.reflect.Method
      class itself, conversion between primitive values and their associated wrapper classes is handled internally.
...


JavaTM Language Specification reads:
...
If more than one method declaration is both accessible and applicable to a method invocation, it is necessary to choose
one to provide the descriptor for the run-time method dispatch. The Java programming language uses the rule that the most
specific method is chosen.

The informal intuition is that one method declaration is more specific than another if any invocation handled by the first
method could be passed on to the other one without a compile-time type error.

The precise definition is as follows. Let m be a name and suppose that there are two declarations of methods named m,
each having n parameters. Suppose that one declaration appears within a class or interface T and that the types of the
parameters are T1, . . . , Tn; suppose moreover that the other declaration appears within a class or interface U and that
the types of the parameters are U1, . . . , Un. Then the method m declared in T is more specific than the method m declared
in U if and only if both of the following are true:

      T can be converted to U by method invocation conversion.
      Tj can be converted to Uj by method invocation conversion, for all j from 1 to n.

A method is said to be maximally specific for a method invocation if it is applicable and accessible and there is no other
applicable and accessible method that is more specific.
...

The following test example demonstrates incorrect Statement.execute() method behavior.

----------- test.java -------------
import java.beans.*;

public class test {
    public static void main(String argv[]) {
        DummyClass target = new DummyClass();
        Object[] arguments = {target};
        Statement statement = new Statement(target, "aMethod", arguments);
        try { statement.execute(); } catch (Exception e) { e.printStackTrace(); }
    }
}
--------- DummyClass.java ---------
class DummySuperClass {};

public class DummyClass extends DummySuperClass {
    public void aMethod(DummySuperClass obj) {
        System.out.println("Test failed: DummySuperClass");
    }
    public void aMethod(DummyClass obj) {
        System.out.println("Test passed: DummyClass");
    }
}
-----------------------------------

DummyClass class contains two methods named "aMethod". The most specific method for the statement
in test.java is aMethod(DummyClass obj) because DummyClass can be converted to DummySuperClass by
method invocation conversion.

But under RedHat Linux 7.1 statement.execute() invokes method aMethod(DummySuperClass obj).
Sample output is:

...
$ java test
Test failed: DummySuperClass
...

Please, note that under Windows OS the test passes. Sample output is:

...
$ java test
Test passed: DummyClass
...

JCK1.4-b14 test api/java_beans/Statement/index.html#execute (testcases Statement2012, Statement2021) fails
due to this reason.

Test source location:
=====================
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_beans/Statement/executeTests.java
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_beans/Statement/P.java
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_beans/Statement/Q.java
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_beans/Statement/DummyClass.java
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_beans/Statement/DummySuperClass.java
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_beans/Statement/WrapNumber.java

jtr file location:
==================
/net/jtgb4u4c.eng/export/sail15/results/merlin/b89/jck14/linux/redhat7.1_kde2_client_linux-13/workDir/api/java_beans/Statement/index_execute.jtr

How to reproduce:
====================
Run the following script under RedHat Linux 7.1
(probably, you need to change JCK and JAVA_HOME paths):
--------Script START---------------------
#!/bin/sh
JAVA_HOME=/net/jdk/export/disk8/local.java/jdk1.4/linux-i386
JCK=/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14
export CLASSPATH="$JCK/classes:$JCK/javatest.jar"
executeClass="javasoft.sqe.tests.api.java.beans.Statement.executeTests -TestCaseID Statement2012 Statement2021"
$JAVA_HOME/bin/java -Xfuture ${executeClass}
---------Script END----------------------

Test output:
=============
Statement2012: Failed. Statement2012 failed
Statement2021: Failed. Statement2021 failed
====== Statement2012 ======
Target: javasoft.sqe.tests.api.java.beans.Statement.DummyClass@ab95e6
Result: null
====== Statement2021 ======
Target: javasoft.sqe.tests.api.java.beans.Statement.DummyClass@fe64b9
Result: null
STATUS:Failed.tests: 2; failed: 2; first test case failure: Statement2012
Test failed

Specific Machine Info:
=====================
Hostname: Linux-13
OS: RedHat Linux 7.1