Releases: ikvmnet/ikvm
8.10.3
8.10.2
8.10.1
8.10.0
Upgrade to JDK8u422-b05. This is the current JDK8 release. We are now, after years, up to date.
What's Changed
- Upgrade to JDK8u312 by @AliveDevil in #550
- Remove pre-Roslyn Workarounds by @wasabii in #551
- Generate JDK source and data by @wasabii in #554
- Generate Nashorn code from source by @wasabii in #555
- Corba Source Generation by @wasabii in #557
- Move openjdk/ and jtreg/ submodules into ext/ by @wasabii in #560
- JDK8u412-b07 Upgrade by @wasabii in #561
- Launcher unable to find class by @wasabii in #565
- Upgrade to JDK8u422-b05 by @wasabii in #566
- IKVM.ByteCode 8.11.0 by @wasabii in #573
- IKVM.ByteCode Refactor by @wasabii in #574
Assembly.Locationmight return an empty string. by @Fabian-Schmidt in #576
New Contributors
- @Fabian-Schmidt made their first contribution in #576
Full Changelog: 8.9.1...8.10.0
Contributors
Assets 206
8.10.0-pre.1
What's Changed
- Upgrade to JDK8u312 by @AliveDevil in #550
- Remove pre-Roslyn Workarounds by @wasabii in #551
- Generate JDK source and data by @wasabii in #554
- Generate Nashorn code from source by @wasabii in #555
- Corba Source Generation by @wasabii in #557
- Move openjdk/ and jtreg/ submodules into ext/ by @wasabii in #560
- JDK8u412-b07 Upgrade by @wasabii in #561
- Launcher unable to find class by @wasabii in #565
- Upgrade to JDK8u422-b05 by @wasabii in #566
- IKVM.ByteCode 8.11.0 by @wasabii in #573
- IKVM.ByteCode Refactor by @wasabii in #574
Full Changelog: 8.9.1...8.10.0-pre.1
Contributors
Assets 206
8.9.1
8.9.0
This is the biggest update to IKVM since our initial 8.2 release. The largest and most impactful change is the removal of most of the C# implementations of the OpenJDK backend classes. We no longer run our own implementations of NIO, network support, process launching, etc. Intead we are making use of the OpenJDK C code directly.
A consequence of this is that we now deliver platform-specific versions of IKVM.Java.dll. Four versions are available: Windows, Linux and OSX and a single reference-assembly. Users of the NuGet package should have this handled automatically: for RID-specific deployments the NuGet infrastructure will copy the appropriate version of IKVM.Java to the output directory. For RID-agnostic deployments, all three will be copied into runtimes/{rid}/lib and selected at runtime by .NET. For Framework targets, only the Windows version will be output.
This is unobtrusive for users of our IkvmReference implementation. The reference assembly is used to compile Java code against. And then at runtime the appropriate IKVM.Java implementation is included. The appropriate ikvm/ image directory is copied to the output as well.
However, for users not using NuGet and PackageReference, management of the reference assemblies falls to them. ikvmc should be run specifying the reference-assembly. And then only the appropriate runtime assemblies should be distributed with the application. This isn't unlike manually using csc.exe to compile .NET code at this point: you have to pick the appropriate reference assemblies. However, that is left as an exercize to the user.
This is also our first IKVM release in which we have enabled native-AWT. We include AWT support directly from the OpenJDK C code. We know there are bugs in this: On Windows we've observed Chinese-looking fonts periodically. And we know OS X support doesn't quite work right. This enables a lot of scenarios, but there are still bugs to be worked out. However, AWT is better than no-AWT.
What's Changed
- Platform Specific IO, Security, Base Libs by @wasabii in #521
- Native AWT by @wasabii in #528
- README typo by @Sinan-Karakaya in #533
- Linux CI Build by @wasabii in #532
- Update to jdk8u192-b26 by @wasabii in #500
- win-x86 test suites by @wasabii in #456
- Upgrade to jdk8u275-b01 by @wasabii in #534
- Add osx-arm64 tests by @wasabii in #537
- Remove bin artifact drop. This doesn't quite work as easily now that we have 4 versions of IKVM.Java. Users are expected to get the appropriate version(s) out of NuGet if they need the assemblies directly.
- Remove image artifact drop. Replace with jre and jdk images.
- Split IKVM.ByteCode out and reduce package size.
New Contributors
- @Sinan-Karakaya made their first contribution in #533
Full Changelog: 8.8.1...8.9.0
8.9.0-pre.3
This is the biggest update to IKVM since our initial 8.2 release. The largest and most impactful change is the removal of most of the C# implementations of the OpenJDK backend classes. We no longer run our own implementations of NIO, network support, process launching, etc. Intead we are making use of the OpenJDK C code directly.
A consequence of this is that we now deliver platform-specific versions of IKVM.Java.dll. Four versions are available: Windows, Linux and OSX and a single reference-assembly. Users of the NuGet package should have this handled automatically: for RID-specific deployments the NuGet infrastructure will copy the appropriate version of IKVM.Java to the output directory. For RID-agnostic deployments, all three will be copied into runtimes/{rid}/lib and selected at runtime by .NET. For Framework targets, only the Windows version will be output.
This is unobtrusive for users of our IkvmReference implementation. The reference assembly is used to compile Java code against. And then at runtime the appropriate IKVM.Java implementation is included. The appropriate ikvm/ image directory is copied to the output as well.
However, for users not using NuGet and PackageReference, management of the reference assemblies falls to them. ikvmc should be run specifying the reference-assembly. And then only the appropriate runtime assemblies should be distributed with the application. This isn't unlike manually using csc.exe to compile .NET code at this point: you have to pick the appropriate reference assemblies. However, that is left as an exercize to the user.
This is also our first IKVM release in which we have enabled native-AWT. We include AWT support directly from the OpenJDK C code. We know there are bugs in this: On Windows we've observed Chinese-looking fonts periodically. And we know OS X support doesn't quite work right. This enables a lot of scenarios, but there are still bugs to be worked out. However, AWT is better than no-AWT.
- Platform Specific IO, Security, Base Libs by @wasabii in #521
- Native AWT by @wasabii in #528
- README typo by @Sinan-Karakaya in #533
- Linux CI Build by @wasabii in #532
- Update to jdk8u192-b26 by @wasabii in #500
- win-x86 test suites by @wasabii in #456
- Upgrade to jdk8u275-b01 by @wasabii in #534
- Add osx-arm64 tests by @wasabii in #537
- Remove bin artifact drop. This doesn't quite work as easily now that we have 4 versions of IKVM.Java. Users are expected to get the appropriate version(s) out of NuGet if they need the assemblies directly.
- Remove image artifact drop. Replace with jre and jdk images.
- Split IKVM.ByteCode out and reduce package size.
Full Changelog: 8.9.0-pre.2...8.9.0-pre.3
Contributors
Assets 207
8.9.0-pre.2
- Remove bin artifact drop. This doesn't quite work as easily now that we have 4 versions of IKVM.Java. Users are expected to get the appropriate version(s) out of NuGet if they need the assemblies directly.
- Remove image artifact drop. Replace with jre and jdk images.
Full Changelog: 8.9.0-pre.1...8.9.0-pre.2
8.9.0-pre.1
What's Changed
- Platform Specific IO, Security, Base Libs by @wasabii in #521
- Native AWT by @wasabii in #528
- README typo by @Sinan-Karakaya in #533
- Linux CI Build by @wasabii in #532
- Update to jdk8u192-b26 by @wasabii in #500
- win-x86 test suites by @wasabii in #456
- Upgrade to jdk8u275-b01 by @wasabii in #534
- Add osx-arm64 tests by @wasabii in #537
New Contributors
- @Sinan-Karakaya made their first contribution in #533
Full Changelog: 8.8.1...8.9.0-pre.1