Configuring and running

There is a skype-bot project at github. It is written in Java and has support for simple functionality. You can clone it via:

git clone https://github.com/toomasr/skype-bot.git

The project is maven based and once you import the project into your favourite IDE that has maven support it should compile out of the box. Before we can actually run the project we need to make couple of adjustments. First make a copy of the project.properties file and make it personal.properties. Then change the username, password and pemfile attributes in the file. Make sure that the folder that has the pem file also has a der file that has the same name (except the extension of course).

Next lets build the project. It is sufficient to just issue a mvn install command. You will end up with a skype-bot-0.0.1-SNAPSHOT.jar in the target folder. Before we can run that we need to start the runtime. See Running the Runtime from the previous post.

Now we are ready to start the bot. Issue a java -jar target/skype-bot-0.0.1-SNAPSHOT.jar. Now expecting that the Runtime is still running and that you updated the credentials in the personal.properties file you should see your need friend come online and you can start a chat.

The bot has the commands that he reacts to defined in the org.zeroturnaround.commands package. But for starters you can tell him “bot: time” and it will tell you the time.

Web Server

The bot also launches a web server on port 2500 that has defined handler on the url http://0.0.0.0:2500/post. You can send a POST message there with the parameters message=? and group=?. This will instruct the bot to issue the message to the group. The group is looked up from the bot’s list of groups that matches the Conversation.PROPERTY.displayname.

So what can we do with this? Most of the todays services have webhooks. For example GitHub has Service Hooks, FogBugz have Web Hooks and others have similar services. This means that you can register a web hook and when an event happens the bot will tell you over Skype (in a group chat for example).

What next?

This is up to you, hopefully you have a friendly bot. Make him tell you important information that you care about and don’t let him waste your time. Check back to the original article if I’ve added anything to the series.

Join the Skype Developer Program

A lot of necessary documentation and also software is behind a login screen at Skype Developer Program. You will need to join the program to continue and log in. This will cost you 10$. I personally don’t like the monetary fee for documentation and a SDK but I’m happy this is not 100$.

Now the biggest challenge has been conquered and you can also open up Skype’s own Getting Started Guide. That guide will go into more details with some of the next steps, so if you get stuck here be sure to check their documentation also.

Create a new project at Skype

Lets create a new project at the developer page. Navigate to My Projects submenu.There you can choose between multiple projects to create.

Right now you need to choose SkypeKit for Desktop. You can name the project something along the lines of chat-bot-demo and fill the rest of the form how ever you like (or they require). Now we have a project in place and we can move on.

Download the SDK and the Runtime

Navigate to your just created project and lets get the SDK and Runtime. SDK is the library (com.skype.*) that you will use to talk to the runtime (headless Skype client). The SDK you can download right away but for the Runtime you need to put in a request and it can take up to several hours to get the download link (usually just 5-10 minutes).

Build a sid-java-wrapper.jar file

The SDK comes in source format only, before we can continue we need to get this into a single JAR file and also install it in your local maven repository. To build it we need ANT to be installed (I presume you do). Issue the following commands now:

toomasr@cigar:~/$ cd skypekit-sdk_sdk/interfaces/skype/java/api/
toomasr@cigar:~/skypekit-sdk_sdk/interfaces/skype/java/api$ ant
Buildfile: ~/skypekit-sdk_sdk/interfaces/skype/java/api/build.xml
 
clean:
   [delete] Deleting directory ~/skypekit-sdk_sdk/interfaces/skype/java/api/bin
 
compile:
    [mkdir] Created dir: ~/skypekit-sdk_sdk/interfaces/skype/java/api/bin
    [javac] Compiling 36 source files to ~/skypekit-sdk_sdk/interfaces/skype/java/api/bin
 
jar:
      [jar] Building jar: ~/skypekit-sdk_sdk/interfaces/skype/java/api/sid-java-wrapper.jar
 
clean-build:
 
main:
 
BUILD SUCCESSFUL
Total time: 3 seconds

We have the sid-java-wrapper.jar file now in that api folder. For easier project setup we will be using maven (and probably for some of you shoot you in the foot as an added bonus). We will need to install the JAR file into our local repository. I will use com.skype as the groupId and skype-sdk as the artifactId. Issue the following command to do the same.

