[Ikvm-developers] using ikvm within the context of a dll: java.lang.ClassCastException: Unable to cast object of type 'java.util.PropertyResourceBundle' to type 'sun.util.resources.OpenListResourceBundle'.

Discussion:

Oliver Egger

2016-04-29 13:23:03 UTC

Permalink

hi

first thanks for that cool product, we are using it with ehealthconnector
project to provide a .net api, see
https://sourceforge.net/projects/ehealthconnector/

but I have a slight problem ...

- i have a jar (ehc.jar) converted to a dll with ikvmc (ehc.dll)

- when i use the dll within a visual studio .net project and create an
executable (ehcdemo.exe) with references to ehc.dll and IKVM.OpenJDK.*.dll
the program runs through
ehcdemo.exe
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

- when i try to create a dll instead of the ehcdemo.exe and use that dll
(ehcdemo.dll) in my app.exe program i get a java.lang.ClassCastException:
Unable to cast object of type 'java.util.PropertyResourceBundle' to type
'sun.util.resources.OpenListResourceBundle'.

app.exe
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

I can fix above exception if i add all IKVM.OpenJDK.*.dll references
directly to my app

app.exe
|---------IKVM.OpenJDK.*.dll
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

however I would like that app.exe has no references directly to the
IKVM.OpenJDK.*.dll.

Is that possible? If you would have any pointers where to start looking for
a solution I would appreciate it very much! I'm not that much a .NET Person
so please excuse me if my question is out of topic for ikvm.

Best regards
Oliver
--
oliver egger

mobile: +41765795005
email: ***@ahdis.ch
twitter: @oliveregger <https://twitter.com/oliveregger>
http://www.ahdis.ch/

ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland
--
oliver egger

mobile: +41765795005
email: ***@ahdis.ch
twitter: @oliveregger <https://twitter.com/oliveregger>
http://www.ahdis.ch/

ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland

Jeroen Frijters

2016-04-29 13:55:08 UTC

Permalink

Hi Oliver,

No, all IKVM.OpenJDK.*.dll assemblies must be in the applicationâs bin directory.

The exception is caused by a bug in OpenJDK that is triggered when it canât load a required class.

Regards,
Jeroen

From: Oliver Egger [mailto:***@ahdis.ch]
Sent: Friday, April 29, 2016 15:23
To: ikvm-***@lists.sourceforge.net
Subject: [Ikvm-developers] using ikvm within the context of a dll: java.lang.ClassCastException: Unable to cast object of type 'java.util.PropertyResourceBundle' to type 'sun.util.resources.OpenListResourceBundle'.

hi

first thanks for that cool product, we are using it with ehealthconnector project to provide a .net api, see https://sourceforge.net/projects/ehealthconnector/

but I have a slight problem ...

- i have a jar (ehc.jar) converted to a dll with ikvmc (ehc.dll)

- when i use the dll within a visual studio .net project and create an executable (ehcdemo.exe) with references to ehc.dll and IKVM.OpenJDK.*.dll the program runs through
ehcdemo.exe
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

- when i try to create a dll instead of the ehcdemo.exe and use that dll (ehcdemo.dll) in my app.exe program i get a java.lang.ClassCastException: Unable to cast object of type 'java.util.PropertyResourceBundle' to type 'sun.util.resources.OpenListResourceBundle'.

app.exe
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

I can fix above exception if i add all IKVM.OpenJDK.*.dll references directly to my app

app.exe
|---------IKVM.OpenJDK.*.dll
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

however I would like that app.exe has no references directly to the IKVM.OpenJDK.*.dll.

Is that possible? If you would have any pointers where to start looking for a solution I would appreciate it very much! I'm not that much a .NET Person so please excuse me if my question is out of topic for ikvm.

Best regards
Oliver
--
oliver egger

mobile: +41765795005
email: ***@ahdis.ch<mailto:***@ahdis.ch>
twitter: @oliveregger<https://twitter.com/oliveregger>
http://www.ahdis.ch/

ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland
--
oliver egger

mobile: +41765795005
email: ***@ahdis.ch<mailto:***@ahdis.ch>
twitter: @oliveregger<https://twitter.com/oliveregger>
http://www.ahdis.ch/

ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland

Oliver Egger

2016-04-29 16:35:04 UTC

Permalink

Hi Jeroen

Thanks for your quick answer.

