That is, you give it more threads, and the throughput increases; the overall time goes down.

The following graph shows, in blue, the Sun’s java.util.zip.ZipFile time to complete a set of unzips on an increasing number of threads:

Wait, what the cocking shit.

The red line shows a pure Java implementation of ZipFile that scales expectedly well. It’s slower on one thread, unfortunately, but faster than the synchronised Sun ZipFile with two threads.

As expected, the performance of Sun’s implementation massively increases (for large number of threads) if you manually synchronise on a global monitor around the ZipFile uses. Red line unchanged:

Y-axis: Seconds.
X-axis: 2^(n-1) threads (i.e. levelling out at 3 due to it being tested on a quad-core machine and being entirely CPU bound).

Test: Opening rt.jar and summing all the bytes in files who’s path contains an ‘e’.
File entirely cached by the file-system. JIT warmed. Heap significantly larger than required.

Vista x64, Sun Java 1.6u20 x64 (i.e. server vm).

java -cp jazzlib-binary-0.07.zip:. ZipFileTester somefile.zip


//\u000a/*
#include <iostream>

/*\u002a/
}
// */


Eclipse deals.. okay. The red-underlining in the commented sections is for the spelling. <3

deshield can. Given the number of magic numbers in it, I fully expect it not to work with other installers.

Why do they bother? The data isn’t even compressed; it’s just bit-twiddled a little with the file-name, and this magic number: [ 0x13, 0x35, 0x86, 0x07 ].

The test: committing a file that slowly increases in size, and a new file, 200 times.

git: 2 seconds.
darcs: 10 seconds.
bzr: 70 seconds.
svn: 200 seconds.

No comment.

Reproduction steps follow.

bzr 2.0.3 and git 1.5.6.5:
time ($CMD init && for i in $(seq 200); do echo $i >> foo && touch bar$i && $CMD add * &>/dev/null && $CMD commit -m "Whoosh"; done)

darcs (which, admittedly, took about 200 seconds to work out how to commit to) 2.0.2:
time ($CMD init && for i in $(seq 200); do echo $i >> foo && touch bar$i && $CMD add * &>/dev/null && $CMD record -a -Aa -m "Whoosh"; done)

svn 1.5.1:
rm -rf ../repo; svnadmin create ../repo && svn co file:///var/tmp/repo . && time (for i in $(seq 200); do echo $i >> foo && touch bar$i && $CMD add * && $CMD commit -m "Whoosh"; done)

He, like most .NET users, is desperately seeking features to differentiate his second-rate platform from the wonderfulnessness of Java.

He showed .NET expressions, a wonderful feature whereby the actual nature of a predicate can be retrieved at runtime and optimal, say, SQL can be built to match it.

He, however, claimed that Java lacks this feature. This is not the case.

ExpressionTest shows various uses of this in Java; basically:

Expression.toSQL(new Predicate() { @Override public boolean matches(FooDTO t) { t.a == 7; } });

will return:

(a = 7)

Obviously this remains slightly more verbose while the Java lambda proposals are finalised, but the feature is hardly missing!

Similarily,
return (t.a == 7 || t.a == 8 || t.a == 9) && "pony".equals(t.b);

becomes:

(a = 7 AND b = 'pony') OR
(a = 8 AND b = 'pony') OR
(a = 9 AND b = 'pony')

And, etc.

The implementation, if the devil compels you to look.

Catchlogger [jar] [git src] checks that exceptions are being logged properly.

It’s entirely fallible, but, if your codebase is prone to catching and ignoring exception, and you use log4j, it’s Very Helpful.

For example:

try {
  foo();
} catch (IOException e) {
  logger.error("bar: failed to foo", e);
}

This is fine; an error has occurred and it’s full stacktrace will be placed in the log4j configured log.

try {
  foo();
} catch (IOException e) {
  logger.error(e);
  logger.info("oh noes", e);
  e.printStackTrace();
}

None of these, however, will do anything useful. The first logs just the toString() to the error log, info is too low-level to log exceptions at, and printStackTrace() doesn’t necessarily go anywhere at all.

For this block, catchlogger will issue:
IOException e unused at (Test.java:15) in public main(String[] args) in path.

The JAR is huge as it pulls in the entire Eclipse compiler to parse the source. BSD/MIT licensed.

They claim the word “Free” for software available under the GPL.

Let us consider some developer freedoms, and some alternative licenses for blocks of code:

Looking at this, it’s reasonably obvious to me which licenses offer the most Freedom to the developer; that being the BSD/MIT/ISC family.

These are the licenses I use personally, and the licenses I use to define Free Software; I don’t see how it can be taken any other way.

–

• Link / use: The license allows you to use the software as a whole, for any purpose (i.e. it’s free for use in assisting proprietary software and terrorism) (like freedom 0, but applicable to libraries).
• Four boring freedoms: Follows the four freedoms outlined by the GNU project.
• Reuse the code: The freedom to study and reuse the code, for any purpose**** (especially for terroism).
• Sue the author: Generally, with proprietary software and with non-software licenses, you have the right to hold the author responsible for their work, at least, up to a certain value. The author may want to disown this responsibility.

–

* The LGPL is discouraged, the GDFL is not for software (and generally considered non-free anyway), the AGPL is an extension of the GPL.

** I can’t think of nearly any prominent Freeware libraries, either. Foobar2000’s SDK?

*** The WTFPL’s FAQ covers “Why is there no “no warranty” clause?”, and also why Public Domain isn’t really a license.

**** Apparently there’s some confusion as to what I mean by “for any purpose”. I include using the code inside other applications, regardless of their license, as a purpose. That is, the GPL does not allow code reuse for any purpose, because it does not allow code reuse in proprietary applications.

Eclipse Memory Analysis Tool (via. DTFJ for the IBM heapdumps) is rather resource hungry, needing massively increased the heap (~7gb, i.e. can’t be run on an 32-bit machine) and stack size (~8mb). However, once the heap dump had been loaded (1h+), it was reasonably obvious (after #266231) what was happening:

The finalizers wern’t being processed fast enough.

The finalization thread is run at a lower priority, and, seemingly, on the configurations on these machines/OS/JVM combinations, it was getting no time at all.

For historical reasons, quite a few large classes in our codebase have:

void finalize() {}

..in, that is, finalizers that do nothing at all. These empty finalizers still have to be run before the object can be collected, however, so they simply wern’t, quickly leaking memory. The more that was leaked, the slower the JVM was running, so the less time the finalization thread had, a vicious cycle.

I couldn’t find many other people experiencing this on the internet, I can only assume that people simply don’t use finalizers, which can only be a good thing.

One guy had a rather more interesting solution:

public static void main(String[] args)
{
  new Object()
  {
    @Override protected void finalize() throws Throwable
    {
      super.finalize();
      Thread.currentThread().setPriority(Thread.MAX_PRIORITY);
    }
  };
  // ...
}


The worst thing is, I can’t really see any disadvantages to this…

The Google Earth download is actually just a cunningly disguised Google Update installer, and it seems to think it needs elevation.

It extracts %TEMP%\GUXXXXX.tmp\GoogleUpdate.exe, then tries to run:

GoogleUpdate.exe /install "appguid={74AF07D8-FB8F-4d51-8AC7-927721D56EBB}&appname=Google%20Earth&needsadmin=true" /installelevated

Instead of this,

GoogleUpdate.exe /install "appguid={74AF07D8-FB8F-4d51-8AC7-927721D56EBB}&appname=Google%20Earth"

..will happily download and extract Google Earth to %TEMP%\7ZipSfx.XXX. This is the unpacked offline installer, but the installer itself still attempts to elevate. Luckily, it’s already unpacked, in:

%TEMP%\7ZipSfx.XXX\program files\Google\Google Earth

Just copy this folder to somewhere convenient and run googleearth.exe.

–

For reference for other apps, the quoted argument to GoogleUpdate.exe is the last “line” in the downloaded GoogleEarthSetup.exe.

I thought it’d be fun to directly fix the problem.

It seems that, like some other things, as far as I can see, there’s no support for this.

Luckily, it’s an even smaller patch than last time. I won’t show it, it’s simply erasure of a jmp. It’s a terrible solution to the problem, and the binary only contains fixes for kernel32.dll as seen on x64 SP1 and x32 SP1 as of now, it could break at any point. I implore nobody to use this utility seriously.

noelev (asc) (cpp) (pdb) works much like the reverse of the unix “sudo” command, running a command via. it makes it run without elevation.

It’s not infectious, so it won’t work for all applications (like some setup applications that unpack other installers), and, of course, some applications actually don’t work without elevation.

A lot of Windows components actually appear to cope relatively gracefully with the unexpected lack of permissions, unlike, say, the nVidia components. I was hoping to find an entertaining failure to screenshot, but they’re all boring.