toomasr@cigar:~/$ cd ~/skypekit-sdk_sdk/interfaces/skype/java/api/
mvn install:install-file -Dfile=sid-java-wrapper.jar -DgroupId=com.skype -DartifactId=skype-sdk -Dversion=1.0 -Dpackaging=jar

Run the runtime

Just to check if the runtime starts lets unpack and start the binary. If everything goes successfully you should see something similar. On a Linux machine I had to download couple of different binaries before I got a client that did not die (at least on EC2).

toomasr@cigar:~/downloadss/mac-x86-skypekit-novideo_3.5.1.1041_493734/bin/mac-x86$ ./mac-x86-skypekit-novideo 
SkypeRuntime Copyright (C) 2003-2011 Skype Technologies S.A.
SkypeRuntime Version: 3.4.1/mac-x86-skypekit-novideo_3.5.1.1041_493734
Proprietary and confidential, do not share this application.

Development keypair

Next we need a development keypair. It is a signed RSA private key that you need to request from the Skype developer website. See the screenshot.

Once you have the file downloaded lets convert it to a format that is used by the Skype SDK. This is the openssl command for this. Be smarter than me and don’t accidentally overwrite the downloaded PEM file because they let you download it only once. The keypair is valid for 60 days!

openssl pkcs8 -topk8 -in download-pair.pem -outform DER -out downloaded-pair.der -nocrypt

Create a Skype account for the bot

Go to skype.com and create an account for you bot. Also add this bot to your friend list and log in once with the bot and accept the request.

Lets sum it up

By now we should have the following in place

• Have 10USD less on you bank account
• Skype Developer account
• A project created at Skype Developer page
• Working Skype Runtime
• Skype SDK jar file
• Development Keypair in PEM and DER format
• New contact on your contact list and its username/password

If you are missing any of those or had problems getting them then check out the more in depth documentation at developer.skype.com or post a comment.

Where to go from now? Check out the next part, Getting it Running.

The Plan

Image by Simon Abrams

The Skype bot needs a bit more work than your average IRC bot because of the proprietary nature of Skype. There is much clicking and downloading of certificate stuff to get you started for example. Also I want to show you how to put the bot into action, so we will go beyond just the bot.

Getting started

In this Part I – Getting Started we will go through the steps to get you started with the Skype developer program and download all the necessary software for the bot. The registration process, necessary accounts etc. Once you complete these steps you can develop any other bot out there.

Hacking on the Java part

In this Part II – Getting It Running we will take a Java Skype bot and get it running. It requires a little more than just compile and run so it has its own chapter.

We will also look into how to use this bot to notify about important information to Skype chat rooms.

And maybe something more

If everything went well then you have your own bot running now. There are many ways to go forward and improve the bot and the services. Lets see if we have time to cover those.

Hopefully next time that I have a dumb crazy idea I go have a beer instead.

So in the previous part I gave you an intro of the game and how I stumbled upon the game and how it took over our lunches (now we have recovered and are back to random discussions). In this part we’ll look how to detect the furballs from Fling screenshots.

Abstract

Lets build a web service that accepts screenshots of Fling and sends you back a webpage link of the solution to the image or just bunch of attachments.

Solution

Lets divide and conquer.

• Image/Color recognition to detect the Furballs (covered in this piece)
• Algorithm to solve the puzzles (not covered, but code available)
• Algorithm to draw the 1 step screens (not covered, but code available)
• Email handling (not covered, but code available)

Detecting Furballs

When I started out with this one I had no idea how to do it. I sent an email to one of my friends who has done image recognition and asked him how to get started. He took a look at the screenshot and asked, why do I need to recognize anything, just detect the color and you can tell if it is an empty square or a furball! It sounded so obvious that I was somewhat ashamed for not thinking of this myself :)

Python and PIL

Go get the latest version of PIL installed to have the examples work. Also we’ll be working from the root of the fling solver project. Just clone my BitBucket repo. So lets get started and load up the image and verify that PIL is working. Or you can skip this and take a look at blog_demo_1.py.

