For Proguard, it is the basic config file… it do it itself 
I was wondering if the service and/or applet will be available in the next few days?
I’ve assembled the compressor tool chain that I use into an easy-to-use bundle:
http://groboclown.net/games/4kgames-build-framework-1.0.zip
Run ant in the base unzipped directory to setup your environment (download jars and make sure properties are setup right).
Then, modify the “sample-game” directory structure to include your source Java file in the “src” sub-directory, and setup the project.properties file. Then, you can run “ant” from in that directory to build all the jar files, which are output into the work/jars directory.
It takes a long time to run, because it performs many iterations over different combinations of class file shrinking and compression.
You can also test the applet with the “ant test” command.
Thank you very much for the utility package. Much appreciated.
Suit yourself.
I don’t think it is down, just merely rejecting all connections since I get an error 324 (empty response)
I for one would really appreciate the applet version.
Cheers,
Kev
I seem to be having the same problem around here.
I second what kev said. We’re all loving your service so much that we’ve grown accustomed to it, Riven. We’re looking forward to the applet version 
Starting with a log from 2011/11/28, I tried to find out which processes were undertaken by Riven’s incomparable
Compile and shrink service, that most of us miss. What I found may be interesting.
First of all, I should indicate the configuration of my computer :
Windows 7 Home Premium - Service Pack 1
Java™ SE development Kit 6 Update 29 ( Windows x86 )
Proguard 4.6
Kzip compiled on 2007/04/14 ( latest release for what I know )
Kzip was the only archiver I used for this test.
And here is the log generated by Riven’s tool on 2011/11/28 :
a.java => 24352 bytes
a.class => 9625 bytes
a.normal.java6.jar => 5194 bytes
a.normal.java6.pack => 7978 bytes
a.progrd.java6.jar => 5104 bytes
a.progrd.java6.pack => 7878 bytes
a.progrd.java6.kz.pack.gz => 4058 bytes
a.normal.java6.kz.pack.gz => 4078 bytes
a.progrd.java6.bj.pack.gz => 4086 bytes
a.progrd.java6.7z.pack.gz => 4280 bytes
a.normal.java6.7z.pack.gz => 4302 bytes
In the following lines, you will find the processes I set manually for the same source code as on 2011/11/28.
STEP 1 : JAVAC ( from java file )
Input file : a.java => 24352 bytes
Command line>javac -target 1.5 -g:none a.java
Output file : a.class => 9625 bytes ( C’n s: 9625 )
STEP 2 : JAR ( from step 1 class file )
Input file : a.class
Command line>jar cfM a.normal.java6.jar a.class
Output file : a.normal.java6.jar => 5199 bytes ( C’n s: 5194 )
STEP 3 : PACK200 ( from step 2 jar file )
Input file : a.normal.java6.jar
Command line>pack200 --effort=9 --strip-debug --no-keep-file-order -O --no-gzip a.normal.java6.pack a.normal.java6.jar
Output file : a.normal.java6.pack => 7978 bytes ( C’n s: 7978 )
For this step, the command was supplied by Bonbon-Chan.
STEP 4 : PROGUARD ( from step 2 jar file )
Launch proguardgui.bat from Windows.
*Page Input/Output
Input file : a.normal.java6.jar
Output file : a.progrd.java6.jar
*Page Shrinking
Options
X Shrinking
Keep
X Applets
Also keep
none
*Page Obfuscation
Options
X Obfuscate
X Overload aggressively
Keep names
none
*Page Optimization
Options
X Optimize
X Allow access modification
9 Optimisation passes
Remove
all
Remove debugging
all
*Page Information
default settings
*Page Process
hit Process!
Output file : a.progrd.java6.jar => 5104 bytes ( C’n s: 5104 )
STEP 5 : PACK200 ( from step 4 proguarded jar file )
Input file : a.progrd.java6.jar
Command line>pack200 --effort=9 --strip-debug --no-keep-file-order -O --no-gzip a.progrd.java6.pack a.progrd.java6.jar
Output file : a.progrd.java6.pack => 7878 bytes ( C’n s: 7878 )
STEP 6 : KZIP ( from step 5 proguarded and packed file )
Input file : a.progrd.java6.pack
Command line>kzip /b96 a.progrd.java6.kz.pack.gz a.progrd.java6.pack
Output file : a.progrd.java6.kz.pack.gz => 4177 bytes ( C’n s: 4058 )
For note, using the kzip default option /s0 ( Xtreme strategy ) gave worst results than /b96 with my file.
Kzip indicated that 4177 was the total size of the file, including headers. It also gave the mention “KSflating 4041”.
STEP 7 : KZIP ( from step 3 packed file )
Input file : a.normal.java6.pack
Command line>kzip /b96 a.normal.java6.kz.pack.gz a.normal.java6.jar
Output file : a.normal.java6.kz.pack.gz => 4197 bytes ( C’n s: 4078 )
Kzip indicated that 4197 was the total size of the file, including headers. It also gave the mention “KSflating 4061”.
Here is the comparison between Riven’s log and my own results :
a.java => 24352 bytes Riven / 24352 bytes StephR
a.class => 9625 bytes Riven / 9625 bytes StephR ( step 1 )
a.normal.java6.jar => 5194 bytes Riven / 5199 bytes StephR ( step 2 )
a.normal.java6.pack => 7978 bytes Riven / 7978 bytes StephR ( step 3 )
a.progrd.java6.jar => 5104 bytes Riven / 5104 bytes StephR ( step 4 )
a.progrd.java6.pack => 7878 bytes Riven / 7878 bytes StephR ( step 5 )
a.progrd.java6.kz.pack.gz => 4058 bytes Riven / 4177 bytes StephR ( step 6 )
a.normal.java6.kz.pack.gz => 4078 bytes Riven / 4197 bytes StephR ( step 7 )
a.progrd.java6.bj.pack.gz => 4086 bytes Riven / not evaluated
a.progrd.java6.7z.pack.gz => 4280 bytes Riven / not evaluated
a.normal.java6.7z.pack.gz => 4302 bytes Riven / not evaluated
CONCLUSION
It seems I misused Kzip, so I didn’t get as good compression results as Riven’s Compile and shrink service. Anyone could help to fix this ?
I can’t such good results either, maybe Riven has a ‘special’ kzip!
FWIW my build process goes;
javac -target 1.5 A.java
jar cvfM A.normal.jar A.class
java -jar jarg.jar A.normal.jar
java -jar proguard.jar -injars A.normal_s.jar -outjars A.proguard.jar -libraryjars rt.jar -keep public class A -optimizationpasses 9 -overloadaggressively
pack200 --effort=9 --strip-debug --no-keep-file-order -O --no-gzip A.proguard.pack A.proguard.jar
kzip /b96 /y A.proguard.pack.gz A.proguard.pack
This takes my assassin game from a 12059 byte class file to a 4069 byte pack.gz file.
Strange phenomenon: If I give kzip the output filename ‘A.pack.gz’ instead of ‘A.proguard.pack.gz’ the file size grows by 1 byte!?
For my version of the kzip execution, I set the “random seed” command-line argument, and loop through executing it several times, and choose the smallest one. Then, I loop through that bit, this time switching between different block sizes. It takes a while (say, 2 minutes), but it’s well worth the wait.
kzip /r /y /rn /s0 /b<block size> outfile.zip infiles
where is one of 0, 32, 64, 128, 256, 512, and 1024.
I additionally use JoGa after Proguard, it saves some bytes.
I tried a brute force approach for kzip (every possible combination of switches) and found that in all the cases I tried /b96 gave the best results.
Good call! I’d forgotten JoGa - that shaved off another 43 bytes!
But if you use KZip and just name the file .pack.gz its still a zip.
When I use unpack200, it just uses “copy-mode” and returns the same file.
Did you validate the result with unpack200 ?
You need to use a tool like this one to convert the zip file to a gz file:
http://www.java-gaming.org/index.php/topic,21630.msg177304.html#msg177304
Ok, cool. Will try that out
Finally, and thanks to the comments of Bonbon-Chan, Groboclown, Damocles, SimonH and Bainit, I have reconstructed a complete compression chain similar in results to Riven’s Compile and shrink service. Of course, unlike with this last, you have to do everything yourself !
To start, here are some informations about my operating system and the software I used :
Windows 7 Home Premium - Service Pack 1
Java™ SE development Kit 6 Update 29 ( Windows x86 )
Proguard 4.6
Kzip compiled on 2007/04/14 ( latest release for what I know )
Zip2Gzip ( pjt33’s awesome converter )
And here is the comparison between Compile and shrink’s log and my own results :
a.java => 24352 bytes C’n s / 24352 bytes StephR
a.class => 9625 bytes C’n s / 9625 bytes StephR
a.normal.java6.jar => 5194 bytes C’n s / 5199 bytes StephR
a.normal.java6.pack => 7978 bytes C’n s / 7978 bytes StephR
a.progrd.java6.jar => 5104 bytes C’n s / 5104 bytes StephR
a.progrd.java6.pack => 7878 bytes C’n s / 7878 bytes StephR
a.progrd.java6.kz.pack.gz => 4058 bytes C’n s / 4054 bytes StephR
a.normal.java6.kz.pack.gz => 4078 bytes C’n s / not evaluated
a.progrd.java6.bj.pack.gz => 4086 bytes C’n s / not evaluated
a.progrd.java6.7z.pack.gz => 4280 bytes C’n s / not evaluated
a.normal.java6.7z.pack.gz => 4302 bytes C’n s / not evaluated
In the following lines, you will find the processes for the complete compression chain :
STEP 1 : JAVAC ( from java file )
Input file : a.java => 24352 bytes
Command line>javac -target 1.5 -g:none a.java
Output file : a.class => 9625 bytes ( C’n s: 9625 )
STEP 2 : JAR
Input file : a.class
Command line>jar cfM a.normal.java6.jar a.class
Output file : a.normal.java6.jar => 5199 bytes ( C’n s: 5194 )
STEP 3: PROGUARD
Launch proguardgui.bat from Windows.
*Page Input/Output
Input file : a.normal.java6.jar
Output file : a.progrd.java6.jar
*Page Shrinking
Options
X Shrinking
Keep
X Applets
Also keep
none
*Page Obfuscation
Options
X Obfuscate
X Overload aggressively
Keep names
none
*Page Optimization
Options
X Optimize
X Allow access modification
9 Optimisation passes
Remove
all
Remove debugging
all
*Page Information
default settings
*Page Process
hit Process!
Output file : a.progrd.java6.jar => 5104 bytes ( C’n s: 5104 )
STEP 4 : PACK200 - REPACK
Input file : a.progrd.java6.jar
Command line>pack200 --repack a.progrd.java6.jar
Output file : a.progrd.java6.jar => 5116 bytes ( C’n s: not available )
STEP 5 : PACK200 - PACK
Input file : a.progrd.java6.jar
Command line>pack200 --effort=9 --strip-debug --no-keep-file-order -O --no-gzip a.progrd.java6.pack a.progrd.java6.jar
Output file : a.progrd.java6.pack => 7878 bytes ( C’n s: 7878 )
For this step, the command was supplied by Bonbon-Chan.
STEP 6 : PACK200 - UNPACK
Input file : a.progrd.java6.pack
Command line>unpack200 a.progrd.java6.pack a.progrd.java6Test1.jar
Output file : a.progrd.java6Test1.jar => 5096 bytes ( C’n s: not available )
Here, you are supposed to test the resulting jar in a standard applet code. You can do it locally.
STEP 7 : KZIP
Input file : a.progrd.java6.pack
Command line>kzip /s0 /rn /b128 /y a.progrd.java6.kz.pack a.progrd.java6.pack
Output file : a.progrd.java6.kz.pack => 4172 bytes ( C’n s: not available )
As recommanded by Groboclown, here the kzip command should be repeated until you see what is the minimum compression value with the option /b128. Then, values other than 128 should be tested ( like /b64, /b96, /b104, /b112… ), and for each /bX value, the kzip command should be repeated again, until you find the minimum value with the optimal /bX value.
STEP 8 : ZIP2GZIP
Input file : a.progrd.java6.kz.pack
Command line>java Zip2Gzip a.progrd.java6.kz.pack a.progrd.java6.kz.pack.gz
Output file : a.progrd.java6.kz.pack.gz => 4054 bytes ( C’n s: 4058 )
Here, you will have to compile yourself the Zip2Gzip program before using it. Its source code can be found here, as indicated by Groboclown :
http://www.java-gaming.org/topics/java-4k-resources-thread/21630/msg/177304/view.html#msg177304.
STEP 9 : DEPLOYMENT
Now you can deploy your a.progrd.java6.kz.pack.gz file on your server, with the following applet code ( provided by appel ) put into a .htm page :
<applet code="a.class" archive="a.progrd.java6.kz.pack.gz" width="your width" height="your height">
<param name="java_arguments" value="-Djnlp.packEnabled=true" />
</applet>
FINAL NOTES
- the obsfuscator programs jarg ( to use before Proguard ) and JoGa ( to use after Proguard ) didn’t help with my code. Maybe I misused them, or my code did not fit well for them ;
- about using pack200, I missed a few steps as I didn’t sign my jar. But you will find some detailed informations about it here :
http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/tools/pack200.html - it seems you can’t test your pack.gz program without a server ;
- special thanks to pjt33 and his Zip2Gzip automagical converter.
hello Riven, is the applet version ready? Maybe an offline version would be great so everyone could execute it in local machine and not depend on the service to be online.