You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should expose Dotnet tool packages. Two obvious ones are ikvmc and ikvmstub. I do think we should go through with the remain to ikvmimp and ikvmexp at this point. Perhaps exposed as subcommands of a singleular tool: 'dotnet ikvm export', 'dotnet ikvm import', etc. Or some similar pattern.
Additionally, our JRE/JDK distribution, should be distributed as tools. This would make it easy for .NET users to install our JDK and just start using it.
'dotnet ikvm java', 'dotnet ikvm javac'. Etc.
The text was updated successfully, but these errors were encountered:
We probably should think through how we can make it a bit easier to specify things like IVKM.java, IKVM.Runtime and the BCL with these tools though. And whether any information that is available to us by being a dotnet tool can assist with that. Can we, for instance, actually deliver Framework reference assemblies with the tools? How do we deal with cross-tfm problems still? We still need a separate tool version for Framework.
We should expose Dotnet tool packages. Two obvious ones are ikvmc and ikvmstub. I do think we should go through with the remain to ikvmimp and ikvmexp at this point. Perhaps exposed as subcommands of a singleular tool: 'dotnet ikvm export', 'dotnet ikvm import', etc. Or some similar pattern.
Additionally, our JRE/JDK distribution, should be distributed as tools. This would make it easy for .NET users to install our JDK and just start using it.
'dotnet ikvm java', 'dotnet ikvm javac'. Etc.
The text was updated successfully, but these errors were encountered: