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 -- Ben Hutchison Lead Developer Playscape Games http://www.playscapegames.com ------------------------------------------------------------------------- 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