shot = Image.open(os.path.join(os.path.dirname(os.path.abspath(sys.argv[0])),       
                               "etc/shots/sample001.png"))                          
shot_pix = shot.load()                                                              
shot.show()

Once you execute this an image should pop up, like the one on the right. Now lets isolate a square and dwell into it.

Because the grid is static it is a matter of figuring out the width and height and the offsets as where the squares start. You can use your top notch vision, pixel ruler or little bit of Python to get this right. Run the following and you will see how I’m using PIL to find the offsets (trial and error). You should see something like this.

x, y, w, h = 2, 70, 45, 45                                                          
# lets choose the leftmost square and visualise it                                  
draw = ImageDraw.Draw(shot)                                                         
draw.rectangle([x, y, x+w, y+h], outline=(255, 255, 255))                           
del draw                                                                            
shot.show()

Ok, excellent. We now know the coordinates. Lets now average the colors. We will iterate through every pixel and take an average of the R, G, B values. We’ll also display the image for debugging purposes.

# lets find the average color
avgR, avgG, avgB = 0,0,0
counter = 0
# load pixels of the image
shot_pix = shot.load()
 
for i in xrange(1, w):
    for j in xrange(1, h):
        counter = counter + 1
        avgR = avgR+shot_pix[x+i, y+j][0]
        avgG = avgG+shot_pix[x+i, y+j][1]
        avgB = avgB+shot_pix[x+i, y+j][2]
 
avgR = avgR/counter
avgB = avgB/counter
avgG = avgG/counter
 
avgC = (avgR,avgG,avgB)
 
draw = ImageDraw.Draw(shot)
draw.rectangle([x, y, x+w, y+h], outline=(255, 255, 255), fill=avgC)
del draw
shot.show()

Okay, looks about right. Now lets do this for the whole image. Here I will be reusing code from the flingsolver package. You can do the same.

fip = ImProcessor('etc/shots/sample002.png')
fip.debug = True
state = fip.process()
fip.show()

Voila, all squares are marked with their average color. Now detecting furballs and not furballs is quite easy. Just make a conditional based on some color. For example I used:

def isBall(...)
...
if avgR in range(60, 90) and avgG in range(90, 130) and avgB in range(36,55):        
	return False
else:                         
	return True

For the complete demo you can run blog_demo_1.py from the flingsolver repository. It should generate all the images shown in this post. Happy hacking your own images!

Next time when I have time I will continue with the solving Fling and writing the email handling.

This post is an intro as how this all started out. I sure hope I get around to write the other posts (see the end of the post for a list of potential subjects).

I stumbled upon an iPhone game called Fling that I still play every now and then (I purchased it about a year ago). The game is a puzzle game and your mission (should you choose to accept it) is to fling furballs into each other and the ones closest to the edges are flung off the board.

See the animated GIF for a live demo or check out the video on Youtube. Once the board has just a single furball you’ve won!

As you progress the number of Furballs per level increases and finding a solution takes more time. At certain levels it takes a lot of time. Kind of reminds me of really difficult chess puzzles that can steal an hour or two from you.

The puzzle got so popular amongst colleagues of mine from ZeroTurnaround that during lunch we would place an iPad on the table with one of the levels and who ever found it interesting would give it a shot at some difficult level.

One time over lunch we theorized on how to solve a puzzle of this sort in algorithmic terms. We had different approaches and time estimates but one of the colleagues showed up with a Python solution the next day. Took him less than 90 minutes (apparently attended a not so interesting lecture). And in terms of time complexity we figured that on every move every furball has len(furballs) - 1 furballs to kick out so (n-1)! should be a rough upper bound estimate.

These 100 lines of Python code started a chain reaction of learning more Python, detecting furballs from screenshots, solving the puzzle by outputting images with the moves, email exchange with the author and prank pitching him as an investor, writing an email frontend (you can send in your screenshot), profiling Python, checking out Jython and hopefully some more blog posts on the subject.

In this post I’ll review how we solved this problem in JavaRebel, and share the solution with you. It’s not a magical solution, but it will help alleviate some of the problems introduced in both libraries and applications in Java EE.

