The IKVM.NET project has released version 7 of its implementation of Java for the Mono platform and Microsoft .NET Framework. This project, developed by Jeroen Frijters, is designed to bridge the gap between the JVM and the .NET platform. IKVM.NET provides the capability to run Java-based applications on .NET, and supports both Microsoft's .NET Framework and Mono 2.0.
The following components compose the IKVM.NET project:
A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries
Tools that enable Java and .NET interoperability
The latest release brings about several new features including a focus on incorporating support based on OpenJDK 7 b147 and Java 7 JVM changes. Selected improvements made since the previous release include:
- Java annotations on statically compiled code are now returned as java.lang.reflect.Proxy objects for compability with broken code that assumes this is always the case.
- Added delegate conversion for java.lang.reflect.InvocationHandler to ikvm.runtime.Delegates.
- Changed build and JNI code to use different names for the Windows x86 and x64 versions of the native dll.
- Retain reflection field ordering for ikvmc compiled code (not required by spec, but to improve compatibility with broken code).
- Interop between java.lang.AutoCloseable and System.IDisposable.
- Fixed java.io.FileOutputStream in append mode to use atomic append.
- Added -Xnoglobbing option to ikvm.exe.
- Implemented dual stack sockets (Windows Vista and up only).
- Implemented platform MBean server.
- Implemented SocketChannel.sendOutOfBandData().
- Implemented DatagramChannel multicast methods.
- Removed mapping of System.Security.VerificationException to java.lang.VerifyError.
- IKVM.Reflection: Massive enhancements to support a very large portion of the managed PE capabilities (much more than System.Reflection.Emit).
Release notes indicate that this release has been tested on both 32-bit and 64-bit versions of .NET Framework 2.0 SP2 and .NET 4.0 under Windows.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/dotnet-spa-templates-proxy/en/smallimage/ASP-NET-SPA-templates-proxy-changes-small-1683016303172.jpg)
/presentations/net-apps-cloud/en/smallimage/infoq-live-logo-small-1683100880551.jpg){kind=logo}
/articles/asp-dotnet-minimal-apis/en/smallimage/logo-1678972581766.jpg){kind=logo}
/articles/functional-dotnet-development/en/smallimage/Fsharp-vs-Csharp-is-one-more-functional-than-the-other-small-1676023056578.jpg)
/articles/dotnet-grpc-json-transcoding/en/smallimage/logo-1674822319367.jpg){kind=logo}
/articles/Dotnet-Seven-MSMQ-Alternatives/en/smallimage/logo-1670585778128.jpg){kind=logo}
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/open-source-java-profilers/en/smallimage/unleash-power-of-open-source-java-profilers-small-1681206807197.jpg)
/articles/rmi-to-websocket/en/smallimage/migrate-a-RMI-based-legacy-application-to-WebSocket-small-1680106723513.jpg)
/articles/rapid-startup-of-your-cloud-native-java/en/smallimage/logo-1680293937095.jpg){kind=logo}
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/articles/series-apache-kafka-streams/en/smallimage/apache-kafka-article-series-logo-small-1673455781546.jpg){kind=logo}
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/secure-kafka-cluster-strimzi/en/smallimage/securing-a-kafka-cluster-in-kubernetes-using-strimzi-small-1671647644310.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
Community comments
Let's ask the obvious
by M Vleth,
Re: Let's ask the obvious
by Jonathan Allen,
Re: Let's ask the obvious
by ryan martin,
Re: Let's ask the obvious
by Matej Tymes,
Re: Let's ask the obvious
by peter lin,
Subject
by Lyndon Samson,
Let's ask the obvious
by M Vleth,
Your message is awaiting moderation. Thank you for participating in the discussion.
Why would you ever want to run Java code on the CLR? What's the practical use here?
Re: Let's ask the obvious
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
IKVM is offered for the same reason the CLR has p/invoke and COM interop, specifically that it is easier than porting some random Java library that your .NET or Mono application needs.
Re: Let's ask the obvious
by ryan martin,
Your message is awaiting moderation. Thank you for participating in the discussion.
Perhaps to utilize libraries/frameworks that have no .net counterpart and would take too long and cost too much to implement?
Re: Let's ask the obvious
by Matej Tymes,
Your message is awaiting moderation. Thank you for participating in the discussion.
For example it was used for porting scala to CLR.
Subject
by Lyndon Samson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think it's used for port of the SAXON XSLT/xquery engine to dotnet.
Re: Let's ask the obvious
by peter lin,
Your message is awaiting moderation. Thank you for participating in the discussion.
I used IKVM so that I could use Java's concurrent libraries in the past. This was before microsoft released .Net's concurrent libraries. Sometimes it is very handy and IKVM is a solid project. I've been following it for many years. The author of IKVM has submitted many bug reports to Microsoft, so it has helped make .Net better.