Re: [Ikvm-developers] scanning jars for class files

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

Hi Brian,

The resource jar is a real jar (attached as a .NET resource to the assembly). It would be too expensive to synthesize a jar with all the stub classes at runtime, so the classes live in the virtual file system as individual files.

As a workaround you could use the ikvmc -resource: option to manually add all the required classes as resources.

Something like this:
ikvmc -resource:com/nomura/unity/refdata/fingalmapper/Foo.class=<path to foo.class>

You probably want to use a response file (@filename) if you have a lot of classes.

Regards,
Jeroen

> -----Original Message-----
> From: bri...@no... [mailto:bri...@no...]
> Sent: Thursday, February 14, 2013 16:30
> To: Jeroen Frijters; ikv...@li...
> Subject: RE: scanning jars for class files
> 
> Hi Jeroen-
> 
> Thanks for your quick response!
> 
> I believe that this IS what Spring is doing.  Stepping through the code,
> I see that Spring is iterating over the entries in a jar located at
> c:/.virtual_ikvm_home/assembly/...
> 
> Spring is essentially doing this:
> 	((JarURLConnection)resource.getURL().openConnection()).getJarFile()
> .entries().
> 
> The URL is:
> 	{jar:file:/C:/.virtual-ikvm-
> home/assembly/fingalmapper.Lib/resources/fingal-mapper-1.0.0-
> SNAPSHOT.jar!/com/nomura/unity/refdata/fingalmapper/}
> 
> The entries I see in the jar contain all the dirs and all the non-class
> files, but not the classes.  Is it that the classes are synthesized on
> demand only when requested explicitly by name, meaning that jar scanning
> for classes will always fail in IKVM, or am I doing something wrong?
> 
> BTW, sorry about the legal clause.  It gets added automatically by the
> mail server and I cannot stop it. :(
> 
> Thanks,
> Brian
> 
> 
> 
> -----Original Message-----
> From: Jeroen Frijters [mailto:je...@su...]
> Sent: Thursday, February 14, 2013 1:51 AM
> To: Ross, Brian (IT/US); ikv...@li...
> Subject: RE: scanning jars for class files
> 
> Hi Brian,
> 
> The classes are not in the "jar", but they are synthesized (on demand)
> when they are requested as resources or when the virtual file system
> directory for that assembly is enumerated.
> 
> There is no switch to include the classes in resources jar, but I've
> considered it.
> 
> I don't know anything about Spring, but maybe it can be persuaded to
> look at the virtual file system directory instead?
> 
> BTW, it's considered very bad etiquette to post to an open source
> mailing list with such a ridiculous confidentiality clause.
> 
> Regards,
> Jeroen
> 
> > -----Original Message-----
> > From: bri...@no... [mailto:bri...@no...]
> > Sent: Thursday, February 14, 2013 1:42
> > To: ikv...@li...
> > Subject: [Ikvm-developers] scanning jars for class files
> >
> > Hi-
> >
> > I am calling Java code from .Net which creates a Spring
> > AnnotationConfigApplicationContext.  What Spring does here, is open up
> > the relevant jar files and iterate over their entries to find all
> > class files (after which it loads those classes to look for relevant
> > annotations).  When running through IKVM, Spring fails to find any
> > entries.  It appears that the jar files included in the assembly don’t
> > actually include the class files, although they are certainly in the
> > source jar I fed to ikvmc.  Is there any way to get ikvmc to include
> > the class files (or at least stubs sufficient to allow their presence
> > to be recognized)?
> >
> > Thanks,
> >
> > Brian
> >
> >
> > PLEASE READ: This message is for the named person's use only. It may
> > contain confidential, proprietary or legally privileged information.
> > No confidentiality or privilege is waived or lost by any
> mistransmission.
> > If you receive this message in error, please delete it and all copies
> > from your system, destroy any hard copies and notify the sender. You
> > must not, directly or indirectly, use, disclose, distribute, print, or
> > copy any part of this message if you are not the intended recipient.
> > Nomura Holding America Inc., Nomura Securities International, Inc, and
> > their respective subsidiaries each reserve the right to monitor all e-
> > mail communications through its networks. Any views expressed in this
> > message are those of the individual sender, except where the message
> > states otherwise and the sender is authorized to state the views of
> > such entity. Unless otherwise stated, any pricing information in this
> > message is indicative only, is subject to change and does not
> > constitute an offer to deal at any price quoted. Any reference to the
> > terms of executed transactions should be treated as preliminary only
> > and subject to our formal written confirmation.
> 
> 
> PLEASE READ: This message is for the named person's use only. It may
> contain confidential, proprietary or legally privileged information. No
> confidentiality or privilege is waived or lost by any mistransmission.
> If you receive this message in error, please delete it and all copies
> from your system, destroy any hard copies and notify the sender. You
> must not, directly or indirectly, use, disclose, distribute, print, or
> copy any part of this message if you are not the intended recipient.
> Nomura Holding America Inc., Nomura Securities International, Inc, and
> their respective subsidiaries each reserve the right to monitor all e-
> mail communications through its networks. Any views expressed in this
> message are those of the individual sender, except where the message
> states otherwise and the sender is authorized to state the views of such
> entity. Unless otherwise stated, any pricing information in this message
> is indicative only, is subject to change and does not constitute an
> offer to deal at any price quoted. Any reference to the terms of
> executed transactions should be treated as preliminary only and subject
> to our formal written confirmation.