Ben, If you would like this as a new feature, please write it up as a Sourceforge request. I can try to take a look at it... Of course, patches are always welcome.
Craig Ben Hutchison wrote: > Recently Ive spent some time diagnosing an Preverify error I get when I > use EclipseME to create a packaged obfuscated build. > > "Errors preverifying jarError preverifying class o > VERIFIER ERROR o.a(I)V: > Incompatible argument to function" > > This is coming out of Suns WTK 2.5 preverify tool. Its complaining about > a method of obfuscated class o with signature void a(int). I *guess* > "Incompatible argument to function" means that parameter int is > incompatible, probably with its superclass declaration? The Preverify > error should be more precise about why it thinks the parameter is > "incompatible" - can anyone clarify what this error means, or how to get > more verbose output from Preverify? > > On investigation, the bug looks like its inside the WTK preverify tool, > not Proguard. I tried re-arranging the method ordering within the > classes source code, and the problem went away. But I then examined the > obfuscated classfiles with/without the error, and the resultant names & > signature is identical in both cases, and apparently valid, including > the whole superype hierarchy. So it appears to be its position in the > classfile, not its name or signature, that is triggerring the error. > Thus, smells like a preverify bug. > > Someone else had a similar expereince: > http://www.j2meforums.com/forum/index.php?topic=8139;prev_next=next > > So, losing confidence in Sun's Preverify, I started looking at > alternative preverifiers. > > First I tried the EclipseME internal preverify, but got an error. It > does something that I think it ought not to: calling Class.forName() to > load classes that its verifying. This will runs the static initializers > of classes under verification. Net result, a tool in the compiler > pipeline ends up running arbitrary parts of the application during > compile. Why shouldn't you do this? Well, preverify this class... oops! ;) > > class DontLoadMeUnlessThingsAreDire { > static { > deleteContentsOfHardDrive(); > } > static void deleteContentsOfHardDrive() {....} > } > > Over the top example, I admit. A more real world case: when preverifying > my own classes, EclipseME is getting NPEs inside application static > initalizers, because my classes are designed to be loaded in a certain > order (which I doubt EclipseME's verifier knows about) to prevent > circular reference problems. > > Although loading classes in the most convenient way to access the type's > data, I think the right way to do it is through static analysis of the > classfile, using perhaps eg CGLib? > > There is a third Preverify option: new releases of Proguard allow you to > combine preverification with obfuscation (new -microedition flag). I > turned that on, and the Proguard stage seemed to complete ok. However, > EclipseME still tried to run the SunWTK preverify after, which results > in the orignal error. > > So, a feature request please: can we have the ability in EclipseME to > delegate preverify to the obfuscator, and not try to separately > preverify afterwards? > > Regards > Ben > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Eclipseme-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/eclipseme-users
