#145 ClassCastExceptions
With just about all interactions with complex
applications I get exceptions like this:
> package com.coi.xtrend.client.test.base;
> CoreAPI.main(new String[0]);
java.lang.ClassCastException:
at com.coi.xtrend.client.base.Environment.<init>
(Environment.java:67)
at
com.coi.xtrend.client.base.Environment.getInstance
(Environment.java:169)
at com.coi.xtrend.client.base.Environment.init
(Environment.java:230)
at com.coi.xtrend.client.test.base.CoreAPI.main
(CoreAPI.java:559)
at sun.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
When I try the same with the DynamicJava-GUI,
there's no problem.
Any ideas?
Logged In: YES
user_id=429731
Hmm... Have you tried adding any necessary Jars or class
files to the "Extra Classpath" option in the Preferences window?
Logged In: YES
user_id=708858
No it's not the ClassPath, since I'm using the exact same
one when testing with DynamicJava.
The problem definately seems to be related to the
ClassLoader. I've managed to get around the Exception I
submitted originally, which turned out to be a cast on the
ClassLoader
code:
clsLoader = (java.net.URLClassLoader)
Environment.class.getClassLoader();
This doesn't work since DrJava uses it's own ClassLoader
which doesn't cast to URLClassLoader.
Trouble is, after getting around this bug I've ecountered
others of the same sort communiating with serialised
objects from Jboss, which also can't be casted or aren't
recognised as the class they're supposed to be.
Strangely enough DynamicJava doesn't seem to cause
any problems whatsoever.
I'm not sure whether it'd be practical for you, but maybe
you should rethink the DrJava ClassLoader.
Is there maybe an earlier DrJava
Logged In: YES
user_id=429731
Ah, yes, classloaders might be a problem for us. We do use
a custom classloader on top of the DynamicJava code,
partially because of classpath issues we have observed with
DynamicJava. (We've had trouble accessing or extending
classes stored in jar files unless we use our classloader.)
We'll look into this, though. Ideally, we'd like to be at
least as robust and functional as straight DynamicJava.
I'll try to determine if our classloader is a hard
requirement for us, or if there's another approach to pursue.
Charlie
(Oh, and we've had our "StickyClassLoader" for most of the
life of DrJava, so unfortunately, I cannot recommend an
earlier version.)