JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions
joel.franck at oracle.com
Fri Sep 13 14:55:08 UTC 2013
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.
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.
>> 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:
>>>> 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:
>>>> The webrev is here:
>>>> This review is also on crucible. The ID is CR-JDK8TL-182.
More information about the core-libs-dev