The most common way to leak is to register some kind of a callback object and never deregister it. E.g. look at the following code:
[java]
Core.addListener(new MyListener());
[/java]
If Core is a part of the framework/platform/container then it will hold to MyListener long after the application was redeployed and the class loader left hanging.

Let’s see if we can do anything to solve this. The Core implementation looks something like this:
[java]
public class Core {
List listeners = new ArrayList();

void addListener(Listener l) {
listeners.add(l);
}

void fireListeners() {
// Exercise for the reader!
}
}
[/java]

The problem is that listeners provides a strong reference to the Listener object. What if we replace it by a weak one?

[java]
public class Core {
List listeners = new ArrayList();

void addListener(Listener l) {
listeners.add(new WeakReference(l));
}

void fireListeners() {
// Exercise for the reader!
}
}
[/java]

Unfortunately although this does solve the problem of GC-ing the class loader, it doesn’t really work. The Listener behind the weak reference will be GC-d at first opportunity and after that it’ll no longer receive any callbacks. To illustrate why it’s a problem the code above is basically equivalent to throwing the reference away altogether:

[java]
public class Core {
List listeners = new ArrayList();

void addListener(Listener l) {
// Listener is ignored and GC-d
}
}
[/java]

Replacing weak reference with a soft one doesn’t improve the situation, just delays the inevitable a bit further. Both are useful for caches, where objects can be recreated at will, but not in this case where we have an externally created object.

So what do we do? What we’d like to do is have the Listener reference to depend on the class loader somehow. Unfortunately, to the best of my knowledge, there isn’t a ready-made solution for that, and there’s no way to achieve it with any combinations of weak references without causing problems.

What we’d like to have is an ability to add a strong reference to the class loader: in other words have it carry a custom property:

[java]
void addListener(Listener l) {
ClassLoader cl = l.getClass().getClassLoader();
List lls = (List) cl.getProperty(“CoreListeners”);
if (lls == null) {
lls = new ArrayList();
cl.putProperty(“CoreListeners”, lls);
}
lls.add(l);
}
[/java]

That would work, wouldn’t it? Well, not quite. We also need to save a reference to the class loaders, so that we could later go over all of them. Here the WeakHashMap is useful:

[java]
Map classLoaders = new WeakHashMap();

void addListener(Listener l) {
//…
classLoaders.put(cl, Boolean.TRUE);
}
[/java]

There’s not WeakHashSet in Java, so we’re just using a boolean flag as the value.

So this would probably work, but unfortunately class loaders don’t have a getProperty()/putProperty() API. However, it turns out that with a bit of a hack we can simulate it, by generating a unique class per class loader to hold the properties for us. Let’s see how it’s done!

We start with a little boilerplate:
[java]
class ClassLoaderLocalMap {
private static Method defineMethod;
private static Method findLoadedClass;

static {
try {
defineMethod = ClassLoader.class.getDeclaredMethod(
“defineClass”,
new Class[] {
String.class,
byte[].class,
int.class,
int.class });
defineMethod.setAccessible(true);

findLoadedClass =
ClassLoader.class.getDeclaredMethod(
“findLoadedClass”,
new Class[] { String.class});
findLoadedClass.setAccessible(true);
}
catch (NoSuchMethodException e) {
throw new RuntimeException(e);
}
}
}
[/java]

This will give us access to ClassLoader protected methods defineClass() and findLoadedClass() later on. Now let’s setup the basic API:
[java]
public static void put(
ClassLoader cl,
Object key,
Object value) {
// Synchronizing over ClassLoader is safest
synchronized (cl) {
getLocalMap(cl).put(key, value);
}
}

public static Object get(
ClassLoader cl,
Object key) {
// Synchronizing over ClassLoader is safest
synchronized (cl) {
return getLocalMap(cl).get(key);
}
}
[/java]

getLocalMap() method should return a map of entries associated with the class loader. How should that work?

Next we introduce a map from class loaders to unique holder class names. We also introduce a nextHolderName() method that generates unique names:
[java]
private static final Map classLoaderToHolderClassName =
Collections.synchronizedMap(new WeakHashMap())
private static volatile int counter = 1;

