search

microsoft / vsminecraft

Visual Studio extension for developing MinecraftForge mods using Java.
Other
194 stars 25 forks source link

Request: Add support for other development stacks #16

Closed BrainSlugs83 closed 9 years ago

BrainSlugs83 commented 9 years ago

It would be awesome if there was support for .NET based Minecraft mods (specifically, C# -- but other stacks like Python, Ruby, and even JavaScript might not be so bad either).

There are already tools available that will let you JIT JavaScripts at runtime and run them directly on the JVM.

There's the Jython project to run Python on the Java platform.

As for .NET, there are tools that go the other way, Java->.NET (like IKVM), and there are tools that take .NET and convert it to JavaScript as well (JSIL is one that some commercial games use -- it cheats for things that Java/JavaScript doesn't support -- like for structs -- it passes a manually made copy for example).

Anyway, with Roslyn, maybe .NET (or C#?) could be made to output Java Byte code (or perhaps MS could just make a third party tool that just converted the CIL to Java Byte code -- a tool like this is long over due).

An alternate approach could be to run the code out of process (the latest .NET is supposed to be portable, open source, and cross platform -- you can package it up with your code if you need to and deploy it -- no need to have it be "installed").

I get that it may be out of scope for this project -- but if there's anyone at Microsoft or Mojang listening that has the ability to make something like this happen -- this is super wanted. :-)

hanetzer commented 9 years ago

No.

BrainSlugs83 commented 9 years ago

Okay.

sharwell commented 9 years ago

@BrainSlugs83 Thanks for taking the time to write a well-thought-out post on this issue. :smile: From my perspective, this would be a cool feature from an education perspective, but has a large downside regarding cost of implementation that would take time desperately needed by other features ranging from improving the project system to addressing bugs found in the debugger. Since this is an open source project, no one is going to stop a contributor from working on this feature. However, based on my experience in open source development I wouldn't count on this happening soon.

mluparu commented 9 years ago

This project actually is a good example of Java-to-.NET out-of-process communication - take a look at its source code. It uses protobuf over pipes for VS to communicate with Eclipse. Someone could use the same mechanism to establish a MinecraftForge mod-to-.NET process communication. The only challenge is that Java can't create named pipes so you'll need to start them from the .NET process.

I don't think however that such a MinecraftForge-to-NET OOP mod fits in this project though. But if someone else creates it, I'll be happy to help them publish the mod as a MMDP Sample in VSGallery :)

sharwell commented 9 years ago

The debugger uses an in-process DLL written in C# as well, that communicates with the JVM using its native API. A shim layer written in C++ sits between the Java and C# code. A similar configuration could theoretically be invoked from within Java code, but it would still be difficult to make sure all the Java APIs were correctly exposed in the C# side.

BrainSlugs83 commented 9 years ago

No, thank you -- for the well thought out responses! -- I think something like this would need larger support from Microsoft to get it right (hence the last line of the original request) -- or some people with a heck of a lot of free time, anyway.

Regarding Java<->.NET communication is there a cross platform way to do it? (Something that will work with Linux and Mac OS as well? -- It would be good if everything still got packaged up as a jar that forge could load... -- even if it secretly used a .NET DLL that was packed in, and a redistributable mini version of the framework...)

As far as thinking realistically goes, I think I might be better off just hacking in support for the things I really want into an OSS Java compiler (or perhaps making a preprocessor); that would essentially add syntactic sugary things from C# -- like delegates, properties, lambdas, regions, and extension methods, default values, etc... (it would be nice to fix the typing/generics system, but the issues there, especially with type erasure, etc. -- that'll take more than just syntactic sugar to fix.)

I have a few other ideas (honestly, would be great if Roslyn could just compile to .jar), but I think the preprocessor is the most realistic...

Also, @mluparu, thanks for the offer -- I may take you up on that.