# Sunday, 20 June 2004
« Another Snapshot | Main | Yet Another Snapshot »
A Couple More Fixes

A new snapshot with a few small fixes and bigger fix to support serialization of Throwable. Since java.lang.Throwable is a remapped type, it's fields don't really exist and therefor didn't get serialized (and I had totally failed to realise this). It turned out to be easy to add serialization support (compatible with Sun's serialization of Throwable) by using the (previously unknown to me) feature of serialization to manually do serialization in a way that is compatible with the default serialization implementation.


  • Fixed ikvm.exe regression that caused it to fail to invoke main on package private classes. (Caused by reflection fix in the previous snapshot).
  • Added (small) hack to reflection invoke to support deserialization of java.lang.Throwable (and subclasses).
  • Fixed (de)serialization of java.lang.Throwable.
  • Fixed small bug in Throwable.initCause(). Previously, if an exception was constructed and null was passed as the cause, you could later on use initCause() to change the cause.
  • Added ldlen opcode to remapper.cs
  • Fixed String.copyValueOf(char[]) to throw NullPointerException if array is null.
  • Fixed String(char[]) constructor to throw NullPointerException if array is null.
  • Fixed recently introduced reflection regression that (sometimes) causes NullPointerException when getting a method's declared exceptions. This mostly showed up running ikvmstub.

New snapshots: just the binaries and source plus binaries.

Sunday, 20 June 2004 11:04:29 (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]
Tuesday, 22 June 2004 15:08:19 (W. Europe Daylight Time, UTC+02:00)
Can I use VTK (A C++ lib)'s java (JNI) bindings w/mono?
Grumpy Old Man
Friday, 25 June 2004 14:09:47 (W. Europe Daylight Time, UTC+02:00)

I've used your compiler to successfully create .Net assemblies from various Apache projects. However, when using the eXist XML database (http://www.exist-db.org), a NullPointerException is thrown from the following statement:

InputStream is = SomeClass.class.getClassLoader().getResourceAsStream(SomeFileNameInsideTheJAR);

Is the getClassLoader or getResourceAsStream method not being properly handled by IVKM?
Friday, 25 June 2004 14:31:03 (W. Europe Daylight Time, UTC+02:00)
getClassLoader returns null for statically compiled Java code. According to the JVM specification this is legal (it means that the class was loaded by the bootstrap class loader), but unfortunately many applications don't deal with this very well.

What they should be doing is:


This always works, even if the bootstrap class loader (null) is used.

Having said all this, I'm considering changing IKVM in the future to have statically compiled load by a class loader other than the bootstrap class loader.
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview