Re: [Ikvm-developers] Package.getImplementationVersion

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

Thanks for the repro. It turns out that this is a design limitation. You can only have one manifest per class loader currently.

This is a left over from the times when it wasn't possible to have multiple resources with the same name. I will try to fix this for 7.4.

Regards,
Jeroen

> -----Original Message-----
> From: Eric Pederson [mailto:er...@gm...]
> Sent: Wednesday, February 19, 2014 19:12
> To: Jeroen Frijters
> Cc: ikv...@li...
> Subject: Re: [Ikvm-developers] Package.getImplementationVersion
> 
> Whoops - my bad, sorry about not posting the repro.  I am assuming you
> mean attach to the email?  If not please let me know.
> 
> The repro is attached as file ptest.zip.  Inside, the file "b" is the
> build script:
> 
> 
> 	#!/bin/sh
> 	export PATH="C:\work\KozoExcel\Dependencies\net.ikvm\ikvmbin\ikvm-
> 7.2.4630.5\bin:"$PATH
> 
> 	echo Compiling
> 	javac p/*.java
> 	javac p2/*.java
> 
> 	echo Creating JARs
> 	jar cfvm p.jar MANIFEST.MF p/CCTest.class
> 	jar cfv p2.jar p2
> 
> 	echo Creating DLL
> 	ikvmc -target:library -out:ptest.dll p2.jar p.jar      # This fails
> 	#ikvmc -target:library -out:ptest.dll p.jar p2.jar     # This works
> as expected
> 
> 	echo Creating test.exe
> 	ikvmc -out:test.exe p/CCMain.class -r:ptest.dll
> 
> 	echo Running test.exe
> 	./test.exe
> 
> 
> When run as is, the output is (incorrect):
> 
> 
> 	class: class p.CCTest
> 
> 	package: package p
> 
> 	getImplementationVersion: null
> 
> 	getImplementationTitle: null
> 
> 	getImplementationVendor: null
> 
> 	getSpecificationVersion: null
> 
> 	getSpecificationTitle: null
> 
> 	getSpecificationVendor: null
> 
> 
> 
> When you switch the commented lines the output is (correct, from the
> p.jar manifest):
> 
> 
> 	class: class p.CCTest
> 
> 	package: package p, Kozo Function Client Library, version 1.3.15-
> SNAPSHOT
> 
> 	getImplementationVersion: function-clientlibrary-1.3.15-SNAPSHOT
> 
> 	getImplementationTitle: Kozo Function Client Library
> 
> 	getImplementationVendor: null
> 
> 	getSpecificationVersion: 1.3.15-SNAPSHOT
> 
> 	getSpecificationTitle: Kozo Function Client Library
> 
> 	getSpecificationVendor: null
> 
> 
> Thanks,
> 
> 
> -- Eric
> 
> 
> 
> On Tue, Feb 18, 2014 at 12:17 PM, Eric Pederson <er...@gm...
> <mailto:er...@gm...> > wrote:
> 
> 
> 	Hi Jeroen - I just wanted to follow up on this.  It looks like a
> bug?
> 
> 	Thanks,
> 
> 
> 	-- Eric
> 
> 
> 
> 	On Tue, Feb 11, 2014 at 1:17 PM, Eric Pederson <er...@gm...
> <mailto:er...@gm...> > wrote:
> 
> 
> 		Hi Jeroen:
> 
> 		Per your instructions I created a small test case.   If I
> create a DLL with just the jar that has the class that I am calling
> getClass().getPackage().getImplementationVersion() on, then it works
> fine.  However, if the DLL is created with a number of jars, then it
> uses the information from the manifest of the first jar.  For example
> the DLL is created with:
> 
> 		ikvmc -target:library -out:MyLib.dll -version:3.2.1 -
> sharedclassloader jar1.jar jar2.jar jar3.jar
> 
> 		it will always use the information from the manifest of
> jar1.jar, even if the class in question is from jar2.jar.
> 
> 		Thanks,
> 
> 
> 		-- Eric
> 
> 
> 
> 		On Tue, Feb 11, 2014 at 2:52 AM, Jeroen Frijters
> <je...@su... <mailto:je...@su...> > wrote:
> 
> 
> 			Hi Eric,
> 
> 			After you create the dll you can create an exe from a
> small Java class that prints the package info. Compile the test class
> like this:
> 
> 			ikvmc -out:test.exe Test.class -r:MyLibrary.dll
> 
> 			Regards,
> 			Jeroen
> 
> 
> 			> -----Original Message-----
> 			> From: Eric Pederson [mailto:er...@gm...
> <mailto:er...@gm...> ]
> 
> 			> Sent: Monday, February 10, 2014 19:10
> 			> To: Jeroen Frijters
> 			> Subject: Re: [Ikvm-developers]
> Package.getImplementationVersion
> 			>
> 			> Hi Jeroen:
> 			>
> 			> What's the best way to create a small repro?  I'm a
> Java guy and I don't
> 			> know the best way to do this.  The project that I'm
> working on is a
> 			> Excel .XLL addin.  I can create a small DLL based on a
> small jar using
> 			> ikvmc - how would I test that DLL?
> 			>
> 			> In the meantime, here's some more clues - the other
> package.getXXX
> 			> methods also return values that aren't the same as the
> manifest for the
> 			> jar that contains the class:
> 			>
> 			>
> 			> getImplementationVersion: 1.1
> 			>
> 			> getImplementationTitle: Sun Java System Application
> Server
> 			>
> 			> getImplementationVendor: Sun Microsystems, Inc.
> 			>
> 			> getSpecificationVersion: 1.1
> 			>
> 			> getSpecificationTitle: JavaBeans(TM) Activation
> Framework Specification
> 			>
> 			> getSpecificationVendor: Sun Microsystems, Inc.
> 			>
> 			>
> 			>
> 			>
> 			> Thanks!
> 			>
> 			>
> 			>
> 			> -- Eric
> 			>
> 			>
> 			>
> 			> On Sun, Feb 9, 2014 at 5:56 AM, Jeroen Frijters
> <je...@su... <mailto:je...@su...>
> 
> 			> <mailto:je...@su... <mailto:je...@su...> >
> > wrote:
> 			>
> 			>
> 			>       Please post a (small) repro.
> 			>
> 			>
> 			>       > -----Original Message-----
> 			>       > From: Eric Pederson [mailto:er...@gm...
> <mailto:er...@gm...>
> 			> <mailto:er...@gm... <mailto:er...@gm...> >
> ]
> 			>       > Sent: Saturday, February 8, 2014 1:36
> 
> 			>       > To: ikv...@li...
> <mailto:ikv...@li...>  <mailto:ikvm-
> <mailto:ikvm->
> 			> dev...@li...
> <mailto:dev...@li...> >
> 			>       > Subject: [Ikvm-developers]
> Package.getImplementationVersion
> 			>       >
> 			>       > Hi all:
> 			>       >
> 			>       >
> this.getClass.getPackage.getImplementationVersion returns "1.1"
> 			> instead
> 			>       > of the string in the MANIFEST.MF using a DLL
> built with ikvmc
> 			>       > 7.2.4630.5.  I saw in mailing list post that
> 7.1 should support
> 			> it.
> 			>       >
> 			>       > Please advise, thanks!
> 			>       >
> 			>       >
> 			>       > -- Eric
> 			>
> 			>
> 			>
> 
> 
> 
> 
>