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