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

[Shuvankar Mukherjee]

I am having similar problem while using biojava on Sybase's EAserver on
Windows NT.
I have prepared utility classes which works fine as stand-alone but could
not be used as AlphabetManager does not get initialized. (Same problem as
david mentioned).

EAserver (formerly jaguar) uses a sun VM.
Is the bug fixed in the current nightly build??? Could not follow David's
fix ??

EAserver is not even supporting a call of
            System.out.println("ClassLoader is
:"+this.getClass().getClassLoader().getClass().getName());

while the standalone application supports the call and gives the following
output.

        ClassLoader is :sun.misc.Launcher$AppClassLoader

Please advise ASAP.

regards

Shuvankar Mukherjee


> 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.
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at biojava.org
> http://biojava.org/mailman/listinfo/biojava-dev
>