From 54388304023426062f26a3b66fe403c6984bbfe0 Mon Sep 17 00:00:00 2001 From: Vaibhav Srivastava Date: Sat, 29 Aug 2026 11:27:35 +0530 Subject: [PATCH 1/2] docs: fix typo guarenteed -> guaranteed Signed-off-by: Vaibhav Srivastava --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index e1c08e856c..9727585c0d 100644 --- a/README.md +++ b/README.md @@ -181,7 +181,7 @@ The IKVM project recommends that people do not redistribute FOSS Java libraries Creating copies of FOSS Java libraries and publishing them to distribution mechanisms such as NuGet.org creates eco-system confusion and dependency conflicts downstream. We provide a system so that .NET users of Java libraries can reference those libraries directly out of the standard Java ecosystem mechanisms: Maven Central, etc though IKVM.Maven. Remember, very few libraries exist in a vacuum. Libraries often depend on dozens of other libraries. Two unrelated Java libraries often depend on the same underlying Java library. A complex method of dependency conflict resolution and version unification has to be involved in resolving this hierarchy for any individual downstream project. You are likely going to be introducing duplicate classes into the users of your versions, or causing your users to depend upon the wrong version of other libraries. -In addition to the above, we presently do not guarentee that API between statically compiled assemblies and the IKVM.Java and IKVM.Runtime libraries remains stable. A statically compiled assembly built against one version of IKVM is not guarenteed to run against a higher version of IKVM, even at the patch level. We would like to advertise better support for this in the future, but at present there is a lot of work planned for the IKVM.Runtime and IKVM.Java APIs that we don't want to inhibit. Since we also provide build tools to make the process of recompiling assemblies from the build machine easy, if recommendations are followed, this should be of limited impact. +In addition to the above, we presently do not guarentee that API between statically compiled assemblies and the IKVM.Java and IKVM.Runtime libraries remains stable. A statically compiled assembly built against one version of IKVM is not guaranteed to run against a higher version of IKVM, even at the patch level. We would like to advertise better support for this in the future, but at present there is a lot of work planned for the IKVM.Runtime and IKVM.Java APIs that we don't want to inhibit. Since we also provide build tools to make the process of recompiling assemblies from the build machine easy, if recommendations are followed, this should be of limited impact. There are exceptions to this advice, such as the library not being published to Maven. In that case, guidance would be to advocate that the original Java library in fact be published to Maven, or do the work yourself, as that is the appropriate place for Java libraries. From 79ac537ec200d29f953541ab2b98107859d97bbb Mon Sep 17 00:00:00 2001 From: Vaibhav Srivastava Date: Sat, 29 Aug 2026 11:28:10 +0530 Subject: [PATCH 2/2] docs: fix typo guarentee -> guarantee Signed-off-by: Vaibhav Srivastava --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9727585c0d..b8cea6ada5 100644 --- a/README.md +++ b/README.md @@ -181,7 +181,7 @@ The IKVM project recommends that people do not redistribute FOSS Java libraries Creating copies of FOSS Java libraries and publishing them to distribution mechanisms such as NuGet.org creates eco-system confusion and dependency conflicts downstream. We provide a system so that .NET users of Java libraries can reference those libraries directly out of the standard Java ecosystem mechanisms: Maven Central, etc though IKVM.Maven. Remember, very few libraries exist in a vacuum. Libraries often depend on dozens of other libraries. Two unrelated Java libraries often depend on the same underlying Java library. A complex method of dependency conflict resolution and version unification has to be involved in resolving this hierarchy for any individual downstream project. You are likely going to be introducing duplicate classes into the users of your versions, or causing your users to depend upon the wrong version of other libraries. -In addition to the above, we presently do not guarentee that API between statically compiled assemblies and the IKVM.Java and IKVM.Runtime libraries remains stable. A statically compiled assembly built against one version of IKVM is not guaranteed to run against a higher version of IKVM, even at the patch level. We would like to advertise better support for this in the future, but at present there is a lot of work planned for the IKVM.Runtime and IKVM.Java APIs that we don't want to inhibit. Since we also provide build tools to make the process of recompiling assemblies from the build machine easy, if recommendations are followed, this should be of limited impact. +In addition to the above, we presently do not guarantee that API between statically compiled assemblies and the IKVM.Java and IKVM.Runtime libraries remains stable. A statically compiled assembly built against one version of IKVM is not guaranteed to run against a higher version of IKVM, even at the patch level. We would like to advertise better support for this in the future, but at present there is a lot of work planned for the IKVM.Runtime and IKVM.Java APIs that we don't want to inhibit. Since we also provide build tools to make the process of recompiling assemblies from the build machine easy, if recommendations are followed, this should be of limited impact. There are exceptions to this advice, such as the library not being published to Maven. In that case, guidance would be to advocate that the original Java library in fact be published to Maven, or do the work yourself, as that is the appropriate place for Java libraries.