Re: [Ikvm-developers] ClassCastException for DLL generated with IKVMC

[Jeroen F. <je...@su...>]

Hi Andy,

I just realized something that may be of help. When you catch an
exception in C# that originates in IKVMC compiled Java code, you often
don't get a stack trace (or only a partial stack trace). The way around
that is as follows:

try {
  ...
}
catch (System.Exception x) {
=20
java.lang.Throwable.instancehelper_printStackTrace(IKVM.Runtime.Util.Map
Exception(x));
}

Alternatively, if you put a try/catch with an x.printStackTrace() in the
Java code around the statement that throws, it will also print a full
stack trace.

If you report the full stack trace, I may be able to provide more help.

Regards,
Jeroen

> -----Original Message-----
> From: ikv...@li...=20
> [mailto:ikv...@li...] On=20
> Behalf Of Andy Harris
> Sent: Tuesday, August 15, 2006 23:41
> To: ikv...@li...
> Subject: [Ikvm-developers] ClassCastException for DLL=20
> generated with IKVMC
>=20
> Hi-
>=20
> =20
>=20
> We currently have to implementations of our product to=20
> satisfy customers who prefer Java and customers who prefer=20
> .net. It is becoming a maintenance issue to check fixes into=20
> both branches, migrating features between branches, etc.=20
> Hence, we want to consolidate into 1 code base with the help of IKVMC.
>=20
> =20
>=20
> After successful integration of ikvmc into our ant build=20
> process, I've been able to produce a set of DLLs and test=20
> console application. I don't see output from ikvmc that=20
> indicates any problems.
>=20
> =20
>=20
> However, at runtime, I get a ClassCastException for the=20
> following line:
>=20
> =20
>=20
>             Url u;  // assigned elsewhere
>=20
>             String path =3D u.getPath();
>=20
> =20
>=20
> The same exception occurs for
>=20
> =20
>=20
>             System.out.println(u.toString());
>=20
> =20
>=20
> I think the IKVM runtime is getting confused about two=20
> different versions of String, but don't know where there=20
> could be another version defined. The project that contains=20
> this java code also references 3 additional jars that have=20
> been IKVM'd: saxon.jar, xercesimpl.jar and xalan.jar. =20
>=20
> =20
>=20
> Here is the manifest of the project:
>=20
> =20
>=20
> .assembly extern IKVM.Runtime
>=20
> {
>=20
>   .publickeytoken =3D (13 23 5D 27 FC BF FF 58 )               =20
>          // .#]'...X
>=20
>   .ver 0:28:0:0
>=20
> }
>=20
> .assembly extern IKVM.GNU.Classpath
>=20
> {
>=20
>   .publickeytoken =3D (13 23 5D 27 FC BF FF 58 )               =20
>          // .#]'...X
>=20
>   .ver 0:28:0:0
>=20
> }
>=20
> .assembly extern mscorlib
>=20
> {
>=20
>   .publickeytoken =3D (B7 7A 5C 56 19 34 E0 89 )               =20
>          // .z\V.4..
>=20
>   .ver 1:0:5000:0
>=20
> }
>=20
> .assembly extern saxon.net
>=20
> {
>=20
>   .publickeytoken =3D (BF A5 75 5D 7F DE CB 9F )               =20
>          // ..u]....
>=20
>   .ver 0:0:0:0
>=20
> }
>=20
> .assembly extern xerces.net
>=20
> {
>=20
>   .publickeytoken =3D (BF A5 75 5D 7F DE CB 9F )               =20
>          // ..u]....
>=20
>   .ver 0:0:0:0
>=20
> }
>=20
> .assembly extern xalan.net
>=20
> {
>=20
>   .publickeytoken =3D (BF A5 75 5D 7F DE CB 9F )               =20
>          // ..u]....
>=20
>   .ver 0:0:0:0
>=20
> }
>=20
> =20
>=20
> This is a blocking issue and I've been unable to determine=20
> the cause or a workaround.=20
>=20
> =20
>=20
> Also, I've also been unsuccessful at using VS.NET 2003 to=20
> debug this issue (resorting to console tracing). I believe=20
> that it should be possible to step into a generated DLL when=20
> both javac and ikvmc have been instructed to compile with=20
> debugging enabled.
>=20
> =20
>=20
> I appreciate any suggestions or hints.
>=20
> =20
>=20
> -Andy
>=20
>=20