Community
Participate
Working Groups
Build Identifier: 20100917-0705 When I compile a class with Eclipse, it includes the complete source into the class file with all whitespaces and comments. When the class is decompiled you'll get the complete source code with all comments, whitespaces, variable names and everything else. This is too simple for thiefs. And it is not smart as for the resulting class/jar size. I would like to see an option to strip the source on the fly before encoded to the class file (remove all whitespaces except for new-lines and remove all comments). Only linefeeds (no carriage returns) need to be preserved to keep stack traces intact. Additionally it would be great to have two more options: 1) to obfuscate the code slightly by renaming all local variable names to single letter names and 2) to do the same to private fields. This also saves a little disc space and makes it a little harder to understand decompiled code. I guess, this is all, you can do to obfuscate the code while keeping stack traces intact. And this only uses out-of-the-box eclipse featuers like refactoring of local variable names and removing white spaces (code formatter). If there are smarter and more advanced ways to obfuscate the code on the fly, they should also be included in Eclipse and be selectable. But the above few options really should be in there. Reproducible: Always
(In reply to comment #0) > Build Identifier: 20100917-0705 > > When I compile a class with Eclipse, it includes the complete source into the > class file with all whitespaces and comments. No, it doesn't. :) Whitespace and comments are never stored in .class files. If you see the original whitespace and comments you are not looking at a .class file. If you did click on a .class file the IDE obviously knew where to find the source file and presented that instead (via "source attachment" in the build path configuration). > Additionally it would be great to have two more options: 1) to obfuscate the > code slightly by renaming all local variable names to single letter names and > 2) to do the same to private fields. This also saves a little disc space and > makes it a little harder to understand decompiled code. Obfuscation must be done as a post-processing step, the incremental compiler needs un-obfuscated .class files to work efficiently. Therefor, I recommend to use an existing standalone tool for that. I don't see any benefits (but obvious difficulties) if this would be integrated in the JDT/Core. Am I missing anything?
I am sure, that I once decompiled one of my classes and was shocked, that it contained everything. Now this seems to have changed indeed. I used cavaj to decompile a class and the non-empty lines were indented. I guess, cavaj did that. So whitespaces are indeed eliminated as well as comments. So far so good. Wouldn't it be a great feature, if the jar exporter would provide a combo box with three options? These were NO_OBFUSCATION, LIGHT_OBFUSCATION, FULL_OBFUSCATION and they you work as described above. This way the incremental compiler could work efficiently and when rolling out your source as a jar you could use obfuscation to make the lives of thieves harder. I think, this would be a great eclipse feature and - depending on the quality of the obfuscation - would put Java more into place as a language of choice for commercial software. Maybe it would also be nice, if eclipse would provide an interface to plug in an arbitrary obfuscator, so that this functionality doesn't need to be done by the eclipse team.
