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

Eric McCorkle eric.mccorkle at oracle.com
Mon Sep 16 18:50:33 UTC 2013

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.


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