Is this a classpath loader issue that the classes are not visible from the
dependent dll's?
Is the bug already raised in OpenJDK and might it be that it get resolved
in a future release?

Best regards
Oliver

Post by Jeroen Frijters
Hi Oliver,
No, all IKVM.OpenJDK.*.dll assemblies must be in the applicationâs bin directory.
The exception is caused by a bug in OpenJDK that is triggered when it
canât load a required class.
Regards,
Jeroen
*Sent:* Friday, April 29, 2016 15:23
java.lang.ClassCastException: Unable to cast object of type
'java.util.PropertyResourceBundle' to type
'sun.util.resources.OpenListResourceBundle'.
hi
first thanks for that cool product, we are using it with ehealthconnector
project to provide a .net api, see
https://sourceforge.net/projects/ehealthconnector/
but I have a slight problem ...
- i have a jar (ehc.jar) converted to a dll with ikvmc (ehc.dll)
- when i use the dll within a visual studio .net project and create an
executable (ehcdemo.exe) with references to ehc.dll and IKVM.OpenJDK.*.dll
the program runs through
ehcdemo.exe
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll
- when i try to create a dll instead of the ehcdemo.exe and use that dll
Unable to cast object of type 'java.util.PropertyResourceBundle' to type
'sun.util.resources.OpenListResourceBundle'.
app.exe
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll
I can fix above exception if i add all IKVM.OpenJDK.*.dll references directly to my app
app.exe
|---------IKVM.OpenJDK.*.dll
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll
however I would like that app.exe has no references directly to the IKVM.OpenJDK.*.dll.
Is that possible? If you would have any pointers where to start looking
for a solution I would appreciate it very much! I'm not that much a .NET
Person so please excuse me if my question is out of topic for ikvm.
Best regards
Oliver
--
oliver egger
mobile: +41765795005
http://www.ahdis.ch/
ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland
--
oliver egger
mobile: +41765795005
http://www.ahdis.ch/
ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland

--
oliver egger

mobile: +41765795005
email: ***@ahdis.ch
twitter: @oliveregger <https://twitter.com/oliveregger>
http://www.ahdis.ch/

ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland

Jeroen Frijters

2016-04-30 05:29:35 UTC

Permalink

Hi Oliver,

Iâm not entirely certain, but I think you misunderstand how .NET assembly loading works. Itâs not a class loader issue. The IKVM boot class loader knows about all IKVM.OpenJDK.* assemblies.

I did file an OpenJDK bug for this, because it is not a supported scenario (neither for OpenJDK, nor for IKVM). In OpenJDK 9 the class library will be modularized and things will hopefully get a little better.

Regards,
Jeroen

From: Oliver Egger [mailto:***@ahdis.ch]
Sent: Friday, April 29, 2016 18:35
To: Jeroen Frijters <***@sumatra.nl>; ikvm-***@lists.sourceforge.net
Cc: ehc-implementors <ehc-***@googlegroups.com>
Subject: Re: [Ikvm-developers] using ikvm within the context of a dll: java.lang.ClassCastException: Unable to cast object of type 'java.util.PropertyResourceBundle' to type 'sun.util.resources.OpenListResourceBundle'.

Hi Jeroen

Thanks for your quick answer.

Is this a classpath loader issue that the classes are not visible from the dependent dll's?
Is the bug already raised in OpenJDK and might it be that it get resolved in a future release?

Best regards
Oliver

On 29 April 2016 at 15:55, Jeroen Frijters <***@sumatra.nl<mailto:***@sumatra.nl>> wrote:
Hi Oliver,

No, all IKVM.OpenJDK.*.dll assemblies must be in the applicationâs bin directory.

The exception is caused by a bug in OpenJDK that is triggered when it canât load a required class.

Regards,
Jeroen

From: Oliver Egger [mailto:***@ahdis.ch<mailto:***@ahdis.ch>]
Sent: Friday, April 29, 2016 15:23
To: ikvm-***@lists.sourceforge.net<mailto:ikvm-***@lists.sourceforge.net>
Subject: [Ikvm-developers] using ikvm within the context of a dll: java.lang.ClassCastException: Unable to cast object of type 'java.util.PropertyResourceBundle' to type 'sun.util.resources.OpenListResourceBundle'.

hi

first thanks for that cool product, we are using it with ehealthconnector project to provide a .net api, see https://sourceforge.net/projects/ehealthconnector/

