JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions

Eric McCorkle eric.mccorkle at oracle.com
Thu Sep 19 22:15:36 UTC 2013


The webrev has been updated with Joe's comments addressed.

On 09/19/13 00:11, David Holmes wrote:
> On 19/09/2013 9:59 AM, Eric McCorkle wrote:
>> This still needs to be reviewed.
> 
> You seem to have ignored Joe's comments regarding the change to Modifier
> being incorrect.
> 
> David
> 
>> On 09/16/13 14:50, Eric McCorkle wrote:
>>> I pulled the class files into byte array constants, as a temporary
>>> measure until a viable method for testing bad class files is developed.
>>>
>>> The webrev has been refreshed.  The class files will be taken out before
>>> I push.
>>>
>>> http://cr.openjdk.java.net/~emc/8020981/
>>>
>>> On 09/13/13 20:48, Joe Darcy wrote:
>>>> To avoid storing binaries in Hg, you could try something like:
>>>>
>>>> * uuencode / ascii armor the class file
>>>> * convert to byte array in the test
>>>> * load classes from byte array
>>>>
>>>> -Joe
>>>>
>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote:
>>>>> I did it by hand with emacs.
>>>>>
>>>>> I would really rather tackle the bad class files for testing issue
>>>>> once
>>>>> and for all, the Right Way (tm).  But with ZBB looming, now is not the
>>>>> time to do it.
>>>>>
>>>>> Hence, I have created this task
>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674
>>>>>
>>>>> I also just created this one:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812
>>>>>
>>>>> On 09/13/13 13:54, Peter Levart wrote:
>>>>>> Hi Eric,
>>>>>>
>>>>>> How did you create those class files? By hand using a HEX editor? Did
>>>>>> you create a program that patched the original class file? If the
>>>>>> later
>>>>>> is the case, you could pack that patching logic inside a custom
>>>>>> ClassLoader...
>>>>>>
>>>>>> To hacky? Dependent on future changes of javac? At least the "bad
>>>>>> name"
>>>>>> patching could be performed trivially and reliably, I think:
>>>>>> search and
>>>>>> replace with same-length string.
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>>>>>>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>>>>>>
>>>>>>> I have already filed a task for test development post ZBB to
>>>>>>> develop a
>>>>>>> solution for generating bad class files.  I'd prefer to file a
>>>>>>> follow-up
>>>>>>> to this to add the bad class file tests when that's done.
>>>>>>>
>>>>>>> On 09/13/13 10:55, Joel Borggrén-Franck wrote:
>>>>>>>> I think the right thing to do is to include the original compiling
>>>>>>>> source in a comment, together with a comment on how you modify
>>>>>>>> them, and then the result as a byte array.
>>>>>>>>
>>>>>>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>>>>>>
>>>>>>>> cheers
>>>>>>>> /Joel
>>>>>>>>
>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle
>>>>>>>> <eric.mccorkle at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> There is no simple means of generating bad class files for
>>>>>>>>> testing.
>>>>>>>>> This is a huge deficiency in our testing abilities.
>>>>>>>>>
>>>>>>>>> If these class files shouldn't go in, then I'm left with no choice
>>>>>>>>> but
>>>>>>>>> to check in no test for this patch.
>>>>>>>>>
>>>>>>>>> However, anyone can run the test I've provided with the class
>>>>>>>>> files and
>>>>>>>>> see that it works.
>>>>>>>>>
>>>>>>>>> On 09/13/13 09:55, Joel Borggrén-Franck wrote:
>>>>>>>>>> Hi Eric,
>>>>>>>>>>
>>>>>>>>>> IIRC we don't check in classfiles into the repo.
>>>>>>>>>>
>>>>>>>>>> I'm not sure how we handle testing of broken class-files in jdk,
>>>>>>>>>> but ASM might be an option, or storing the class file as an
>>>>>>>>>> embedded byte array in the test.
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> /Joel
>>>>>>>>>>
>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle
>>>>>>>>>> <eric.mccorkle at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> A new webrev is posted (and crucible updated), which actually
>>>>>>>>>>> validates
>>>>>>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>>>>>>
>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review this patch, which implements correct behavior for
>>>>>>>>>>>> the
>>>>>>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>>>>>>
>>>>>>>>>>>> The bug report is here:
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>>>>>>
>>>>>>>>>>>> The webrev is here:
>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>>>>>>
>>>>>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Eric
>>>>>>>>>>>>
>>>>>>>>> <eric_mccorkle.vcf>
>>>>


More information about the core-libs-dev mailing list