C# Actors with Akka 2.0 via IKVM .NET

Typesafe have released their second iteration of the amazing Akka actor framework. This was very exciting news to me, but unfortunately I can't really make any use of it professionally at the moment, as I have switched to C#/.NET for the current project I'm working on. So I have investigated the possibility of using the library in .NET, via IKVM. Guess what: I succeeded in executing various Akka samples in C#, opening up very interesting opportunities...


Here's how I did it. At first I tried to simply compile the akka-actors-2.0.jar into a DLL (using IKVM), using the following command, from within the Akka lib folder:


ikvmc -target:library -recurse:..\scala-library.jar akka-actors-2.0.jar


This basically instructs the IKVM compiler to convert the JAR into a .NET DLL assembly and to use the Scala library JAR to lookup missing dependencies / classes. A number of IKVMC0100 warnings are shown, about multiple missing anonymous class files. This seems quite worrying (there were about 50+ warnings) but didn't seem to affect the end library! In actual fact the classes reported as missing are not part of the JAR, so this may be an IKVM bug...


The next step was to convert this "getting started with Akka" Java code into C#. This step was fairly trivial. I'm planning to attach the C# file here. (!TODO!)


The final step (I thought) was to run it. But little did I know that the fun was just starting! The application would crash with an NoSuchMethodException. The missing method is an interesting one, found in the sun.misc.* Java package:


sun.misc.Unsafe.park(...)


It seems that this method is used by a built-in JSR166 implementation, from within Akka. As you may know JSR166 is the codename for the Fork/Join concurrency framework, introduced in JDK 7.

By investigating and trying to find out more about this class, I've understood that it provides high-performance, but platform-Dependent, implementations of common threading operations, such as thread state manipulation, direct memory access, etc.


As I'm not very keen on submitting bug reports (the waiting gets to me), I've had a stab at implementing this method. Apparently, the LockSupport class in the java.util.concurrent.* package provides a non-native implementation.