but I have a slight problem ...

- i have a jar (ehc.jar) converted to a dll with ikvmc (ehc.dll)

- when i use the dll within a visual studio .net project and create an executable (ehcdemo.exe) with references to ehc.dll and IKVM.OpenJDK.*.dll the program runs through
ehcdemo.exe
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

- when i try to create a dll instead of the ehcdemo.exe and use that dll (ehcdemo.dll) in my app.exe program i get a java.lang.ClassCastException: Unable to cast object of type 'java.util.PropertyResourceBundle' to type 'sun.util.resources.OpenListResourceBundle'.

app.exe
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

I can fix above exception if i add all IKVM.OpenJDK.*.dll references directly to my app

app.exe
|---------IKVM.OpenJDK.*.dll
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll

however I would like that app.exe has no references directly to the IKVM.OpenJDK.*.dll.

Is that possible? If you would have any pointers where to start looking for a solution I would appreciate it very much! I'm not that much a .NET Person so please excuse me if my question is out of topic for ikvm.

Best regards
Oliver
--
oliver egger

mobile: +41765795005
email: ***@ahdis.ch<mailto:***@ahdis.ch>
twitter: @oliveregger<https://twitter.com/oliveregger>
http://www.ahdis.ch/

ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland
--
oliver egger

mobile: +41765795005
email: ***@ahdis.ch<mailto:***@ahdis.ch>
twitter: @oliveregger<https://twitter.com/oliveregger>
http://www.ahdis.ch/

ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland
--
oliver egger

mobile: +41765795005
email: ***@ahdis.ch<mailto:***@ahdis.ch>
twitter: @oliveregger<https://twitter.com/oliveregger>
http://www.ahdis.ch/

ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland

Andrew Finnell

2016-04-30 23:00:15 UTC

Permalink

I've written a test to simulate this problem and if there is enough
interest i'll upload it to GitHub. The good news is I see what the issue is
and see that Jeroen provided the answer but I think it was lost in
translation.

The issue here is that the Assembly **Binaries**, the files themselves must
be in the same directory as the executing assemblies file. The .NET
Executable Project within Visual Studio itself does NOT need the
references. So you can still maintain your abstraction that I assume you're
looking for.

You just need to have an After-Build event on the project to copy the IKVM
assemblies into the bin/Release and bin/Debug directories. You can even
setup flags for this and have the Library do the copying in order to keep
the separation.

To illustrate this you can add this code anywhere before you call IKVM
converted classes and your program will work.

// Make sure the IKVM OpenJDK files can be found in the same directory
// as the executing assembly.
DirectoryInfo root = new DirectoryInfo(@"OpenJDKLocation");
foreach (var fileInfo in root.GetFiles("IKVM.*.dll"))
{
if (!File.Exists(Path.Combine(new
FileInfo(Assembly.GetExecutingAssembly().Location).Directory.FullName,
fileInfo.Name)))
{
File.Copy(fileInfo.FullName, Path.Combine(new
FileInfo(Assembly.GetExecutingAssembly().Location).Directory.FullName,
fileInfo.Name));
}
}

At the end of the day the Assemblies have to be on the production system
somewhere. The problem with the mixture of the OpenJDK, IKVM and the .NET
runtime is that the OpenJDK files have to be in the same directory. You
don't need them reference from the executing project, thus, you can keep
the abstraction in place and your executable never needs to know it's
calling IKVM'fied classes.

Andrew T. Finnell

Post by Oliver Egger
Hi Jeroen
Thanks for your quick answer.
Is this a classpath loader issue that the classes are not visible from the
dependent dll's?
Is the bug already raised in OpenJDK and might it be that it get resolved
in a future release?
Best regards
Oliver

--
oliver egger
mobile: +41765795005
http://www.ahdis.ch/
ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications
Manager
Applications Manager provides deep performance insights into multiple
tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Ikvm-developers mailing list
https://lists.sourceforge.net/lists/listinfo/ikvm-developers

--
Regards
Andrew

Oliver Egger

2016-05-06 22:44:51 UTC

Permalink

Hi Andrew
Hi Jeroen

Thanks for your response and sorry for my delayed answer. I was able to
setup the application with no explicit reference as you described, that was
very helpful.

I got then afterwards two other problems which were different then in the
exe setup:

