Skip to main content

Obfuscating rt.jar

5 replies [Last post]
sat1196
Offline
Joined: 2003-11-08
Points: 0

Hi,
I just read the forum about adding debug infos into rt.jar. While it might make sense in the developer jre. It would certainly be useless for the average user. Similarly, wouldn't it be interesting to obfuscate rt.jar. Thus shortening the class/method/field names and reducing size both on disk and in memory and maybe increasing performance. Is it a good idea? Has it been tried before?

Greetings

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
alexlamsl
Offline
Joined: 2004-09-02
Points: 0

I think LZW would have done a good enough job in compressing the files that size gained by obfuscation would not be significant.

mthornton
Offline
Joined: 2003-06-10
Points: 0

While it would be possible to obfuscate just the internal classes and methods (e.g. stuff in the com.sun.* heirarchy), it would also make stack traces in bug reports less useful or more tedious to understand.
A better idea would be to find a way of obtaining line number information (for those stack traces) without paying a memory penalty until (if) a stacktrace was actually requested.

javakiddy
Offline
Joined: 2004-01-23
Points: 0

If memory serves, the line numbers are provided by just a straight forward table which denotes which range of bytecodes within a method maps to which line in the source file (...?)

If the bytecode position of the failure was reported, it could be looked up in some external line numbers file (created by the compiler), perhaps by a tool which took an exception stack trace and the line numbers file corresponding to the code being run...?

Just an idea.

jwenting
Offline
Joined: 2003-12-02
Points: 0

wow, obfuscating the entire runtime library.

Very good idea indeed, would certainly reduce the size of the language by a good chunk :)

s690716
Offline
Joined: 2004-03-04
Points: 0

And then your software is calling obfuscated methods? A new definition of "hard coding"... ;-)