So I downloaded the IKVM source code and located the Unsafe.java class (the one under openjdk/sun/misc, not the one under classpath/*). I added the following method, somewhere near the unpark() method:




public void park(boolean isAbsolute, long time) {
if (!isAbsolute) {
if(time > 0)
java.util.concurrent.locks.LockSupport.parkNanos(time);
}
else
{
if(time > java.lang.System.currentTimeMillis())
java.util.concurrent.locks.LockSupport.parkUntil(time);
}
}


Then I had to re-compile IKVM, which meant I had to download the necessary dependencies (just follow the very simple instructions in the IKVM README file, found in the source IKVM package). Basically that involved downloading NAnt 0.85, JDK7 and the stripped OpenJDK package that IKVM provide as part of their downloads (click "Browse all files" in SourceForge). Ah, also you have to add to your path environment variable all of these, then run the default NAnt target and you're done.

Retrying to execute the sample Akka application was again causing NoSuchMethodException, but progress had been made! This time another method was missing...


Long story short, there were another 3 methods missing, all from within the Unsafe class. Here's how I implemented them:



public void monitorEnter(java.lang.Object o)
{
java.util.concurrent.locks.ReentrantLock lck = null;
synchronized(lckmap)
{
int hash = o.hashCode();
if(!lckmap.containsKey(hash))
lckmap.put(hash, new java.util.concurrent.locks.ReentrantLock());

lck = (java.util.concurrent.locks.ReentrantLock) lckmap.get(hash);
}

lck.lock();
}
}


public boolean tryMonitorEnter(java.lang.Object o)
{
java.util.concurrent.locks.ReentrantLock lck = null;
synchronized(lckmap)
{
int hash = o.hashCode();
if(!lckmap.containsKey(hash))
lckmap.put(hash, new java.util.concurrent.locks.ReentrantLock());

lck = (java.util.concurrent.locks.ReentrantLock) lckmap.get(hash);
}

return lck.tryLock();
}


public void monitorExit(java.lang.Object o)
{
java.util.concurrent.locks.ReentrantLock lck = null;
synchronized(lckmap)
{
int hash = o.hashCode();
if(!lckmap.containsKey(hash))
lckmap.put(hash, new java.util.concurrent.locks.ReentrantLock());

lck = (java.util.concurrent.locks.ReentrantLock) lckmap.get(hash);
}

lck.unlock();
}




You also have to declare a shared map at the top of the file somewhere:


private static Map lckmap = new HashMap();


Before anyone starts pointing out the obvious, I know there is a lot to improve in this code. But this is a temporary solution. The reason for this is that we cannot use ConcurrentHashMap as the "lckmap" type, because it creates a cyclic dependency. The JDK7 ConcurrentHashMap uses the Unsafe class internally... I plan to improve this over the coming week, so that I submit a patch to IKVM for inclusion with their next release.

So final steps now. We have to re-compile IKVM and execute the ikvmc compiler to convert again now (see first step above). From within Visual Studio, just reference all the "Akka.NET" dependencies:


IKVM.OpenJDK.Core
IKVM.OpenJDK.Text
IKVM.OpenJDK.Util
IKVM.Runtime


And you're done. You can now use Akka from within your C# / .NET projects. Have fun! You should be able to download the full completed product here (!TODO!)


Linux Mint (Lisa) 1680 x 1050 resolution

By default (as I'm accustomed to with Linux distros) the very useful (to me) resolution of 1680 x 1050 (@60Hz) is not supported. This could be because the Samsung SyncMaster 22" is not a very popular monitor... Here's how to get it to work with Linux Mint 12 (codename Lisa)

Type the following on a terminal:

inxi -Gx

This should show your graphics card info, for example:

Graphics: Card: ATI RV670PRO [Radeon HD 3850] bus-ID: 01:00.0
X.Org 1.10.4 drivers ati, radeon unloaded: fbdev,vesa Resolution: 1024x768@60.0hz
GLX Renderer Gallium 0.4 on AMD RV670 GLX Version 2.1 Mesa 7.11 Direct Rendering Yes


Then type this:

xrandr

Running xrandr gives us a bunch of info about the currently supported resolutions. Note that 1680x1050 is not there:

Screen 0: minimum 320 x 200, current 1024 x 768, mximum 8192 x 8192
DVI-0 unknown connection (normal left inverted right x axis y axis)
1360x768 59.8
..................
320x240 120.1
DIN disconnected (normal left inverted right x axis y axis)
DVI-1 connected 1025x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1024x768 60.0*
..................
640x480 59.9


Then type this:

cvt 1680 1050 60.0Hz

This establishes an X11 "modeline":

# 1680x1050 59.95 Hz (CVT 1.76MA) hsync: 65.29 kHz; pclk: 146.25 Mhz
Modeline "1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync


Now let's add this new mode:

xrandr --newmode @1680x1050_60.00@ 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync
xrandr --addmode DVI-1 @1680x1050_60.00@


Note: if you use CRT, you have to replace DVI-1 above.

That's it! Now you should have this new display resolution available under Menu -> System Tools -> System Settings -> Displays -> Resolution.

Enjoy the wonderful Linux Mint 12 experience :)

JPropel brings LINQ, reified collections and consice utilities for Java

This is a post about JPropel-light, a free and open-source Java library aiming to cut down code bloat, boilerplate and generally the number of lines of code Java developers have to write in order to complete a task.

It comes with full LINQ support, reified generic collections and concise one-liners for performing standard tasks such as reading an entire text file into memory, array manipulations, XML processing and querying, etc. Let's examine some of them.


LINQ

A very popular language feature of C#, Language INtegrated Query adds native data querying capabilities. These can, for example, be used to project and filter data in arrays and enumerable classes (source: LINQ)

var results = someCollection.where(c => c.SomeProperty < someValue * 2);

Here is an equivalent Java snippet:

List<SomeElement> results = new ArrayList<SomeElement>();
for(SomeElement c : SomeCollection)
if(c.SomeProperty < someValue * 2)
results.add(c);

This is a trivial example, but it becomes obvious that for more complex queries, such as group by, select many, etc. the code becomes much more verbose. Even the low level of verbosity shown above hides the real purpose of the snippet, so one has to read it multiple lines of code in their entirety to understand it. This gets in the way of the developer and is not good for productivity. So is the following *valid* Java code perhaps better?

List results = someCollection.where(propertyLessThan(someValue*2));

How is this possible? Well, firstly we have to import the right class, which would be the Linq class of the framework. It has implementations for all methods found in the .NET implementation such as: all, any, select, where, distinct, first, last, zip, etc.

The second step is to annotate the class that contains your code with the @ExtensionMethod annotation, imported from a library called lombok-pg. This library makes a lot of the shown syntactic sugar possible by instructing your compiler to pre-process the class code before compiling. This is done transparently to the developer. As far as bytecode is concerned, the code is converted to standard Java calls. So for the snippet above, the code effectively becomes:

List results = Linq.where(someCollection, propertyLessThan(someValue*2));

This you will recognise is standard Java static method call. This is how extension methods work under-the-hood in C# for example. But crucially, you as a developer do not have to work as such and can be much more expressive, using a builder-like fluent API:

List names = new String[] {"james","john","john","eddie"}.where(startsWith("j").select(toUppercase()).distinct().toList();

The above statement returns ["JAMES", "JOHN"] and is arguably more readable and concise than the equivalent imperative series of Java statements that it gets compiled down to, don't you agree?

String[] array = String[] {"james","john","john","eddie"};
array = Linq.toList(Linq.distinct(Linq.select(Linq.where(array, startsWith("j")), toUppercase())));

The other interesting thing to note here is how can we seemingly pass functions as arguments (e.g. see startsWith, toUppercase). Everyone knows that Java does not have first class functions, in other words, cannot pass methods/functions around as objects. This is another area where lombok-pg helps us, allowing for the annotation of methods/functions with @Function, enabling easier functional programming in Java.

@Function
private static String toUppercase(String element) {
return element.toUpperCase();
}

The above annotation will pre-process the code by wrapping the annotated function in an anonymous class, allowing us to pass it around as an object. This is what the resulting code would look like if you decompiled the class:

private static Function1 toUppercase(String element) {
return new Function1() {
public String apply(String arg) {
return element.toUpperCase();
}
}
}

This is similar to how Scala functions are implemented. You can then pass these 'functions' (which are really just Java objects / anonymous classes) around, just like you would pass objects around in other languages, e.g. C#. And these are the types of objects that the Linq class accepts as selectors, predicates, filters, etc. Here is for example the source code of the select() method.

public static TResult[] select(final TSource[] values, final Function1 selector)
{
List result = new ArrayList(values.length);

for(TSource item : values)
result.add(selector.apply( item));

return toArray(result, selector.getReturnType());
}

As you can see, all the above method does is call the apply() method of the function to extract the required data, oblivious to the actual implementation of your selector. The JPropel library comes with a number of predicates and projections built-in, such as the ones shown above e.g. startsWith, endsWith, contains, equal, etc. The Linq class static methods accept these as well as custom (written by you!) functions to perform select, where and other such operations, in a way that is suitable to your program.

The JVM deals with anonymous classes very frequently when you code against it using languages such as Scala. A benchmark between C++, Go, Java and Scala which made the news recently, showed that Scala's performance is very much on par with Java's. So clearly the JVM can cope with wrapping methods into anonymous classes pretty well. Therefore there is a minimal performance consideration when using such code, but you can also cache such 'functions' around when you know you will use them very frequently.

Most Linq methods come in two flavors. One accepts generic arrays and one accepts generic Iterables. There are two reasons for this. Firstly, arrays and Iterables do not share a common super class which would allow for traversal of items. Secondly, arrays and Iterables are handled completely differently from the JPropel library perspective.

So when you pass an array to be processed, the resultant array is allocated and all results are inserted before it is returned. This is not the case with iterables. Iterables are created using a block iterator, similarly to how yielding works in C#. This means that if you do not iterate over the entire collection, then only some of the elements are processed, which is more efficient, because it allows you to for instance break the iteration process without consuming as much memory and processing resources.


Reified generic collections

Generics in Java are implemented using type erasure. This means that generic type information is removed at run-time. A list of integers and a list of strings have the same class type in Java, which creates an interesting set of problems in areas such as overloading, instantiation and introspection. Type erasure is considered by many an inferior way of implementing generics. The subject of erasure vs reification has been covered neatly already so let's focus on what's important here. Since the JVM erases the run-time type of generics, we have to live with this. Or do we?

Neil Gafter came up with a workaround to this problem, called super-type token. The whole idea is based on the fact that the JVM does not erase type information of anonymous classes. Therefore if you instantiate a class using anonymous class semantics, you can query its run-time type parameter(s):

List list = new ArrayList<String>() {}; // note: braces after parentheses

The JPropel library embraces this pattern and provides a wide array of collections that follow it, such as Lists, Maps, Hashtables and others. This allows you to do common sense things such as:

LinkedList list = new LinkedList(){};
String[] items = list.toArray();

With type-erased collections you would have to do nonsensical things such as:

Object[] items = list.toArray();

or

String[] items = list.toArray(new String[list.size()]);

Being able to query the run-time type parameter can bring several benefits, especially if you are creating generic container, e.g. your own collection classes. But in such scenarios, if you have multiple layers of generic containers, you may not be able to reliably obtain the run-time type information. One example:

public class MyClass
public MyClass() {
List list = new ReifiedArrayList() {}; // no can do
}
}

The reason this is not possible, is because the type T of MyClass is not known. In such scenarios you have to pass the type explicitly, as such:

public class MyClass {
public MyClass() {
Class clazz = SuperTypeToken.getClazz(this);
List list = new ReifiedArrayList(clazz) {}; // OK
}
}

You then go ahead and instantiate MyClass using anonymous class semantics, as shown above (or pass the type explicitly if you wish). Although this is not ideal, at least it is possible to accommodate for multi-level generic containers.

Finally, it is also possible to instantiate collections with multiple type parameters:

AvlHashtable lookup = AvlHashtable() {};
Iterable keys = lookup.getKeys();Iterable values = lookup.getValues();

This is possible because the SuperTypeToken class has an overloaded method that allows you to obtain the generic run-time parameter type based on its zero-based index.


Fun with utilities!

There are a lot of very concise one-liners supported by the library, allowing you to focus on the actual problem you are trying to solve instead of writing boilerplate. Here are some examples.

// create alphabet
char[] alphabet = new Character('A').to(new Character('Z'));
char[] numbers = new Charracter('1').to(new Character('9'));

// join two arrays and put in a list
List allowed = alphabet.join(numbers).toList();


// load entire text file in memory
String data = file.readFileToEnd();

// append to file
file.appendText("Some more text");

// XML compacting
String compacted = someXml.compact();

// copy stream over
inputStream.copy(outputStream);

// Culture-aware case-insensitive string comparison
boolean trueInGermany = StringUtils.equal("stra├če", "STRASSE", StringComparison.CurrentCultureIgnoreCase);

// check if all elements are present
boolean itsTrue = "abcdef".containsAll(new String[] {"bc", "cd"}, StringComparison.Ordinal);


There are too many utilities to cover here, around the areas of reflection, XML, conversions (e.g. binary, octal, hex, decimal, base64, etc.), character escaping, hashing, strings, etc. Have a look at the propel.core.utils.* package for more.


JPropel

JPropel-light is a lightweight version of the JPropel library. If you do not mind a couple of extra dependencies (BouncyCastle and SLF4j), have a look at it as it contains some extra utility functionality.

For instance, the CryptographicString class allows you to store a secret in memory in encrypted form:

CryptographicString cs = new CryptographicString("super secret");
char[] unencrypted1 = cs.asCharArray();
byte[] unencrypted2 = cs.asByteArray();
String unencrypted3 = cs.asString(); // beware of String interning

Another interesting construct is the ability to trace method calls, logging all input and output data (or exceptions thrown) in a highly configurable way.

@Trace(level=LogLevel.INFO)
public int add(int a, int b) {
return a+b;
}

This allows you to focus on the task at hand without worrying if you have enough logging within a method. To enable the tracing you have to instantiate your class (perhaps via a factory newInstance() method) in a way that allows the tracing to take place:

IMyClass myClass = new Tracer(new MyClass());

All calls to myClass that have been annotated with @Trace will emit logging statements of all method arguments, results (if not void) and exceptions (if thrown). The logger uses SLF4j so will plug into any popular logging library you are using. The format of messages is highly configurable as well.


Lombok-pg

JPropel and JPropel-light depend on the lombok-pg library.

If you are using an IDE such as Eclipse or Netbeans, you should patch it so that it knows that lombok is used as a Java agent. The process is very simple: just double-click on the lombok.jar found in the "lib" folder. This will enable much of the syntactic sugar shown above.

Javac and Ant do not require any patching as such.

You may visit the lombok project website for more info, or ask Philipp more about it.

Scala on .NET via IKVM

This post will show you how to get started with writing Scala code and running it on the Mono and .NET runtimes, using a JDK re-implementation called IKVM.

So the Scala language has been gaining a lot of traction lately, mostly due to Twitter adopting it for their Kestrel messaging back-end as well as other open source projects. Another major reason why Scala is becoming increasingly relevant is the lack of velocity with which the Java community process has been incorporating various trendy language features, such as delegates, closures, and many more. There are many advantages you get when migrating from Java to Scala. So how about getting all of those and sticking close to your platform of choice, .NET?

Apparently an attempt was made to allow Scala to run over .NET, called Scala.NET. It is basically far from being production ready and only supports Scala 1.4, whereas what I'm going to show is verified to run on Scala 2.8 RC7.

1) Download the latest IKVM from SourceForge (I used 0.42.0.6)
2) Download the latest Scala from scala-lang (I used 2.8 Release Candidate 7)
3) Download a recent Java JDK and JRE (I used v1.6).
4) Write a Scala application in your favorite IDE, e.g. Netbeans
(Note: Use plugin manager in Netbeans to download Scala IDE support)
A typical app looks like this:

package myscalaapp

object Main{
def main(args: Array[String]): Unit = {
println("Hello Scala on .NET!!!")
}}


5) Build your project to create myscalaapp.jar
6) Copy myscalaapp.jar and scala-library.jar to your IKVM folder
7) Execute

ikvmc -target:exe -recurse:scala-library.jar myscalaapp.jar

8) Run myscalaapp.exe

Hello Scala on .NET!!!

Good times.

NHibernate with csharp-sqlite embedded C# database

Following my [NH-2120] post on JIRA, I decided to make another post here, just in case I need it in the future. Maybe for instance my driver does not get accepted for whatever reason.

So what I have done is created a driver for the managed embedded SQLite C#/.NET re-implementation database called C#SQLite (see csharp-sqlite project) and have tested this with the latest versions of csharpsqlite and NHibernate (2.1.2.GA using the SQLiteDialect).

This database re-implementation is really bringing together a number of very attractive things, such as fully managed code, .NET 2.0 requirement only, multi-platform support via Mono, OK performance, embeddable, etc, etc. So download a copy of the latest database and ADO.NET provider first.

Then you need the NHibernate sources. Open them up and create a new driver file in NHibernate.Driver called CsharpSqlite.cs

Once the driver file (link 1, link 2) is included/pasted in the project, I had to recompile NHibernate and NHibernate.Bytecode.LinFu (you may want to recompile the bytecode provider of your own choice e.g. Castle). I'm using it with 2.1.2.GA currently and C#-SQLite version 3.6.22 (latest at the moment) without problems. EDIT: The very latest version (3.6.23) is broken, I'm investigating this and will submit a patch. In the mean time, use my 3.6.22 binary.

For your own project, the usual NHibernate libraries need to be referenced, consult NHibernate documentation for this. But make sure you include the assemblies "Community.CsharpSqlite" (SQLite managed implementation) and "Community.CsharpSqlite.SQLiteClient" (the ADO.NET provider), both available from noah.hart's csharp-sqlite webpage (EDIT: use my binary above!).

Some of these libraries (e.g. CSharp SQLite itself as well as the Client) appear to target .NET 3.5, but setting them all to .NET 2.0 caused no compilation errors and they worked just fine for me.

Enjoy!

NHibernate embedded managed C# database

I was looking for an embedded cross-platform managed database to use for a C# .NET 2.0 project of mine and I was surprised to find out how difficult it was to find one. After you read this post, I hope that you will have discovered a new and exciting choice.

In my search I encountered the following posts:

(sources: Embedded database for .NET SO question, C#/.NET single user database SO question, Good "mobile" database .NET database SO question, Observations on embedded databases by Ayende, as well as many others)

The major options available seemed not good enough for various reasons:

SQLite: It's basically a native library with a x86-only requirement.
SQL Server CE: It's not thread safe and hangs periodically.
VistaDB: Commercial database.
SharpHSQL: No NHibernate support as of yet.
Firebird: Windows only.

The list goes on. Basically all available options either lacked a NHibernate support, or were not cross platform, or required installation, etc.

So when I stumbled upon this little gem called C#Sqlite (csharp-sqlite) which is a C# re-implementation of the latest SQLite database, I thought that my search was over. Alas, this embedded, managed, cross-platform (.NET/Mono) database (which also has an OK performance) was not possible to use with NHibernate, due to the lack of a driver.

I have posted an NHibernate driver for CsharpSqlite [NH-2120], so there, now you can use NHibernate with this wonderfully compact database which fits the bill for all of the above requirements.

I hope you enjoy it!

SyncMaster 2232bw on Windows 7 1680 x 1050 ATI 3850 AGP

On Windows 7, to get the 1680 x 1050 resolution running on a Samsung SyncMaster 2232BW attached to an ATI 3850 AGP graphics card, you will need two pieces of software:

- The Samsung SM 2232BW driver, from here
- The ATI Catalyst driver (9.1 or over) from here

This is the installation process:
- First, install the ATI driver and reboot
- Then install the Samsung driver
- Select the Analog (and not Digital) version
- Force the mode in the ATI Catalyst Control Center