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.mccor...@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.mccor...@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>
