# Monday, 07 December 2009
« IKVM 0.42 Release Candidate 3 | Main | IKVM 0.42 Released »
New Development Snapshot

The 0.42 release still isn't done, but in the mean time, development of 0.43 continues.

Changes:

  • Fixed interface method resolution (via JNI) and various other minor JNI method resolution compatibility tweaks.
  • When there is no Java code on the stack JNIEnv->FindClass() should use the system class loader instead of the boot class loader.
  • Removed micro optimization that requires full trust on .NET 4.0.
  • Removed .NET 4.0 workaround.
  • Renamed ILGenerator.__GetILOffset() to ILGenerator.ILOffset to match with .NET 4.0.
  • More AWT fixes by Volker
  • Added support for adding "new-style" declarative security (i.e. .NET 2.0 compatible) to IKVM.Reflection.Emit.
  • Various minor optimizations
  • Added a couple of missing classes (that tools.jar depends on).
  • Removed classes that aren't supposed to be in the boot class path (they're from tools.jar). This includes the entire IKVM.OpenJDK.XML.RelaxNG assembly.
  • Created IKVM.OpenJDK.Tools.dll (which is going to be the equivalent of tools.jar).
  • Fixed IsPackageAccessibleFrom to consider class loaders, instead of InternalsVisibleToAttribute
  • Added automatic access to internal accessibility members across assemblies in multi target compilation (previously this was only done for -sharedclassloader scenarios)
  • Cleaned up existing field access stubs (now known as "type 1") and added type 2 access stubs to make public fields that have a non-public field type accessible.
  • Moved FindMainMethod from ikvm.exe into runtime, to avoid the need for hacks (to avoid NoClassDefFoundErrors).
  • Deleting of an non existing Preferences Key should not throw an exception.
  • Type export map performance bug fix by Eyal Alaluf. AssemblyName doesn't implement Equals/GetHashCode and this caused the map to contain an assembly entry for every type.
  • Added IKVM_EXPERIMENTAL_JDK_7 environment variable to enable loading Java 7 class files. Note that no JDK 7 functionality has been implemented yet.
  • Mangle all artificial type names if they clash with Java type names in the same assembly.
  • Added two constructors to ThowsAttribute that take a Type and a Type[] for greater convenience when applying the attribute to user code and for compatibility with Grasshopper's ThrowsAttribute.
  • Various minor reflection optimizations.
  • Don't automatically hide Java "op_Implicit" methods (marked with SpecialName). Instead mark the ones we automatically generate with HideFromJavaAttribute.

Binaries available here: ikvmbin-0.43.3628.zip

Monday, 07 December 2009 09:06:05 (W. Europe Standard Time, UTC+01:00)  #    Comments [1]
Saturday, 19 December 2009 13:23:50 (W. Europe Standard Time, UTC+01:00)
Hi and thanks for your interesting work.
We are developing an app in C#.net which use a open source library (C++ and Java version available). Before finding IKVMC, we create a wrapper around C++ dlls which was a very hard work, but now we can use Java edition freely.
But we encounter a strange problem: in one computer the JAR successfully converted to .net dll and all things work fine, but in another computer does not!
an "Environmental Variable" sets in both computers (i.e. Path).
the conversion code: IKVMC -target:library jarFile.jar
the runtime error in the second computer only happened in debugging time (VS2008)!!! and when the compiled application run from O.S. all things work fine again :O
the Error is: IKVM.Runtime.JNI.Frame.Leave()
ps: we check the ClassLoader parameter with to different setting: AppDomain and SharedClassLoader but nothing changes
thanks in advance
AliPST
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