.net core support? #3
Comments
|
We have not. But it's the same IKVM as before with 1 very small bug fix so it should be the same answer as the main IKVM branch. Which I believe is - it doesn't run on .NET Core. |
|
Hello! Do you have intention to port IKWM.net to Net Core in the future? |
|
We also would love to see it ported to .NET Core. Unfortunately we don't have the resources to do so at present. Have you considered doing it? |
|
Actually IKVM is almost 100% compatible with Core/Net.Standard (based on api analyzer tool). You can add those assemblies to core project. IKVM.OpenJDK.dll rely on one of the constructors of System.IO.FileStream which is not ported to core, which seemed to be the only major dependency. I opened an issue with corefx to add it. IKVM.Runtime.dll has references to several methods from System.Reflection.Emit (see below). Any Idea what Emit API is used for in IKVM? All other assemblies seemed to be 100% compatible.
|
|
FYI, I am looking into seeing if I can build IKVM against .NET Standard 2.0 (so that we can use it from both .NET Framework and .NET Core) and while solving some of the issues, it seems not all have a proper solving. Truth be told, I'm doing this on an older version for now (java 6-based): 0.46. I saw some commits in the master branch that tried to enhance the .NET Standard support/ The reflection parts can be easily solved by using the System.Reflection NuGet packages. |
|
|
If anyone is interested, I've created a branch in my fork of IKVM trying to get things running with .NET Core: https://github.com/ams-ts-ikvm-bag/ikvm/tree/nant_build_net_core Some usages of the not available CTOR of Additionally I found that some cases breaking the UWP-app are code which is specially targeting .NET 4.0, so I simply undefined using that in the build files and got some more compatibility. At some places it's difficult to decide why things have been implemented specially for 4.0 as the GIT-history lacks details, code simply occurs. This allowed me to run my PoC of a Java-lib reading YAML files, parsing some data, using Google Guava-caches and stuff successfully in the end. |
|
@ams-tschoening Very interesting. Any chance you can publish binaries? |
|
I've added a branch, but consider this completely internal work for now. I will surely reorganize things to better fit my needs. Not even sure about tracking things in those repos at all in the long term, the formerly main intention for the repos was to simply backup everything I could find regarding IKVM. https://github.com/ams-ts-ikvm-bag/ikvm-bin/tree/ts_build_net_core |
|
Just tested webclient and jdbc, and both are working now under .net core 2, fantastic! @jollescott @fanoI @timotei can you test your stuff too? |
|
@mikeTWC1984 I am focusing on .NET Standard generation (which seems more tricky than .NET Core), but I will give it a try :) So far I managed to get all (most?) of the IKVM.Runtime compile against .NET Standard, but the generation of the OpenJDK.*.dll seems a bit more trickier to get right since netstandard.dll references has either incomplete types definition or type forwarding, thus linking it with mscorlib/System.runtime directly. I'll publish what I did so far on my fork this week maybe. |
|
OK, good. I also tested updated IKVM on WSL and linux container and it works too ( yay:) ), so it's sort of netstandard already. Maybe we should consolidate all these updates and send PR on this repo |
How did you do that? I simply reused the builds available for NAnt and wasn't able to address anything else then .NET 4. The project files for Visual Studio don't seem to target .NET Standard as well.
I would prefer using a repo containing all the history of the original project as targets of PRs and asked to to change that. Other opinions? |
|
@ams-tschoening Agreed. Probably it make sense to have a separate fork that would focus on core/netstandard compatibility. You kind of created one already, let's see what @timotei got. |
|
Depending on what wwrd says, we might consider simply creating a new organization for IKVM and fork the repos of interest from mine into that. If necessary at all, customized forks for .NET Core vs. other focus/implementations could easily be created within that than. Which I don't see necessary currently, though. I won't have time to get too much involved into IKVM, so suggest that the organization is managed by others, like you or wwrd in the end. I only would like to see my work converting the repo not only useful for me. :-) Any good orga-names in mind already? I suggest following the discussion in #11 as well. |
I've deleted the old branch and created new ones, better named to (hopefully) not care about anymore for now. This one contains the fixes of wwrd as well, but I pretty sure to not maintain it intentionally. https://github.com/ams-ts-ikvm-bag/ikvm-bin/tree/net_core_compat |
|
Speaking for Windward our primary goal is to have a single repo everyone works on going forward. Having IKVM split into distinct repos would be very harmful for it's future. On having a repo with more history, not an issue for us. But we are not opposed to it so fine with whatever the rest of you prefer. We're also fine if we use someone else's repo and they own it. We only did this because no one else did. If we use another repo, we have 2 bug fixes in our repo and those need to be added to your repo if we make that the new main repo. And we, along with you, need to get this to be .NET Core compatible. We were going to start in about 6 months and so we're thrilled if you all do it sooner. |
|
Regarding compatibility, after @ams-tschoening fixed the FileStream CTOR issue, looks like many jars can be ported to core now. Below is the list of missing methods (besides those in Reflection.Emit). They probably are not critical. I think we might need focus on testing now. I already tested some jdbc, I'm going to try BouncyCastle (encryption library) and HtmlUnit (headless browser) some time soon. |
|
My current work is available here: https://github.com/Itiviti/ikvm/tree/v0.46-netstandard Please note it's not in any way a "production" version yet, just want to get my foot in the door to see if .NET Standard is even viable, or we need to be either .NET Framework/.NET Core |
|
There's an new repo for IKVM now: https://github.com/ikvm-revived/ikvm I suggest you fork this, create a branch based on master and integrate your changes from your former repo into that new branch by cherry-picking. Just make your repo a remote for the new fork. I tried that already and ran into various conflicts which make me believe you might not have based your work on master of your repo or I simply don't understand it enough. :-) I didn't understand how your branch If you think it might be of help I could push my branch, but I didn't even ran The overall goal should be to create a branch called |
|
Just want to add some notes that Reflection.Emit seems to be supported in .NET Core 3.0 again:
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-3/
Maybe you want to give your formerly mentioned API-analyzer an additional try? |
|
FYI, managed to compile everything (the IKVM.OpenJDK.*.dll) for .NET Standard and it seems work fine for some really basic tests I did :O I will push the rest of the work soon in the branch. It's also very hackish method to generate them, but hey, it works I guess. @ams-tschoening The portability tool is here: https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer Oh, and missed some earlier messages:
I had to update nant's config to use the new compiler paths, will share soon (this week hopefully, as I am wrapping up everything for anyone outside to be able to use it). |
|
@ams-tschoening I ran it recently, and didn't see the change. The namespace itself (Reflection.Emit) was there, but missing some methods/ctors. Below is the list. Not sure if the anything from that list was added on the most recent release, I'll do some analysis later.
|
|
@timotei if you can attach binaries I'll run some tests I ran before for "Core" version |
|
Btw, what I did was to reference some System.* nuget packages like: https://www.nuget.org/packages/System.Reflection.Emit/ Then we'd get them just fine even if they're not in netstandard. You can even see some types are specified as ".NET Standard Platform Extensions" = "netstandard + those extra NuGet libs" |
|
I think I was exploring that nuget, and missing methods were not there. From the other hand it's probably just used while converting dll to jar or otherwise, and in this case there is no really need to port it |
|
I just did a quick test - removing IKVM.Runtime.dll is not affecting code that uses converted jars and OpenJDK dlls, but crashes ikvmc while converting jar to dll. So I guess jar conversion is the only purpose of that Runtime.dll assembly and we shouldn't bother about missing Emit namespace types/methods, as long as we have access to a Windows machine with .net 4x. |
|
That sounds like something we should explicitly document somewhere, e.g. in the wiki of the newly created organisation: https://github.com/ikvm-revived/ikvm/wiki Copying the wiki-contents from Sourceforge over might be an idea as well. Doesn't seem to be that much anyway: |
|
@timotei I'm new to IKVM and trying to use some Java libraries in a .Net Standard project |
|
@marshallcoco Your question seems off-topic here and is more about general usage. As there's currently no mailing list infrastructure or such, I suggest you ask your question on Stackoverflow and/or in the new IKVM-organisation. Especially SO can still be used, because it has IKVM-tags and some people are still using it and reading there. But in any case you should be more detailed about what exactly you did with which version of IKVM from where and about the exact error messages you get. Otherwise nobody will be able to help you. Most of the published docs are still valid as well: https://www.ikvm.net |
|
Hi all; Ok, we (Windward) now need to get our stuff working on .NET Core. @timotei & @ams-tschoening, what can I do to get all of your changes into our branch? And whatever is left, I'll port over. Also we have extensive unit tests of our libraries (we run all the JUnit tests on the .NET code too). So our tests are a pretty thorough test of IKVM itself. Anyways, get me your changes and I should be able to turn this all around in a week. And thank you both so much for the work you've already done. I've sent both of you invites to give you read access to the project. ps - We're aiming at .NET Core 3.1, not earlier. Is that an issue? |
You should clone https://github.com/ikvm-revived/ikvm and base you work on that. That includes all your customizations not included in IKVM before (
There are .NET Core+UWP-app related PRs already as well, in some of which I document what CN1 did in their fork to support UWP-apps in the past. Additionally, some forks already base their work on that repo instead of yours. This might give the new organisation an additional boost to become the one new entry point for IKVM. |
|
@ams-tschoening Reading through the work in https://github.com/ikvm-revived/ikvm it looks like the only new stuff is our changes (wwrd_fork) and yours (net_core_compat & vs_19_build). And they're distinct branches so it doesn't have both. Are you opposed to my bringing your net_core_compat changes over to here and moving forward on this project? And if so, should I bring the vs_19_build changes over too? Or should we merge all three into ikvm-revived and then merge that into master. And do you or I have permissions in the project to push to the master branch? |
That was by purpose to make using
I won't do that, but instead focus on working with So, I would prefer if you do the same and fork the repo of https://github.com/ikvm-revived/ikvm/network/members
That branch is not strictly related to .NET Core, but instead I tried to get things to work with Visual Studio only to make development faster and reduce turnaround times. Needed to stop at some point, but might be of interest to others as well.
We both have, all members of |
|
@ams-tschoening I'm good with our switching to ikvm-revived if we can merge the wwrd_fork and net_core_compat into the master branch. And I'll then work on completing the .NET Core work. We want to have a single IKVM that builds .NET Standard. So it creates a single DLL that will run on both .NET Framework & .NET Core. In addition we need to get it up on NuGet. At present the only IKVM on NuGet is the original, one by qCat, and Windward's. What/how do you propose doing this as well as keeping the private signing key confidential? |
Reads reasonable to me.
I have absolutely no idea and experience with NuGet and this might be better discussed in an existing issue. |
FYI - the original maintainer of IKVM requested that if someone take over the project, that the name be changed. Maybe calling it
Agreed. So long as you plan to target .NET Standard 2.0. |
We're targeting .NET 3.1. I don't think it's worth the extra effort to work on 2.0 when everyone will be on 3.1 by the end of this year. |
.NET Standard 2.0 is the best option to have a single-targeted library. .NET Standard 2.1 doesn't support .NET Framework. Having a direct .NET Core 3.1 target as well is okay if it makes sense for performance or compatibility reasons. But targeting NET Core alone would mean that all of the other platforms in the .NET ecosystem (.NET Framework, UWP, Unity, Mono, Xamarin, etc.) would have no support. It would be a real shame to get all of this working only for .NET Core to the exclusion of all other platforms. Or have to target the original IKVM library and this one in order to support both .NET Framework and .NET Core, which would be a bad experience for library developers. |
Maybe I misunderstand but if the .NET portability analyzer says the code I build with VisualStudio is compatible with .NET Core 3.1, then we're good on .NET Framework 4.6.1 and we're good on any platform supporting .NET Core 3.1. That will be producing a single DLL that will run on both - correct? |
Doesn't at least UWP uses .Net Core as well? Otherwise I wouldn't have run into trouble at all. |
I haven't tried .NET portability analyzer, but given the fact that IKVM already runs on .NET Framework and the tool says it will support up to .NET Core 3.1, there should be no issue with creating a single-targeted .NET Standard 2.0 library that will run on both .NET Framework 4.6.1+ and .NET Core 2.0+. I haven't looked at the source, though. There may be a little bit of grunt work to get there. But if you want a single target that can support all current platforms as well as .NET Framework, then .NET Standard 2.0 is the best choice. Keep in mind, the idea for library development is to support the lowest version you can, so you get as much coverage as possible. That said, there is practically no reason to support .NET Standard 1.x anymore.
Just so we are clear, .NET Core and .NET Standard were released together. .NET Core is a runtime. .NET Standard is not - it is simply a way to target multiple runtimes, and it is a replacement for Portable Class Libraries. While I haven't ever setup a UWP project, it would seem according to this UWP document that your only 2 choices are targeting UWP directly and targeting .NET Standard. It may be possible to target .NET Core and run on UWP (just like it is possible to target .NET Framework and run on Mono), but if it is, it certainly isn't the normal way to do it :) If you take a look at the up-to-date packages on NuGet.org, you will note most of them target .NET Standard 2.0 if they are single-targeted. And .NET Standard is usually included if they are multi-targeted. BTW - no objections if you want to multi-target - it is actually much easier than it used to be to get that done. I'd be willing to make a contribution if it helps. |
|
@DavidThi808 Are there any updates on your effort to create a single repo and nuget package for a .NET Standard 3.1 compliant IKVM? There is a large community of IKVM users that will benefit from the work that you are doing. |
|
We're making progress. |
|
@timotei I used your binaries for .netstandard as per this comment .But when i am converting the jar to dll i am getting |
Following. Any Updates? Looking at Repo now for recent updates. I haven't pulled yet, but are the updates from 5 months ago workable? TIA! |
|
The most current thread about most current code is most likely the following: |
|
Was this work transferred over to IKVM-revived? It's a bit of a shame because IKVM-revived is a strange repo. There's no readme file over there, and it looks like .NET Core support just sort of hangs out on its own branch, completely independent of work done by others. I'm not sure what to make of it, really. |
That depends on what "this" work is for you. A lot of comments are simply about my branch
There is, because I merged things coming from WWRD as well: https://github.com/ikvm-revived/ikvm/blob/master/README.md
Because it is/was work done independent of any other work done LATER. So you simply have the choice which of the available work you look at and try to get things running for your project. |
|
All, I was wondering which github repo and discussion thread is the latest one to track the progress of this project? Thanks. |
|
I agree with @qwertie, the current situation seems a bit chaotic. Not being heavily involved in the code it's at least difficult to understand what's going on. We have windward-studios/ikvm8 as well as windward-studios/ikvm where .NET Core compatibility is absent and whose Then we have IKVM-Revived with no obvious connection to this repository (it's not forked from here) and with a I understand that this is hard work, but there seem to be quite a few people working on this. From the outset, the main problem appears to be a loss of clear direction as well as where and how to cooperate. If what @NightOwl888 writes in #3 (comment) is correct, the name Either way, I kindly ask you all to please collect your efforts around a single default branch in a single repository and make it the "official" community effort where we can pour all of our resources into getting a .NET Core or .NET 5 compatible IKVM alternative up on its feet. 🙏🏼 If you need any assistance in the managementarial aspects of setting this up, please let me know. |
|
Thanks for pointing out how confusing this is. I don't know everything going on with this project, but I do know that the effort to maintain it has been consolidated at ikvm-revived. I have added ikvmnet/ikvm#40 to clarify this. @DavidThi808 - it would be helpful if you pin an issue at the top of the issues list and/or update the docs for this repo to reflect that the official effort has moved, so any potential contributors know where to focus their efforts. The fact that this repo was never merged to ikvm-revived is a bit of a mystery to me (and is certainly cause for confusion). How do we know whether the patches applied here were applied to ikvm-revived? Another thing that is confusing is the fact that ikvm-revived doesn't have a package on NuGet.org yet (which is why I added the above issue to clarify what is blocking that). But we definitely need some more contributions to get there. |
WWRD and ikvm-revived started with different repos, because I found it important to have the original history and therefore created my own forks. Though, when doing so, I wasn't even aware of WWRD and this discussion, recognized it only afterwards and made my fork available as ikvm-revived. There's a PR containing all the changes applied by WWRD: |
|
The dll that can be operated on the .net core app 5.0 Can I get it through jar?
thank you |
|
You need to give
|
Hi, just wondering if you have done any testing on .net core yet?
The text was updated successfully, but these errors were encountered: