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

[Joe Darcy]

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>