Compress class size

General Discussions
#1

Hey Gurus,

if I compile my code, the byte code size seems to depend on the source code. So if I add more whitespaces for readability, the resulting byte code will become bigger. It is also possible to fully decompile the java byte code and get back the fully formatted java source code with all whitespaces, comments and variable names. This doesn’t seem necessary to me. The only reason, why this could be needed, is, that in case an exception is thrown, the line numbers might be derived from the embedded source code.

Apart from the byte code size, which is pretty serious and important in some cases another issue is, that anyone can see my source code when using a freely available decompiler. Well, this might be illegal, but still possible. And if I don’t write open source software from time to time, I would like to better protect my code.

So my question is, is there a compiler flag to remove all unnecessary whitespaces and comments and to anonymize variable names, so that decompiled code is less useful? And can I set this compiler flag in Eclipse?

Thanks in advance,
Marvin

#2

Whitespace and comments are not included in the bytecode. Line number meta data is included by default to help debugging, but this can be turned off by passing -g:none to the compiler.

To automatically scramble class and member names, you need a tool called an obfuscator. ProGuard is a popular one, but there are others. Obfuscating will not help protect your code.

#3

what you can do though, is convert it to an EXE, this would make you unable to use applet, but it would make it more secure(I think…)

#4

It would also eliminate all platform independency :(.

Marvin

#5

In the eclipse preference tree there’s three checkboxes in /Java/Compiler that control javac’s “-g” option

#6

Ok, thanks for your answers. So there doesn’t seem to be an option to remove all leading or trailing or nested-double whitespaces from each line, right?

I double-checked and comments don’t indeed survive the compiler.

Marvin

#7

As said, if you simple add “-g:none” to javac there will be no sourcecode (nor whitespace, nor anything else source related) in the classfile.

A decompiler might/will add it’s own whitespace for readability if it cannot find the sourcecode-meta-data in the classfile.

#8

If it’s natively compiled to an exe (like with ExcelsiorJet or GCJ) then it should be extremely difficult to get back the original Java source code.

However with tools like JSmooth I’d guess that they just store your bytecode in the created exe (since they don’t change your app, they just make it look like an exe). If you knew the position of the bytecode in the exe then it’d be trivial to retrieve and then you can use any of the many Java decompilers to get the original source code back.

#9

Those launchers are extremely simple:

  1. take the bytes of a process kicker application (C app that calls exec)
  2. take the bytes of the JAR
  3. concatenate into new exe file

done. it simply works.

to ‘extract’ the JAR from the exe, you only have to look for the ZIP header (blatantly assuming those 4 bytes do not occur in the original kicker)

#10

If you’re super paranoid you can use molebox which is an exe packer with some fancy encryption mechanisms. I believe Cas was using it because it also compresses very well.