private static String nextHolderName() {
return “ClassLoaderLocalMapHolder$$GEN$$” + counter++;
}
[/java]

Finally we can implement the getLocalMap() method (to save space I removed all exception handling):
[java]
private static Map getLocalMap(ClassLoader cl) {
String holderClassName =
(String) classLoaderToHolderClassName.get(cl);
if (holderClassName == null) {
holderClassName= nextHolderName();
classLoaderToHolderClassName.put(
cl, holderClassName);
}

Class holderClass =
(Class) findLoadedClass.invoke(
cl,
new Object[] {propertiesClassName});

if (holderClass == null) {
byte[] classBytes =
buildHolderByteCode(holderClassName);

holderClass = (Class) defineMethod.invoke(cl,
new Object[] {
holderClassName,
classBytes,
new Integer(0),
new Integer(classBytes.length)});
}

return (Map) holderClass
.getDeclaredField(“localMap”).get(null);
}
[/java]

The last method to implement is buildHolderByteCode. It’s quite trivial and builds the following class renamed to the unique name:
[java]
public class ClassLoaderLocalMapHolder$$GEN$$X {
public static final Map localMap = new HashMap();
}
[/java]
The code can be derived using ASMifier with just a little customization, you can look it up in the full source code.

Although we could now easily implement the original example it makes sense to do just a little bit extra effort and introduce a ClassLoaderLocal, with behavior similar to the ThreadLocal:
[java]
public class ClassLoaderLocal {
private Object key = new Object();

public Object get(ClassLoader cl) {
if (!ClassLoaderProperties.containsKey(cl, key))
return null;
return ClassLoaderProperties.get(cl, key);
}

public void set(ClassLoader cl, Object value) {
ClassLoaderProperties.put(cl, key, value);
}
}
[/java]

So the original example now becomes:

[java]
Map classLoaders = new WeakHashMap();
ClassLoaderLocal cll = new ClassLoaderLocal();

void addListener(Listener l) {
ClassLoader cl = l.getClass().getClassLoader();
List lls = (List) cll.get(cl);
if (lls == null) {
lls = new ArrayList();
cll.set(cl, lls);
}
lls.add(l);

classLoaders.put(cl, Boolean.TRUE);
}
[/java]

In this code if any listener comes from a freed class loader, then it will be GC-d from both Core.classLoaders and ClassLoaderProperties.classLoaderToHolderClassName, as both are WeakHashMaps and there are no strong references to the class loaders. The generated ClassLoaderLocalMapHolder$$GEN$$X class will also be GC-d along with the class loader, so we have effectively eliminated a class loader leak without explicit cleanup calls from the user.

I hope this code will be useful for someone. I cannot give any guarantees whether it will work or not and it’s clearly a hack (though a solid hack). Please use it if you actually understand what is happening.

If you see a bug in the code or have a good suggestion, please be sure to comment. There could be a free JavaRebel license in it for you :)

Full source code: ClassLoaderLocalMap.java, ClassLoaderLocal.java.

The other day I was playing around with a tool for memory analysis and wrote a small snippet using which I would be able to test the new tool. Quickly (Editor: yeah right quickly) created the following and executed it:

import java.util.*;   
class Leak {  
  static List<Integer> list = new ArrayList<Integer>();  
  public static void main(String[] args) {  
    for (int i = 0; i >= 0 ;) {  
      list.add(i++);  
    }  
    System.out.println("I will either reach here or die trying (with OOM)");  
  }  
}

And what do you think I was displayed by my command prompt (editor: CDOs don't have a command prompt):

Option A:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:2760)
        at java.util.Arrays.copyOf(Arrays.java:2734)
        at java.util.ArrayList.ensureCapacity(ArrayList.java:167)
        at java.util.ArrayList.add(ArrayList.java:351)
        at Leak.main(Leak.java:6)

Option B:

I will either reach here or die trying (with OOM)

Well, as I found out, it doesn’t print out anything. As this is now two years from my last real Java development experience (got demoted to C-level), I went to my hardcore Java hackers. For 10 minutes we all stood with bedazzled faces, before it struck – the memory will be allocated in a way that there is no room for new OutOfMemoryError() to be created.

