Faux' blog

InstallShield unpacker

I couldn't find anything that would unpack the (entirely unnecessary) Nokia map loader set-up application, which is some InstallShield 7 nastiness.

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 ].

Tro^WMicrobenchmarks!

This blog is far too low in trolling. As a start, everyone knows that git is fast and svn is slow, but I wasn't aware quite how shocking the difference was.

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.

Continue reading...

But Java /can/ do that!

I recently attended a talk at FOSDEM by Miguel de Icaza, a fellow enemy of "Free" software.

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<FooDTO>() { @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

Post seriousness: 70%.

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.

The Free Software Definition

The GNU project publishes a list of four Freedoms and recommend a single license*, the GPL.

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:

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.

Continue reading...

Finalizers considered harmful

I diagnosed an interesting problem at work recently; our application, when running on some enterprise platforms was eventually (over a number of days) running out of memory, grinding to a halt then fatally OutOfMemoryErroring, regardless of how much heap it was given.

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...