// org.apache.axis2.util.Loader -
java.lang.ClassNotFoundException:
org.apache.axis2.transport.http.CommonsHTTPTransportSender
/ /org.apache.axiom.om.util.StAXUtils - XMLStreamReader is
com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl instead
of com.ctc.wstx.sr.ValidatingStreamReader

I could resolve this finally when I found out to set the following at
startup:

ikvm.runtime.Startup.addBootClassPathAssembly(System.Reflection.Assembly.Load("jar.dll"));

Now the behaviour for exe and ddlised version are the same.

Thanks a lot for your support!
Oliver

Post by Andrew Finnell
I've written a test to simulate this problem and if there is enough
interest i'll upload it to GitHub. The good news is I see what the issue is
and see that Jeroen provided the answer but I think it was lost in
translation.
The issue here is that the Assembly **Binaries**, the files themselves
must be in the same directory as the executing assemblies file. The .NET
Executable Project within Visual Studio itself does NOT need the
references. So you can still maintain your abstraction that I assume you're
looking for.
You just need to have an After-Build event on the project to copy the IKVM
assemblies into the bin/Release and bin/Debug directories. You can even
setup flags for this and have the Library do the copying in order to keep
the separation.
To illustrate this you can add this code anywhere before you call IKVM
converted classes and your program will work.
// Make sure the IKVM OpenJDK files can be found in the same directory
// as the executing assembly.
foreach (var fileInfo in root.GetFiles("IKVM.*.dll"))
{
if (!File.Exists(Path.Combine(new
FileInfo(Assembly.GetExecutingAssembly().Location).Directory.FullName,
fileInfo.Name)))
{
File.Copy(fileInfo.FullName, Path.Combine(new
FileInfo(Assembly.GetExecutingAssembly().Location).Directory.FullName,
fileInfo.Name));
}
}
At the end of the day the Assemblies have to be on the production system
somewhere. The problem with the mixture of the OpenJDK, IKVM and the .NET
runtime is that the OpenJDK files have to be in the same directory. You
don't need them reference from the executing project, thus, you can keep
the abstraction in place and your executable never needs to know it's
calling IKVM'fied classes.
Andrew T. Finnell

Post by Oliver Egger
Hi Jeroen
Thanks for your quick answer.
Is this a classpath loader issue that the classes are not visible from
the dependent dll's?
Is the bug already raised in OpenJDK and might it be that it get resolved
in a future release?
Best regards
Oliver

Post by Jeroen Frijters
Hi Oliver,
No, all IKVM.OpenJDK.*.dll assemblies must be in the applicationâs bin directory.
The exception is caused by a bug in OpenJDK that is triggered when it
canât load a required class.
Regards,
Jeroen
*Sent:* Friday, April 29, 2016 15:23
java.lang.ClassCastException: Unable to cast object of type
'java.util.PropertyResourceBundle' to type
'sun.util.resources.OpenListResourceBundle'.
hi
first thanks for that cool product, we are using it with
ehealthconnector project to provide a .net api, see
https://sourceforge.net/projects/ehealthconnector/
but I have a slight problem ...
- i have a jar (ehc.jar) converted to a dll with ikvmc (ehc.dll)
- when i use the dll within a visual studio .net project and create an
executable (ehcdemo.exe) with references to ehc.dll and IKVM.OpenJDK.*.dll
the program runs through
ehcdemo.exe
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll
- when i try to create a dll instead of the ehcdemo.exe and use that dll
Unable to cast object of type 'java.util.PropertyResourceBundle' to type
'sun.util.resources.OpenListResourceBundle'.
app.exe
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll
I can fix above exception if i add all IKVM.OpenJDK.*.dll references directly to my app
app.exe
|---------IKVM.OpenJDK.*.dll
|---------ehcdemo.dll
|---------ehc.dll
|---------IKVM.OpenJDK.*.dll
however I would like that app.exe has no references directly to the IKVM.OpenJDK.*.dll.
Is that possible? If you would have any pointers where to start looking
for a solution I would appreciate it very much! I'm not that much a .NET
Person so please excuse me if my question is out of topic for ikvm.
Best regards
Oliver
--
oliver egger
mobile: +41765795005
http://www.ahdis.ch/
ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland
--
oliver egger
mobile: +41765795005
http://www.ahdis.ch/
ahdis gmbh
agile health data information systems
bertastrasse 4
8003 zÃŒrich
switzerland

--
Regards
Andrew