Nope, not at all. I find it simply too much work for a rather meager return. I know Abuse was big on disassembling and reassembing his code to get those sorts of gains, but I could never quite get into that. I’d much rather develop a technology to do it for me. 
However, I do usually run a program like JoGa that not only strips out unnecesary info, but reduces necessary info to as little space as possible.
There is nothing to it. Just change the code so that the class file changes. That in turn can make a difference when the class is zipped. You want to produce a class files with as many repeating patterns as possible. Just randomly changing the code will usually save you a couple of bytes. Intentionaly creating code that compresses better is fairly difficult to get right.
i’ve run a few tests and found that Proguard to be much better at saving space that JoGa
Original : 5427 bytes
JoGa: 3906 bytes
ProGuard: 3840 bytes
ProGuard and JoGa: 3839 bytes
[quote=“kapta,post:143,topic:25185”]
When you get a chance, try running JoGa twice on your code. I know it seems odd, but I’ve actually saved more space that way. I’ve never seen it work a third time, though. :-\
I just tried that. Didn’t work for me 
retest results
Original : 5427 bytes
JoGa: 3906 bytes
JoGa2: 3906 bytes
ProGuard2: 3847
ProGuard: 3840 bytes
JoGa and then ProGuard: 3839 bytes
ProGuard and then JoGa: 3792 bytes
Did you also remove the zip message that ProGuard inserts into the archive?
I’ve found an interesting quirk in Proguard. The optimisation option in Proguard 3.4 shrinks the file more than that of Proguard 3.2 and was great under Java 1.5. However the extra optimisation hammered my framerate under 1.4.2. So, I’m still using Proguard 3.2 at the moment as I need the performance. Also, the latest version of 7zip isn’t any better than the version I had last spring w.r.t. standard zip files.
You might want to check kzip out, I find it gives better results than 7zip.
Kev