... indistinguishable from magic
effing the ineffable since 1977


Recent Posts


Things that just should exist


The IKVM FAQ says that one of the main reasons for its existance is that it "just seems obvious that something like this should exist". That phrase struck a chord with me because I completely agree - if it didn't exist, I have the impression that the universe would have a distinctly IKVM-shaped hole in it.

In the last couple of weeks I've been working on a couple of possible small features (coincidentally, for IKVM) which leave me with the same impression.

The first one I only implemented a tiny fraction of - which happens to be the exact tiny fraction I need.

Some background: nrdo (which I run through IKVM) connects to your database at compiletime and creates your tables for you. However, since it's a Java program, it does that through JDBC, which isn't ideal if you're working on a .NET project for several reasons. Firstly, you need an IKVM-compiled version of the JDBC driver for your database. If your database (and driver) are proprietary, this constitutes a modified version of proprietary code and is therefore probably illegal to redistribute. Secondly, you need to specify your database connection information twice, once as a JDBC URL for use at compiletime, and once as an ADO.NET ConnectionString for use at runtime. And thirdly (at least if SQL Server is your database), the JDBC driver requires you to enable TCP/IP connections, while the ADO.NET provider can use some magic Windows protocol which can be better in various ways from a security standpoint (unlikely as that sounds).

So what I implemented was an implementation of the (very few... okay three) JDBC functions that nrdo actually calls, implementing them using ADO.NET underneath. Just stick "jdbc:sharp:System.Data.SqlClient:" in front of your ADO ConnectionString and you have a JDBC URL for the same database, as long as you don't want to do anything overly complicated like, I dunno, getting any results back from your queries.

This definitely seems like "something that just obviously should exist", but since it met my immediate need I don't have any time or motivation to add the other 99% of the JDBC driver API. I offered it to Jeroen for inclusion (and possible further development) as part of IKVM proper, but he (reasonably enough) doesn't want perpetually unfinished code rotting in his CVS repository. From his email (quoted with permission):

I have had the opposite (an ADO.NET wrapper for JDBC drivers, written by Mainsoft) sitting in my mailbox for a long time. It would definitely be nice to include both of these, but realistically, I don't have time to maintain them (which is why I never got around to doing anything with the ADO.NET wrapper) and I don't want to put them in cvs just to sit there and rot away.
So, yes I'd like it, but you'd also need to volunteer to maintain it ;-)

So if anyone has the need, interest or motivation to maintain and finish that code, there's a JdbcSharp-shaped hole in the universe waiting for you ;)

The second hole in the universe I'm trying to fill is something I noticed the very first time I ever used IKVM. I immediately wrote a comment on the IKVM blog about how schizophrenic it seemed to be writing code in C# that looked like this:

for (Iterator i = myList.iterator(); i.hasNext(); ) {
object o =;

It's marginally weird working with Java APIs through IKVM in general because they adhere to a different naming convention than other .NET APIs, but you can at least pretend the author just didn't read the Framework Design Guidelines. And if you're working in an IDE you don't even need to change the way you type - the casing will be corrected for you. But the moment you need to deal with any kind of Java collection you slam into a mental speedbump - you can't get at the data in the list in any way that any .NET programmer would ever think of. You have to switch gears and - for all practical purposes - write two lines of Java code in the middle of your C# program.

Congratulations, you just hit a foreach-shaped hole in the universe.

So I've been working with Jeroen to figure out what would be necessary to make C# foreach (and VB "For Each") work on Java collections when exposed through IKVM. We've got the code working to the extent that this code works:

java.util.ArrayList list = new java.util.ArrayList();
foreach (object o in list) {

But this code doesn't:

java.util.List list = new java.util.ArrayList();
foreach (object o in list) {

because the extra mapping is only done on classes, not interfaces. Stay tuned: I'm also planning on tackling the other direction (which is harder), so that if you have a 1.5-compatible Java compiler you'll be able to do:

cli.System.ArrayList list = new cli.System.ArrayList();
for (Object o : list) {


Merry Christmas and a Japi New Year

Well, Tom beat me to pointing out that Classpath has now hit 98% of 1.4, but I wasn't about to pass up the opportunity to use this post title :) There are now only two packages red - entirely missing - in 1.4 (jpeg and kerberos), one orange (html - 48% implemented but with a lot of work being done right now by Anthony and Lillian) and two yellow - 80-90% (ldap and print).

Against 1.2 the story is, as you would expect, even more impressive - only 0.74% missing, consisting of 9 classes (all in swing.text.html) and 10 methods (mostly in swing.text).

Go Classpath hackers! :)