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

Eric McCorkle eric.mccorkle at oracle.com
Fri Sep 13 18:54:26 UTC 2013

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

I also just created this one:

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