When I first published the All-Rules Mail Bundle more than two years ago and also provided a precompiled binary, I didn’t spend much thought about where to host the binary. Just hosting it on GitHub together with the source seemed an obvious choice. But then GitHub said goodbye to uploads and discontinued their feature to upload binary files.

At this point I have to say that I wholeheartedly agree with their decision. GitHub is a great place to host and share source code and I love what they are doing.

In the last blog post about Daneel I mentioned one particular caveat of Dalvik bytecode, namely the existence of untyped instructions, which has a huge impact on how we transform bytecode. I want to take a similar approach as last time and look at one specific example to illustrate those implications. So let us take a look at the following Java method.

Those of you who kept following IcedRobot might have seen that quite some work went into Daneel over the past months. He¹ is in charge of parsing Android applications containing code intended to run on a Dalvik VM and transforming this code into something which can run on any underlying Java VM. So he is a VM compatible with Dalvik on top of a Java VM, or at least that’s what he wants to become.

So Daneel is multilingual in a strange way, he can read and understand Dalvik bytecode, but he only speaks and writes Java bytecode.

Have you ever wanted to automate some message sorting tasks in Apple’s Mail application after you have read a message? I, for example, use one archive folder per account and move all messages into that folder after I’ve read them. The application’s rule system is perfectly suited for that task, unfortunately there is no way to activate certain rules by pressing a keyboard shortcut. That’s where this bundle comes into play.

The All-Rules Mail Bundle acts as a plugin for Apple’s Mail application and serves just one specific purpose.

With this post I am proud to announce the first release of WAQL-PP, a WAQL Preprocessor for Java I was working on for the last two weeks. In one of the former posts I described the motivation behind this little project and how I planned to implement it. I’m rather satisfied with the result, so without further ado comes a copy of the release notes for this version.

This week I started to design and implement a preprocessor for the Web-service Aggregation Query Language (WAQL) which is an extension of XQuery. This language is used as part of the WS-Aggregation framework developed at the Distributed Systems Group of the Vienna University of Technology. With this text I want to explain the motivation behind WAQL and how the preprocessor will be designed. The motivation is nicely stated as part of my task description.

The key idea of WAQL is that it provides a convenience syntax for XQuery, which otherwise tends to become complex and hardly comprehensible in bigger scenarios. WAQL queries are transformed into valid XQuery expressions, which are finally executed by a (third-party) XQuery engine.

Some days ago I stumbled across a Java statement which I thought was trivial at first, only to discover that I had no idea. I have a reasonable understanding of what a JVM does and how Java bytecode is executed. But as this example shows once again, that doesn’t necessarily spread to the Java programming language. The snippet below should explain my point.

int lorem = 1, ipsum = 2, dolor = 3;
if (lorem == (lorem = ipsum))
	f();
if ((ipsum = dolor) == ipsum)
	g();

Which of the above two methods f() and g() is actually invoked? Can you tell without compiling the code?

As some of you might have heard (or deduced from my lack of activity), I have left Cacao. This is not a decision I took lightly, hence it took me some time to make it official by the means of this post.

I started my work on Cacao in 2005 with my first project being the ARM port of the code generator, which turned out to be my bachelor thesis and hooked me up with Cacao. I continued to actively contribute to the development of Cacao and tried to help push it towards being a real Java Virtual Machine.

The Java Remote Method Invocation API is a great thing to have because it is available in almost every J2SE runtime environment without adding further dependencies. However there are some implications when using RMI and I just cannot get my head around them:

1. Interfaces used as remote interfaces need to extend java.rmi.Remote. Interfaces should be clean and not contain any clutter introduced by a certain technology.

Since a few days Cacao successfully starts OpenJDKs JMX Monitoring and Management Agent if requested to do so. This allows you to remotely connect to Cacao with any JMX-compliant monitoring tool. One of the main responsibilities of this agent is to act as a server for MBeans (managed beans). The JRE provides some basic MBeans which allow out-of-the-box monitoring and management of VM internals. But applications can easily extend the functionality by providing custom MBeans.