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. http://cr.openjdk.java.net/~emc/8020981/ 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.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> >
