This will give you the command line options. More help is available when using the -gui option.

Improvements since last version:

- should now be 1.5/1.6 complient- now using proguard 4.1- jshrink now works with the tool. (well mostly... jshrink does not seem able to correctly process alrealy obfucated/optimised jars and thus is only able to be uses as a first step... this is handeled automatically)- added Marvin Obsfucator- added Retroguard Obsfucator- removed JavaGuard as it seems unable to process java 1.5+- changed default configuration.- now using kzip instead of java's zip for intermediate steps

These changes should theoretically improve the compression ratio as compared to the previous version.

lol! i suggest creating a script for each optimiser individually to see if you can identify which optimiser is being too aggressive. once/if you have identified it then create a script which is based on the default script minus the offending optimiser

Is the ship data directly injected into the byte code? i believe all optimisers remove the such data. I do have a undocumented -data option which does inject the data back into the optimised jar.

It seems the JOGA does not like your class at all and gives an error when optimising (that is handled by the tool) however the JODE optimiser seems to be the culprit and aggressively optimises some portions of your code completely away! I unchecked it from the list of optimisers and was able to save 108 bytes (from 4091 to 3983)

ah,sorry about that. we cancelled that web host... I have uploaded it to the public ftp related to java 4k entries hosted by Woogley. If he objects then i will have to host by the atrocity which is free file hosting

I gave the optimiser a quick go. It has a couple of problems ATM. I'm afraid I haven't spent more than about 10 mins on it so far to try to fix them...

1. There are a lot of errors from the optimisers. Looks like most of them don't like the class file. I'm compiling with Java 6, but with -target 1.5 -source 1.5 (at least I think I'm using those options... I should check really )2. I need to inject a bitmap back into the class file before the compression stage. You mention above that you have an undocumented -data option to do this? Could you explain how please.

1. There are a lot of errors from the optimisers. Looks like most of them don't like the class file. I'm compiling with Java 6, but with -target 1.5 -source 1.5 (at least I think I'm using those options... I should check really )

Well, if the optimisers generate exceptions, they are skipped... so you will still have a valid output JAR at the end. With some classes, one of the optimisers might be a little too aggressive and actually optimise sections of your code away. In that case the only real option is to remove the offending optimiser from the list of of optimisers using the -gui command line option.

Quote

2. I need to inject a bitmap back into the class file before the compression stage. You mention above that you have an undocumented -data option to do this? Could you explain how please.

there is a -addData <file> option which will inject the contents of the file directly into the final best optimised class just before the JAR creation step.

I assume you have code in your class which reads in the class itself as input and searches for a unique byte string which indicates the start of the your embedded data? If not then you must do so as it is indeterminable to know what byte offset your data will start at.

I've just come across another way to insert binary data into the class file. Just define a string and use octal escapes for the characters. For example:

"\000\001\002\003"

represents the bytes 0 to 3. Then you can just do getBytes() on the String and get a byte array of the contents. Optimizers won't strip this String from the class file. There's a caveat however: String.getBytes() uses the platform encoding to turn the string into bytes. The platform encoding of (effectively) all platforms is ascii-safe, so you can use values 0 to 127 (inclusive).

Well, if the optimisers generate exceptions, they are skipped... so you will still have a valid output JAR at the end. With some classes, one of the optimisers might be a little too aggressive and actually optimise sections of your code away. In that case the only real option is to remove the offending optimiser from the list of of optimisers using the -gui command line option.

I've just come across another way to insert binary data into the class file. Just define a string and use octal escapes for the characters. For example:

"\000\001\002\003"

represents the bytes 0 to 3. Then you can just do getBytes() on the String and get a byte array of the contents. Optimizers won't strip this String from the class file. There's a caveat however: String.getBytes() uses the platform encoding to turn the string into bytes. The platform encoding of (effectively) all platforms is ascii-safe, so you can use values 0 to 127 (inclusive).

Also be aware that Java uses a modified UTF8 format, one difference being that the char '\000' is encoded using 2 bytes rather than 1.This coupled with the additional code necessary for converting these 7bit bytes into a more conventional form means that storing binary data as a seperate Attribute within the class file is generally more efficient.

Yes, this is pretty much expected as it is optimising for deployment as a Webstartable JAR... simply load the JAR in a zip utility such as winRAR or 7zip and add your manifest if you want to make it a self executing JAR.

I have found that adding a manifest does eat up much of the bytes gained from the optimisation.

if i remember correctly there is a flaw in one or more of the optimisers used that they do not accept spaces in the file/path of the input and output jars... perhaps this is the problem? if you want you can send me the jar you are trying to optimise to see if your jar is some how unique and breaking the tool.

if i remember correctly there is a flaw in one or more of the optimisers used that they do not accept spaces in the file/path of the input and output jars... perhaps this is the problem? if you want you can send me the jar you are trying to optimise to see if your jar is some how unique and breaking the tool.

Ah, that must be it. On my system it uses backslash space to denote spaces in file paths, while I noticed causes problems before. The file is in the "Random Code" folder which becomes "Random\ Code". I'll have a looksee if that works.

Well, if the optimisers generate exceptions, they are skipped... so you will still have a valid output JAR at the end. With some classes, one of the optimisers might be a little too aggressive and actually optimise sections of your code away. In that case the only real option is to remove the offending optimiser from the list of of optimisers using the -gui command line option.

So just when I thought I was finished I seem to have hit this problem. Something in the processing is optimising out this whole loop:

For some reason something was stripping out any loop with a float control value. Switching over to using an int control value and calculating the angle from it seems to have fixed it (and pushed my size up by a whopping 400b ).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org