[Biojava-dev] Bug report: getClassLoader() null return not handled

David Jung jungdl at ornl.gov
Fri May 7 13:43:17 EDT 2004


Thomas Down wrote:

> Thanks for pointing this out.
>
> The same problem actually occurs in quite a lot of places -- quite a 
> few areas of the BioJava "guts" do things with ClassLoaders.  I've 
> added a little ClassTools utility which provides a safe method for 
> getting hold of ClassLoaders.  Should be in CVS soon, or grab 
> tommorow's nightly build.
>
Excellent. Thanks.

> I'd be very interested to hear how you get on with IKVM.  To date, I 
> don't know of anyone who's used Biojava with a non-Sun-derived Java 
> implementation.


After making hackish fixes myself (which I'll replace with your new 
build), I can directly
run biojava apps using the biojava.jar file.  However, my normal mode of 
usage is
to run the biojava.jar through an IKVM utility (ikvmc) that translates 
the java bytecodes into
IL (aka .NET) bytecodes.  This is a simple one step process that 
produces a .NET
assembly file biojava.dll.  The assembly includes all the resources in 
the original .jar.
Now, I can just use the biojava API directly from any .NET language.
I'm actually in the beginning stages of developing a custom language for 
bioinformatics
(and scientific computing in general) called Scigol. 
So, now I can transparently access biojava (or any java) APIs from my 
scigol programs.
I plan to do the same with python in future (either using Python.NET
or Jython via IKVM compilation).
Next I plan to embedd the ikvmc functionality into the scigol 
interpreter (no compiler yet)
so that the user can just drop .jar files into their scigol library path 
and then use the APIs
directly.
Note that I'm doing all this uner Linux using Novell's (formerly 
Ximian's) mono
implementation of the .NET stuff.  This means that the Java standard 
APIs are
being supplied by the Class-path project (from which IKVM distributes a
IL version as classpath.dll).  The main missing part from class-path is 
Swing.
For this I'm investigating SwingWT - and open source implementation of Swing
that targets IBM's SWT GUI API (which uses native peers on various 
platforms).
It is cool to see the SwingSet demo running with a native look under 
Linux/Gnome!
I'd like to be able to use Swing from Scigol & C# under Linux & Windows.

Thomas Down wrote:

> I actually found calls to getClassLoader in 20 files, they should all 
> now be fixed.
>
> (Out of interest, do the IKVM developers give any specific reason for 
> returning null?  I find it a little bit worrying, because it seems to 
> suggest that the VM isn't really distinguishing between its bootstrap 
> classpath (with the core classes) and the application classpath.  I 
> don't know if this distinction has ever been formally specified by 
> Sun, but it's something a lot of developers take for granted now.)
>
Their initial comment when I pasted a bit of the offenting biojava code 
to the ikvm mailing list
was to say that the code was buggy (I explained about the null return & 
the Sun docs).
However, I agree with you, that a behaviour closer to Sun's would be 
helpful.  I don't understand
exactly how the ikvm remapping plumbing works, so perhaps making it 
perform that
way is difficult for some reason.  The remapping does some trickery to 
make obejcts, strings,
exceptions etc. look like the appropriate classes from each API. (e.g. 
So I can access the
System.Exception.InnerException property of an exception caught on the 
CLI side, say in
C#, and if the exception was thrown from Java I'll get the same as if I 
called java's getCause()
method (except that the return result is a CLI Exception class!) ).

I will post again to the ikvm list with your comment above (unless you 
object) and ask why
ikvm behaves that way and if there is any reason why making it behave 
more like the JDK
would be difficult or bad.

Oh - one other thing.  One reply from the ikvm list commented that the 
resource names
should have a leading '/' on them.  I don't know if that is true or not 
- but the getResourceAsStream()
calls work as is now.

Thanks very much for your feedback and fixes.
Cheers,
-David.



More information about the biojava-dev mailing list