It just gives a list of method names, and the offset to any return instructions - the last one of which will be the last instruction in the method, so gives you a fair indication of the method size. (It doesn't take account of exception tables, but it's a reasonably good guide to which methods are huge.)
javap extracts a variety of data from java class files. You can get an overview of the options with javap -help. To use with many MIDlet classes, you may have to add in a reference to the MIDP API classes. That would be something like:
and so on. findstr is the NT equivalent of Unix's grep. I've given two patterns: ^Method - which pulls out any line starting with the text "Method"; and return$ - which pulls out any line ending with the text "return". (The ^ matches the start of a line, $ matches the end). findstr is case-sensitive. So:
Since the numbers listed are the offsets (in bytes) to the instruction, and the last instruction in each method is always a return (unless anyone knows otherwise!), this gives you some idea of the size of the method code. (There are sometimes multiple "return"s in a method, but the last one is still the last instruction).
It doesn't tell the whole story. In my tests, I find that a method with a single character name, no parameters and no code (the compiler will still generate a return instruction) increases the size of a class file by 33 bytes. And javap does not list constant-pool entries - it is difficult to include these in method size evaluations, as they are often shared between methods (where two methods include the same String constant, or invoke the same external method, for example).