# Thursday, March 28, 2013
« New Development Snapshot | Main | Java 7 Update 21 »
IKVM.NET 7.3 Release Candidate 0

The first release candidate is available. It can be downloaded here or from NuGet.

What's New (relative to IKVM.NET 7.2):

  • Greatly improved support for dynamically loading classes in statically compiled assembly class loaders.
  • Changed ikvmc to default to using runtime binding when a class is not available at compile time.
  • Fixed ikvmc to use jar class loading that matches the runtime.
  • The runtime now projects stub classes into the (virtual file system) jars they came from.
  • Runtime stub classes are now generated by the same code as ikvmstub uses.
  • Fixed a typo in ikvm.runtime.Startup.addBootClassPathAssembly() method name.
  • Fixed memory model bugs on ARM.
  • Many bug fixes.
  • Improved ikvmc error messages.
  • Deprecated using stub classes with ikvmc.
  • Added IKVM.Attributes.JavaResourceAttribute to allow .NET resource to be exposed to Java.
  • Font API improvements.
  • Graphics API improvements.
  • Support building IKVM.NET on .NET 4.5, but targetting .NET 4.0.

Changes since previous development snapshot:

  • Volatile long/double fields should not use slow reflection.
  • Reduce complexity of annotation custom attributes construction to improve performance and lower risk (for broken apps that should have used ReflectionOnly).
  • Removed accidentally public methods from ikvm.internal.AnnotationAttributeBase.
  • Fixed ikvm.internal.AnnotationAttributeBase to freeze in writeReplace/Equals/GetHashCode/ToString.

Binaries available here: ikvmbin-7.3.4830.0.zip

Sources: ikvmsrc-7.3.4830.0.zip, openjdk-7u6-b24-stripped.zip

Thursday, March 28, 2013 9:27:31 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [8]
Friday, April 12, 2013 3:45:27 PM (W. Europe Daylight Time, UTC+02:00)
Good to see how much effort you keep putting in IKVM. Using the latest version I noticed that assemblies created with IKVMC are suddenly a lot bigger than previous versions. For example, previously the size of was 3.335.680 bytes, but now it has produced 4.884.480 bytes (!) eventhough the original jars haven't changed. I am not 100% sure, but it may have to do with a lot of extra metadata (.NET attributes) being produced. Is this really needed and can it be turned of?

Patrick
Patrick
Friday, April 12, 2013 5:09:47 PM (W. Europe Daylight Time, UTC+02:00)
This is probably because classes that aren't compiled are now stored in the assembly.

If you can send me a repro I will investigate. You can also use ildasm to compare the jar resources in the old and new versions.
Jeroen Frijters
Monday, April 15, 2013 4:48:12 PM (W. Europe Daylight Time, UTC+02:00)
Based on your feedback it is exactly what you mentioned; the jar resources are now significantly larger, sometimes more than 100x. I really would appreciate if you can provide a solution for this because the deployment size of my application has doubled in size.
Patrick
Monday, April 15, 2013 4:54:50 PM (W. Europe Daylight Time, UTC+02:00)
The fundamental change in 7.3 is that classes that can't be compiled are now included as resources.

If you don't want the classes as resources in your assembly, in general you should not put them in the jar.

I can't really provide any specific fixes or suggestions without more information.

Also, please use the ikvm-developers mailing instead of the blog comments for these types of interactions.
Jeroen Frijters
Friday, September 13, 2013 11:35:52 AM (W. Europe Daylight Time, UTC+02:00)
I notice that the nuget package here does not include IKVM.Reflection.dll; I'm probably not the typical IKVM user, but I make lots of use of IKVM.Reflection - is there any chance of hosting that on NuGet? Heck, even as a separate package if necessary.
Marc Gravell
Friday, September 13, 2013 11:44:49 AM (W. Europe Daylight Time, UTC+02:00)
Marc, the ikvm nuget package is only for the ikvm runtime and class libraries, so it does not contain ikvmc and IKVM.Reflection.
I will consider creating an IKVM.Reflection nuget package.
Jeroen Frijters
Saturday, October 12, 2013 6:32:47 AM (W. Europe Daylight Time, UTC+02:00)
Excuse me, how did you find the memory model bugs on ARM? Did you actually encounter the bugs on ARM devices or you proved it in theory?
may
Saturday, October 12, 2013 10:20:42 AM (W. Europe Daylight Time, UTC+02:00)
The ARM memory model bugs were all known dependencies on the x86 strong memory model, not bugs actually encountered.
Jeroen Frijters
Name
E-mail
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview