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

Peter Levart peter.levart at gmail.com
Fri Sep 13 17:54:30 UTC 2013

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 

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