Added java1.5-rt.jar to the shrinker:
http://indiespot.net/java-four-kay
Please report whether it makes smaller files…
For me the jars are indeed smaller, but the final pack.gz files are just as big :persecutioncomplex:
Having said that… as several gz-compressors are non-deterministic, it’s basically anyones guess. I get differences of up to 9 bytes per run.
[quote]Added java1.5-rt.jar to the shrinker
[/quote]
Cool. But, what was there before? I thought we wanted to add Java 1.6.
Read this:
[quote]Added java1.5-rt.jar to the shrinker:
http://indiespot.net/java-four-kay
Please report whether it makes smaller files…
For me the jars are indeed smaller, but the final pack.gz files are just as big
Having said that… as several gz-compressors are non-deterministic, it’s basically anyones guess. I get differences of up to 9 bytes per run.
[/quote]
Riven,
I got similar results. The jars are slightly smaller, but the Java 6 pack.gz files are exactly the same size as the Java 5 ones. Is it possible to add a checkbox to toggle Java 6 on/off? With this change, the service takes much longer to finish processing.
Well, the service takes twice as long, and I added a 250ms delay for each execution of a native process. Which roughly doubles the duration again, causing it to take four times as long as previously.
So I’m going to get rid of the Java 5 rt.jar compiler, but the service will still take twice as long, as it claimed way too much resources of the server.
FYI: Java 1.5 rt.jar is now disabled.
If anyone prefers to run this service offline, here is the steaming pile that is supposed to be the sourcecode.
With some minor effort you can refactor it to run standalone.
Hey, cool! Thank you!
What proguard settings are you using?
The web-based version says:
While the downloaded one says:
You seriously refactored that mess-with-dependencies, to something that runs?!
proguard.conf
libraryjars /root/jdk1.6.0_18/jre/lib/rt.jar
-keep public class *
-keep class *
-allowaccessmodification
-overloadaggressively
-optimizationpasses 99
-defaultpackage ''
proguard.fixed.conf
-libraryjars /root/jdk1.6.0_18/jre/lib/rt.jar
-keep public class *
-keep class *
-allowaccessmodification
-overloadaggressively
-optimizationpasses 99
-defaultpackage ''
-keepclassmembernames class * {
private *;
protected *;
public *;
* ;
}
As you can see, nothing special.
Keep in mind that the compressors are non-deterministic, so the results vary among runs. Also try the “randomize” feature, which takes a lot longer, which might save a byte or two.
[quote]You seriously refactored that mess-with-dependencies, to something that runs?!
[/quote]
Any chance you can post the refactored version? ;D
I hate to nitpick, but you forgot to close ‘out’ in Streams.transfer()
Otherwise, nice clean room impl. although you took some shortcuts 
You can ofcourse remove HighLevelSleep(EXEC_DELAY); because that’s only meant to reduce the load on the server.
Please do remember this is not in any way like my production code
Oops, lookie at that!
And yeah, I made a bunch of assumptions, especially about concurrency, so there’s a whole pile of shortcuts in there. 
I found that getting rid of all the sleeps resulted in some files getting a reported size of 0. I assume that’s what the final 1000 ms sleep is for.
As for not being production code; it works, it performs a service people want, and you didn’t waste days overdesigning it.
I haven’t thought about potential security concerns (instinctively, running native code on arbitrary input feels like it SHOULD be a flaw), but that doesn’t matter when you’re just running it locally.
The sleeps are only for cosmetic / load reducing reasons, and should have no impact on results. I’ll do some further testing to see whether I don’t 100% reliably wait for processes to either exit or get destroyed (timeout). Running locally, you should BTW remove the process-killing code, cause it’s acceptable to wait more than 2000ms for kzip.
Then there should be a security flaw in javac bitwise-or ZipOutputStream. After that all processes run on ‘trusted’ input (the generated jar). Or so I thought. The only real security breach is the alternative jar-upload, which I will probably unpack and repack before handling. Thanks for the heads up - previously I have been lazily ‘securing’ my server through obscurity :persecutioncomplex:
As I said, I hadn’t thought things through properly. I think you’re right!
[quote]Sure: http://www.minecraft.net/temp/Compressor.java
[/quote]
Thanks. You rock!
[quote]I found that getting rid of all the sleeps resulted in some files getting a reported size of 0.
[/quote]
I noticed this happens occasionally with the Compile-And-Shrink service.
[quote]The sleeps are only for cosmetic / load reducing reasons, and should have no impact on results. I’ll do some further testing to see whether I don’t 100% reliably wait for processes to either exit or get destroyed (timeout). Running locally, you should BTW remove the process-killing code, cause it’s acceptable to wait more than 2000ms for kzip.
[/quote]
That would explain it.
[quote]as several gz-compressors are non-deterministic, it’s basically anyones guess. I get differences of up to 9 bytes per run.
[/quote]
Can the local version have an option to run over night in an attempt to squeeze out every last byte?
Possibly, yeah, but then if it ends up at 4097 bytes, what will you do? 
It’s way easier to make it run indefinitely, storing the (at that time) smallest files in a specified directory. You’ll quickly see whether it converges to 4096 or not, and if it does, you can wait it out.
This morning I ran Windows Update. Now, Internet Explorer displays applets with a white border on the right and bottom sides. See the image below. I think I have JRE 1.6.0_20. I tried up update to 1.6.0_22, but the update page claimed that my JRE was up to date. I am using 64-bit Windows 7. Applets display correctly in Chrome. Anyone else experiencing this with IE?
Trying checking Zoom = 100% (View->Zoom->100%) as setting this to anything else changes the applet window size.
If it’s not that, then there’s trouble ahead ;D
I’ve decided what I’m entering now
[quote]Trying checking Zoom = 100% (View->Zoom->100%) as setting this to anything else changes the applet window size.
If it’s not that, then there’s trouble ahead
[/quote]
Alan_W,
Thanks! You were right! In fact, if you look at my screen shot, it says it is zoomed to 105%. Restoring the zoom back to 100% eliminated the ugly white border.