Monday, April 28, 2003

DotGNU & New Snapshot

Saturday I joined the DotGNU IRC meeting to discuss their Java support. We decided to make sure that our efforts will be interoperable.
They are working on a Java source to IL compiler and this complements IKVM's byte code to IL compiler nicely. We'll be working together to create a standard format for remapping Java classes to .NET classes and define custom attributes to express Java semantics that don't map directly onto the .NET standard attributes.

I made new source and binaries snapshots available. Not many changes:

  • invokespecial byte code now checks for null references before calling the method. I intend to write an item on invokespecial in the future, because it is quite an interesting instruction with a bit of a history.
  • Improved method overriding handling for methods that are less accessible than the method they override. Java allows this, but .NET doesn't. It is handled by giving the overriding method the same (or better) accessibility as the overriden method.
    IMHO this is a design flaw in the CLR, because it makes it a breaking change to widen the access of a virtual method in a new version of a type.
  • Improved ikvmc's handling of -recurse and added wildcard support to file arguments.
4/28/2003 10:54:39 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [2]
4/28/2003 5:17:06 PM (W. Europe Daylight Time, UTC+02:00)
<< Improved ikvmc's handling of -recurse and added wildcard support to file arguments. >>

Thanks!
Stuart |sballardAT NOSPAMnetreach dot com
5/6/2003 5:50:07 PM (W. Europe Daylight Time, UTC+02:00)
Can IKVMC handle Class.forName if the target class is in an assembly that isn't directly referenced by the assembly making the call?

I'm thinking about the case of JDBC drivers in particular. I have an application that uses JDBC that I'd like to distribute as a standalone exe using IKVM. It takes the name of the class to use as a JDBC driver in a configuration file, and calls Class.forName().newInstance() on it.

The easy way out would obviously be to compile the JDBC driver directly into the exe or into a dll that it references, but quite apart from the overhead of compiling lots of drivers in when we don't know until runtime which will be used, I don't have permission to redistribute some of them (such as Oracle's and Microsoft's). This also wouldn't allow the user to use any JDBC driver that I don't know about at compile time.

Ideally I'd like to ship my application as an exe with only its own code compiled in, and provide instructions to users on how to use ikvmc to compile their JDBC driver of choice into a dll, and tell them to just put it in the same directory as my exe. Would that work?
Stuart |stuart dot ballardAT NOSPAMcorp dot fast dot net
Name
E-mail (will be published)
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)

Answer:  
Comment (HTML not allowed)