<Beans Dev> [9] Review Request: 8146313 The java.beans.Statement.invoke() method handles 3-arg Class.forName incorrectly

Semyon Sadetsky semyon.sadetsky at oracle.com
Wed Apr 27 07:12:50 UTC 2016

On 4/26/2016 3:10 PM, Sergey Bylokhov wrote:
> On 26.04.16 10:01, Semyon Sadetsky wrote:
>> On 4/25/2016 10:14 PM, Sergey Bylokhov wrote:
>>> On 25.04.16 21:44, Semyon Sadetsky wrote:
>>>> Could you add primitive class case to the test?
>>> No, the test compares behavior of Statement and Class.forName() and
>>> checks that they works similarly(returns exactly the same classes),
>>> but the latter does not support primitive types(this is supported by
>>> the extension of Statement which calls single-args Class.forName()) so
>>> we cannot compare results of such calls.
>> I did not ask to compare with the Class.forName(). In your change the
>> primitive types handled differently in case 3-args forName() in
>> comparison with the 1-arg. So that, this test case is required to prove
>> that the method can work with primitive types in the proposed way. Or
>> you meant that it must not work with primitives?
> Yes it does not work for primitives, it not treated as some special 
> method(like 1-args), it call 3-args Class.forName(which do not support 
> the primitives) directly like any other methods.
What will happen if the 3-args is called with a primitive?

>> --Semyon
>>>> On 4/22/2016 7:20 PM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk9(the fix was discussed offline 
>>>>> already).
>>>>> The Statement class can execute the methods and pass some parameters
>>>>> for them. It can be used to store the statement(method 
>>>>> call+parameter)
>>>>> in xml and load it when necessary. This class has special case for
>>>>> Class.forName() because it provides some additional features(for
>>>>> example it uses a different class loaders and supports primitive
>>>>> types). But it does not take into account that there is the second
>>>>> 3-args forName() method. It was fixed in the change.
>>>>> 3-args forName() method is considered as a usual method which will be
>>>>> executed for provided class+classloadder. The additional check for
>>>>> package access is added. Note that I added a code to always clone the
>>>>> list of arguments just as an additional safeness for the future
>>>>> changes.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146313
>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8146313/webrev.03

More information about the beans-dev mailing list