If you execute the above with 64MB heapsize (which is the default heapsize):

C:\work\snippets\leak java -Xmx64m Leak
C:\work\snippets\leak

But if you increase (well actually modify) the heap size a bit:

C:\work\snippets\leak java -Xmx65m Leak
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:2760)
        at java.util.Arrays.copyOf(Arrays.java:2734)
        at java.util.ArrayList.ensureCapacity(ArrayList.java:167)
        at java.util.ArrayList.add(ArrayList.java:351)
        at Leak.main(Leak.java:6)
C:\work\snippets\leak

Moral of the story? I definitely would not want to be fixing a production system dying like this (Editor: lucky you, you don't have to) – most likely I would be mad way before I could have grasped anything about the reasons …

The previous post was about the weird relation between default visibility and method overriding, which in the end meant that @Override is broken in some cases. Today we’ll take a look at protected.

The main issue with protected in Java is that unlike C++ and most other OO languages it can pose in one of two incarnations — either as visibility from subtypes or as visibility in the same package (the latter is just like the default visibility). This can sometime lead to some confusion, but I have a specific case of interest to offer you.

In the previous post there already was one example involving protected:
[java]
public class /*p1.*/Main {
public static void main(String[] args) {
C1 c = new p2.C3();
System.out.println(c.m());
}
}
public class /*p1.*/C1 {
/*default*/ int m() {return 1;}
}
public class /*p1.*/C2 extends C1 {
protected int m() {return 2;}
}
public class /*p2.*/C3 extends p1.C2 {
protected int m() {return 3;}
}
[/java]

The relevant part in this example is that protected method is invoked via default visibility, but overridden via subtyping visibility. In case you don’t remember anymore the output is “3″. This shows that visibilities and overriding can be mixed pretty much freely. It is also a good example as it demonstrates why the original phrasing in the JVM spec was wrong. In the original phrasing for the method C3.m to override a method C1.m the latter had to be accessible from the former. In our example this is obviously not the case.

The corrected phrasing, available in the addendum, refers to the JLS notion of overriding, which adds transitivity. That is if C3.m overrides C2.m and C2.m overrides C1.m then C3.m overrides C1.m.

But getting back to the topic — when playing around with JavaRebel I stumbled on an even more interesting example where this dual nature of protected makes it act unexpectedly. The setup starts like this:
[java]
public class /*p1.*/Main {
public static void main(String[] args) {
p2.C2 c = new p2.C2();
System.out.println(c.m());
}
}
public class /*p1.*/C1 {
protected int m() {return 1;}
}
public class /*p2.*/C2 extends p1.C1 {
}
[/java]

This compiles and behaves as expected outputting “1″. A question I’d like to ask is: what happens if for some reason later you override the method m() in C2?

[java]
public class /*p1.*/Main {
public static void main(String[] args) {
p2.C2 c = new p2.C2();
System.out.println(c.m());
}
}
public class /*p1.*/C1 {
protected int m() {return 1;}
}
public class /*p2.*/C2 extends p1.C1 {
protected int m() {return 2;}
}
[/java]

Stop here for a second, take a look at it and hazard a guess…

The example seems similar to the previous one, so you’d expect that the output is “2″. But is it?

Let’s evaluate this from the point of compiler and JVM. Initially the call to C2.m from Main resolved to C1.m(), which is in the same package with Main. When we override the method this is no longer the case and actually the method isn’t accessible anymore. So the correct answer is that the code won’t compile.

This is strongly counterintuitive to me, mainly because I always assumed that overriding a method should never affect its caller in such a way. This also isn’t limited to a compile-time error, as it’s quite possible to compile the C2 without recompiling the rest of the classes and get an IllegalAccessError at runtime. So in my book this reads quite unnatural.

There are definitely more creative ways to f**k up with protected you can come up with, by moving from the “default” incarnation to the subtype one. If you know a good one do post it in the comments.

P.S. I’d love to see what weirdness would come if they’d actually introduce the module keyword as well. Luckily it’d be limited mostly to compile time, but as you saw even there things can get tricky.

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. [...] This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Now since I have a background in functional languages, I know that null references are not necessary. Null value is a member of all types, but some types don’t have or need a natural notion of absence. In fact in Haskell there is no such thing as an “absent” value generic to all types — types either have to declare it explicitly or wrap the underlying value into a Maybe type that has a dedicated Nothing value.

So e.g. the List type has a notion of an empty list encoded into the type:

// Roughly: a list is an empty list
// or a pair of a value and a list
data List a = Nil | Cons a (List a)

While the only way to encode an absent structure is to use Maybe:

// To build a car you need at most one engine
// and zero or more wheels :)
buildCar :: Maybe Engine -> [Wheel]  -> Car

So while I was discussing that with Simon, Kirk banged me on the head to get my attention (just joking, banging me on the head is nowhere near enough to get my attention). Apparently they were discussing more or less the same topic with Rickard, and he had a similar solution for Java. I assumed it was the widely discussed @NotNull annotation, but it was way cooler than that.

Basically in the beginning Rickard started by adding @NotNull support to Qi4J (BTW an amazing piece of engineering, definitely check it out), so that they could automatically insert runtime assertions for the parameters having the @NotNull annotations, something like that:
[java]
class Test {
void transfer(
@NotNull Account from,
Account to,
double amount) {
//…
}

public static void main(String[] args) {
// Succeeds
transfer(
new Account(“Bugs Bunny”), null, 1000000.0);
// Throws NullPointerException
transfer(
null, new Account(“Bugs Bunny”), 1000000.0);
}
}
[/java]

However soon after that they discovered that they were inserting @NotNull-s everywhere. So they reverted the notion and decided that they will generate the not null assertions for all parameters except the ones marked as @Optional. And this was the point when I thought to myself “Jevgeni, this is exactly what you were looking for!” So I turn to Rickard and I say “Rickard, this is exactly what I was looking for! This is amazing!” In fact this truly is amazing as it’s exactly captures the semantics of the Maybe type that I liked so much in the functional languages.

After that we go into a discussion whether or not it is possible to validate this assertion during compile-time. Opinions were mixed on this one, though I personally am convinced that it shouldn’t be too easy (your opinion on the topic is welcome, also it will make a great master’s thesis topic). Eventually I get an idea and I say “Rickard, I bet I could implement a JavaRebel plugin that would check this at runtime in about half an hour in 50 lines of code”. And of course Rickard goes “No way!”, so I’m challenged. Next day I sit down for half an hour, then for another half an hour (there was no internet!) and voila — I have a working JavaRebel plugin (in less that 50 lines of code) that will make your methods throw an exception if you try to pass a null reference to a parameter not marked as @Optional (the plugin code deserves another post altogether). Of course I have to show this to Rickard (and he goes “No way!”) and we agree to somehow join forces to promote this sane approach (starting with having a single namespace for the @Optional annotation).

So what do we get? The previous example now looks like this:
[java]
@OptionalCheck
class Test {
void transfer(
Account from,
@Optional Account to,
double amount) {
//…
}

public static void main(String[] args) {
// Succeeds
transfer(
new Account(“Bugs Bunny”), null, 1000000.0);
// Throws NullPointerException
transfer(
null, new Account(“Bugs Bunny”), 1000000.0);
}
}
[/java]
As you can understand if we make all of the code without the @Optional annotation to throw a NullPointerException for nulls we’ll break a lot of existing code. Therefore at the moment you also have to annotate the class where you want to enable such semantics with @OptionalCheck.

That’s pretty much it — you can download the plugin right away and just drop it in the classpath when JavaRebel is enabled (you’ll need a 2.0 milestone as 1.x was missing the necessary APIs). At the moment both annotations are in the org.optionalalliance package, but when it changes all you have to do is Organize Imports, so I won’t sweat the naming too much. Please do let us know what do you think of the approach and feel free to advocate it further :)

Cheers,
Jevgeni Kabanov

P.S. The plugin along with the source is also avalable in our Maven repository:

• URL: http://repos.zeroturnaround.com/maven2
• Group id: org.zeroturnaround
• Artifact id: javarebel-optional-check-plugin