We Want to Run Our C# Code on the JVM
My company has a large C# code base. Well over half of this code is our core engine for creating, reading, modifying, calculating and writing Excel workbooks. We frequently get questions from customers and potential customers asking whether we are going to build a Java version of our engine - many of them are not at all interested in the UI. We even have a few customers who have taken the trouble to use our .NET library from their Java applications.
So, we would like to build a Java version of our core engine, ideally without maintaining a separate Java source code base.
Eric Sink described this problem very well. I am in a similar position except for the fact that our software license includes royalty free deployment, making Eric's choice of Mainsoft a nonstarter for us.
I have been Googling the likes of "c# to jvm" every few months for several years now with no joy. Having spent ~7 years developing similar software for Java, I am confident that the .NET APIs we use in our core engine could easily be encapsulated and we could accomplish everything we need using the Java libraries. So, if we only had a C# -> JVM compiler we could build our core engine for Java and we would no longer have to turn away Java developers who would like to use it.
I am not asking for the technical reasons why Sun does not do a C# compiler. I recognize that Java has no properties or an unsigned 64 bit long, etc... For the sake of argument, just assume that all of these technical issues could be dealt with by extending the JVM and / or other means.
And I am not asking for yet another debate on why one language / stack might be better than the other. The reality in our business is that there are plenty of potential customers using each.
Why Should Sun do a C# Compiler? (IMO of course)
Making it easier to run C# code on the Java platform means more developers and more software for the platform. Is there anything more important to the success of a platform? Jonathan Schwartz is a software guy. I will leave it to others smarter than me to decide whether or not he took on an impossible job as President and CEO of Sun, but having met with Jonathan shortly after he joined Sun my impression is that he understands software and the need for a large base of developers.
So Why Doesn't Sun do a C# Compiler?
NIH syndrome?
The ghost of Scott McNealy?
Too many Java developers dislike or distrust anything related to Microsoft?
They agreed not to as part of taking the big bucks?
???
There must be a good reason. I just cannot for the life of me figure out what it is...
Firstly Sun has zero incentive to implement a C# compiler on the JVM because they have something very similar called the Java programming language.
Its also not really as simple as just implementing a compiler as the Java standard class libraries are not the same as the .net Base Class Libraries. You would end up having to change all the .NET API calls to Java API calls.
Micrsoft had a product called J# which was meant to be for Java to .NET conversion but in the end no one used it as the API was limited to pre Java 2 API so it was mostly useless. It would be the same if Sun implemented parts of the .NET BCL, as only the core portions of it are standardised and royalty free. Parts like ASP.NET and WPF, WCF etc are not part of the ECMA standards and so Sun would need Microsofts permission to implement those API's.
If enough customers want a java version to make business sense to port your application to java then do it, you just wont ever get any help from Sun via a C# to JVM compiler.
Joe Erickson wrote:
Making it easier to run C# code on the
Java platform means more developers
and more software for the platform.
This is an untrue statement. Running C# code on the JVM does not create Java programmers, it creates C# programmers who can execute on a JVM. It only expands the reach of C#, assuming the JVM also translates any microsoft specific calls (i.e. win32) into something that is platform neutral. So if Sun translates IL to Java Bytecode, the only group it helps is: Microsoft. And, given Sun's history with Microsoft during the original C#-Java schism/Visual J++ lawsuits...
Plus, you have to face the technical infeasibility, whether you want to or not. There are fundamental differences in the way the bytecodes are executed that are far more important issues than whether or not there's an unsigned long datatype.
If you must have C# on a non-Microsoft platform, use Mono
Why doesn't Microsoft do a C# to Java byte code compiler? Why don't you do it? There are open specs on each side...
"So, we would like to build a Java version of our core engine, ideally without maintaining a separate Java source code base."
Basically, you want to compile your C# code unmodified, and have it run in a Java-only environment.
IKVM is not what you want. IKVM is three main things.
a. ikvm - CLI implementation of a Java virtual machine (note that this uses Classpath (now OpenJDK) for the Java class library).
b. ikvmc - Compiles java bytecode to CLI bytecode.
c. ikvmstub - Generates java stub classes that call CLI code.
Note that all of these tools depend on CLI at runtime. What you want is exactly the opposite of IKVM, which is of course MVKI (Most Venerable Kompiler Intermediary) :):
a. mvki - Java implementation of a CLI virtual machine (presumably this would use Mono or DotGNU for the class library).
b. mvkic - Compiles CLI bytecode to Java bytecode.
c. mvkistub - Generates CLI stub classes that call Java
Note that none of these would require an existing implementation of the .NET Framework at runtime, so they should be satisfactory to your Java-only customers.
Unfortunately, as far as I know MVKI does not exist, so you're best off doing a manual port (which would inevitably be cleaner, albeit more work).
Edit: Based on the description of Mainsoft, it appears to be similar to MVKI, though I'm not sure what they do for the class library, and unlike IKVM it's not FOSS.
http://jsc.sourceforge.net/ is a c# cross compiler that can convert .NET code to Java (amongst other things).
Expose your .NET API as ASMX web services and you should be good to go.
EDIT: For more heavy-usage scenarios, it would be worth looking into Windows Communication Foundation (WCF). This has built-in, configurable support for security, streaming, different transport scenarios (HTTP, TCP/IP, local named pipes). You are not restricted to SOAP message encoding, but that would probably be the easiest way to interop with Java.
I'm not too sure about your exact scenario, but if you're dealing with large files and the .NET code and Java code are both running locally, you can just save the file to the user's hard drive using .NET and then fetch it from your Java app.
There must be a good reason. I just cannot for the life of me figure out what it is...
It is easy to believe that companies are non-profit organisations which have your interests at heart. It is easy to forget that the only purpose for a listed company is to make money for it share holders. This is a legal obligation and directors/executives have been sacked/sued if share holders don't believe they have failed to do this.
Sun makes Java free because it helps sell their hardware which how it makes money from Java. IBM makes Java free because it helps them make more money on their consulting.
If Sun were to spend money on a C# converter how would it make that money back and make a profit. Imagine you have to convince Sun's share holders. If you can, Sun will make a C# converter.
I wonder whether the Mono project could have made less work for themselves by targeting the JVM instead of developing and maintaining their own virtual machine from scratch. Development effort could have focused on a C# cross-compiler and porting clean-room implementations of the .NET libraries to the JVM. Sort of like an open-source version of what Mainsoft has done. You could then enable inter-language calls between Java and C# code in the same JVM, and deploy Applets and Java Web Start applications written in C#.
I know this might not be what your looking for, but here are some possible alternatives that (if not to you) could be useful to others.
C: You could port as much as possible to C. Now you can make a wrapper in C# and Java (and any other language that can communicate with C) that makes it feel native to their language while programming. The problem now is that you (or them, depending your license) has to build the C part for each platform.
Fantom*: A programming language that according to their home page,
is:
Portable: Write code portable to the Java VM, .NET CLR, and JavaScript in the browser.
Familiar: Syntax Java and C# programmers will feel at home with Fantom's evolutionary syntax.
Object Oriented: Everything subclasses from Obj. Value types when you need the performance.
Functional: Functions and closures are baked in.
Static and Dynamically Typed: Don't like the extremes - take the middle of the road.
Haxe*: (pronounced hex) is cross platform language that compiles to other languages. Soon C# and Java will be supported. It currently supports:
Javascript: You can compile a Haxe program to a single .js file. You can access the typed browser DOM APIs with autocompletion
support, and all the dependencies will be resolved at compilation
time.
Flash: You can compile a Haxe program to a .swf file. Haxe is compatible with Flash Players 6 to 10, with either "old" Flash 8 API
or newest AS3/Flash9+ API. Haxe offers very good performance and
language features to develop Flash content.
NekoVM: You can compile a Haxe program to NekoVM bytecode. This can be used for server-side programming such as dynamic webpages
(using mod_neko for Apache) and also for command-line or desktop
applications, since NekoVM can be embedded and extended with some
other DLL.
PHP: You can compile a Haxe program to .php files. This will enable you to use a high level strictly-typed language such as haXe
while keeping full compatibility with your existing server platform
and libraries.
C++: You can now generate C++ code from your Haxe source code, with the required Makefiles. This is very useful for creating native
applications, for instance in iPhone development.
Haxe Community. (2011, March 11). Haxe Introduction. Retrieved January 29, 2011, from http://old.haxe.org/doc/intro
You can learn more about why Haxe is useful here.
*I have never used this language and I don't know how well this would work.
I made a comment that should really have been an answer:
It is just not technically possible at this point to implement the C# spec on the JVM. C# supports pointers, unsigned types, user defined value types, true generics, passing by reference, and loads of other things. For a very C#-like JVM language, check out Stab.
Mainsoft fakes it. I am sure it takes enormous effort on their part.
Have fun.
Must break checked exceptions.
Must find a way to implement delegates (which are like single-method interfaces added no earlier than load time).
You can run your .NET code and Java code in the same interpreter! See the IKVM .NET-based JVM, and the Boo and Java wiki page for an example use case (using the .NET-based Boo language to write applications using Java libraries).
Joe, I suggest you investigate IKVM. You might find something there that scratches your itch
If i was doing something like cross platform cross language support, I would create a 'common api' since the languages are similar in syntax you could make a translator easy enough. Then instead of calling java or .net apis directly from the core, you would call your 'common api' which would re implement the java and .net apis you would need. In this way you could create a cross language sandbox if you will. Since the main differences in java and c# are object definitions, I would get those by reflecting the C# dlls, and then reconstruct the constructs, then it would be easy to have an interpreter run through and implement the function bodies and convert properties to getters setters already knowing the structure of the files. This of course is assuming .net 2.0, some of the features in 3.0 and 3.5 become very difficult to 'interpret'
It would be complex, but probably not as complex as reconstructing a core in java by hand, and having to have 2 teams working on them seperatly. If this idea sparks some inspiration i might create one. I would really rather see a simpler stable mono installation for mac.
Basically I think a code level interpreter based on a set of common api classes is something very possible to write with a team in a week or two.
Simple. Because Sun would rather not be sued by Microsoft. And while we as programmers might see no viable reason for a suit, keep in mind that Microsoft is quite a bigger company than Sun and has the power to boss them around.
Sun fortunately is in the position of being quite more open than Microsoft however. If such a demand exists, either open source or a third-party could make this compiler for Java and Sun wouldn't have to take the heat.
JACIL is an apparently dead project that attempts to do the reverse of IKVM. Perhaps some motivated folks could use it as a starting point for a viable .Net to JVM compiler.
I guess the better question is why don't you write a C# to Java byte code compiler, if you want one to exist. Waiting for corporate overlords to do something is a bad idea.
A suggestion for creating such an implementation: take Mono's or .GNU's C# front end. Don't bother writing your own.
I think you will find that the Mainsoft, Enterprise Edition tool allows you to run most/maybe all your .NET code under the Java JVM... Seems to be focused more on ASP.NET but will allow C#. It has been available for some time, pity they don't publicize it better!
Warning blurb follows....
Mainsoft® is Java-.NET
interoperability software that enables
IT organizations to move to
Java-enabled platforms such as Linux
while preserving existing investments
in .NET code and skills. The software
integrates seamlessly into the Visual
Studio® development environment,
enabling C# and Visual Basic
developers to rapidly develop and
maintain server and Web applications
that run on Windows, Java EE platforms
or both, thereby reducing application
development and maintenance costs,
time-to-production and total cost of
ownership.
Related
To make development portable to Java, does it make sense to do the whole development on J# vs C#? What happens to missing bits in Java that exist in C# like lambda expression and so on?
What is the best way to achieve portability?
I definitely wouldn't use J# - it's not supported any more, and it only supported Java 1.1.4 anyway, IIRC.
I would personally recommend keeping the overall architecture consistent between the two languages, but then write the code separately, manually, taking into account the different idioms in the different languages.
If your codebase uses data-driven tests, it would be good to share that data between the two languages, as a way of helping to ensure data portability.
I suggest you don't use J# anymore as it has been discontinued. The last version has been shipped with Visual Studio 2005.
In addition to J#-specific language extensions and .NET CLR support, its runtime library implements Java 2 Collections Framework (without the java.util.concurrent extensions, though) and even some JFC/Swing, via the Supplemental UI Library.
So you'll be limited to the Java 1.4 API.
Given that J# has been discontinued long ago, I wouldn't suggest you invest your time into it.
If you really need portability between JVM and CLR, I'd take a look at IKVM (implements Java 1.7 API on top of CLR), Scala for .NET (discontinued circa Scala 2.10) or languages like Ruby (JRuby/IronRuby) or Python (Jython/IronPython).
Alternatively, you can generate your C# for .NET -- there're Java to C# converters available.
He's the deal: I'm making some theorical research on .NET and Java platforms for my graduation course and I reached a cloudy area: Can C# be considered part of the .NET Framework? Analog to this, is Java (the programming language) considered part of the Java platform?
Let me review the facts:
.NET is a development platform specified by the ECMA-335 Standard; it is an implementation of this standard, if you will. C# however, is an implementation of another standard, ECMA-334 which states clearly that its implementation does not require an implementation of the ECMA-335 standard - the CLR in Microsoft's case (which a lot of people mistakenly call .NET when there's a lot more to it than just the CLR).
Also, we have Mono, a different implementation of the ECMA-335, on which C# also runs (from everything I read, it is implied that Novell doesn't have a ECMA-334 implementation of its own, which is perfectly reasonable), but C# is not PART of Mono.
There's the fact that I read somewhere that a programming language is not part of a platform, but unfortunatelly I can't seem to find the source.
There's also the fact that Wikipedia "Computing Platform" article states that a programming language is a platform; Wiki is, however, virtually worthless if you want your research to be taken seriously.
Microsoft seems to promote C# as a part of .NET, but being .NET a multi-language platform, wouldn't be so every language that supports/is supported by it?
So far, I only spoke of .NET, but I also need an answer regarding Java. Actually, a general response would be the best.
So, can anyone help me to put the pieces together? Reference material is much appreciated.
On a different issue, I've found A LOT of books out there that explain the inner workings of the CLR, isn't anything on the same lines for the JVM? I mean, there's the Specification, of course, but I was aiming for something easier to digest, I'm not planning to build a Java compiler after all..
As everybody seems to notice, it depends on your definitions.
But Ecma 334 (and/or some other Ecma doc) also specify MSIL (or CIL), and that definitely is part of the platform.
And I think C# is not part of the platform, the MS compiler just targets the CLR by outputting MSIL. it's not so hard to imagine an implementation for another platform, managed or unmanaged.
Java confuses the issue a little by having both a platform and a language called Java but it's not so hard to see the distinction.
So, can a language be part of a Platform? Yes, see MSIL.
But most languages (including C# and Java) are not.
A lot of languages (C, C++) make an active effort to be portable across platforms.
Are you asking in general? If so then it would seem to me that surely the answer is yes, a programming language can be part of a platform. For instance, the ECMA-335 standard includes a specification of the CIL programming language. It could have pointed to the C# language as well and referenced the ECMA-334 standard. It just doesn't.
This is really a question of loose vs. tight coupling applied on a broad scale. Loose is generally preferred as a design choice. Tight is nonetheless always an option.
Thinking about the question a bit more, I think I understand better what you are uncertain about. There's the CLI, specified by ECMA-335, and then there's .NET, which is obviously tied to Microsoft.
The CLI does not include C#; on that much I think we can agree. Does .NET?
Honestly, I'm not really sure. Considering .NET is a product maintained by Microsoft, I suppose it's really up to them whether C#, VB.NET, F#, etc. are or are not a "part of" .NET. Same goes for Sun with Java and the "Java platform."
Going back a bit further(1978), the distintion between UCSD Pascal & the UCSD p-System was often blurred, such that most users refered to UCSD Pascal as the operating system.
C# is a programming language. It was developed by Microsoft within the .NET initiative and later approved as a standard by Ecma (ECMA-334) and ISO (ISO/IEC 23270). Mono, DotGNU and DotNetAnywhere are not ".NET" implementations of C#. So C# is part of .NET, Mono, DotGNU and DotNetAnywhere.
Java programming language is also a language, which runs on the Java Platform. Remember, the JVM can run many programming languages (Scala, Groovy, JRuby, Jython). Then you have the different Java "platforms": Java Standard Edition, Java Enterprise Edition, and Java Mobile Edition. Each of these follow certain specifications defined by the Java Community Process, and they include the Java programming language.
Sun/Oracle's thinking on the subject pertaining to Java:
Java technology is both a programming language and a platform.
Later:
A platform is the hardware or software environment in which a program runs. ... The Java platform differs from most other platforms in that it's a software-only platform that runs on top of other hardware-based platforms.
So I would say according to their definition, the Java Language is not "part" of the Java platform. Just as C99 isn't part of of the Unix platform, etc.
In practice, though, the lines are somewhat blurred. The Java Language is probably more coupled to the Java Platform than they would like to admit. The Java API (the libraries) are said to be part of the Java Platform, not the language, and yet the language is coupled to certain classes or interfaces (for example, the for-each loop depends on java.lang.Iterable and java.util.Iterator).
In general, the designers attempt to contain the coupling to the java.lang package, that being for language support. That's why you see special cases like String, Object, etc. in java.lang.
From a purely theoretical standpoint, language and platform are seperate. The language specification of C# defines ONLY its structure and syntax; how it should look and act from the perspective of the programmer. From an object-oriented perspective, the language is an interface (quite literally), and platforms are implementations of it. There are many C/C++ IDEs out there, all of which can conform to the ANSI C++ specification for the language itself (some include extra gizmos). If you wanted to, you could write a compiler that will accept C# code files and produce Java intermediate instead of MSIL, or even native machine code (though as C# was designed for a managed-code platform, some features of a native-code language, like the ability to explicitly destroy objects, may need to be added to the spec to make it work).
In the real world, C# is all-but-inseperable from the .NET Framework because Microsoft developed the language spec, and MS's implementation (.NET) is by far the most prolific. So, the language is usually considered part of the platform, to the point that hardly anybody says C#.NET anymore. There are ports of the language spec (usually written for workalikes of the MS platform), but when you just say C#, developers assume you are talking about C# in the context of the .NET Framework.
A simple answer could be yes and no, as you said, it's a cloudy area. You will probably find some arguments for, and some against, both equally valid.
But my point of view is that c# is not a part of .NET. C# is designed for platforms like .NET and puts quite specific demands of the platform, like managed memory, that 32 bit assignments can be implemented atomically, etc.
Turn the question around, does .NET require c#? Throw c# out and you still have VB.NET, etc. C# can be thought of as a plugin that requires a platform with a specific interface, where .NET implements that interface.
As a "Yes" argument you could ask the rhetorical question what .NET would be without c#. Would it even survive?
Not C# or Java related but, for instance, SmallTalk platform includes not only the language and the VM but also the IDE. So I guess the answer to your question is: yes - a programming language can be a part of a platform.
C# does depend on certain .NET classes (specifically, in mscorlib) to implement its special constructs, though I suppose you could create equivalents for a different backing runtime.
foreach depends on IEnumerable or IEnumerable<T>
using depends on IDisposable
Lambda expressions can resolve to special generic representation objects Expression<>
yield return is also tied into the .NET enumeration model
So C# isn't completely independent of at least some aspects of .NET and the CLR, though you could, in principle, get the same behavior by creating a runtime/compiler that provides only the minimal subset of .NET features required to implement the language features. I don't think it would be particularly useful, however, since the language and runtime have grown and evolved together.
Would you recommend Iron Ruby, Iron Python, or PowerShell for making a C# application a script host?
After some quick tinkering, right now I'm leaning towards powershell for two main reasons (note these a purely my opinions and if they are wrong, I'd love to know!!!):
1) It's simple to create a runspace with classes in your application; therefor it's easy to make your application scriptable.
2) I've heard some rumors that IronRuby and IronPython are losing support from Microsoft, so they may be a poor long term solution?
As this is my first time adding scripting to an application though, I'd welcome all the advice I can get from people who have been down this road before.
Specifically, besides letting me know whether you agree with my two points above, I'd like to know if IronRuby and IronPython are much easier to use (for a user, not developer) than powershell, and if in your experience using the DLR is as easy as just passing an object to a powershell runspace? And if I added support for the DLR and IR/IP scripting would my application still be backwards compatible with XP?
EDIT in June, 2022
With 12 years behind us, the original answer is terribly bad 😣
PowerShell became a DLR language (sort-of) in 2012
IronRuby was basically abandonware by then
PowerShell was open-sourced in 2016
PowerShell was cross-platform in 2018 on .NET Core
IronPython 3 was ported to .NET Core in 2020
The Microsoft-run PowerShell open source project has multiple orders of magnitude more community involvement and popularity than the IronLanguages ever did...
While it is still not designed as an embedded scripting language, PowerShell definitely has the capability to be used as such.
While it never worked with the DLR hosting model, it definitely has a working hosting model now.
With the new licensing, PowerShell is completely redistributable.
With expanded OS support (and even compatibility with ARM), there's really no reason not to choose PowerShell.
ORIGINAL ANSWER from 2010:
I'm not convinced PowerShell has "being a scripting language for applications" anywhere in it's long-term goals. It's first a shell, second an integration & automation engine, and third a shell scripting language ... since it's not redistributable at all, I'm not sure where embedded scripting fits in.
It's certainly very easy to host PowerShell -- assuming that it's pre-installed on your target PCs-- so it's a very viable option, but I think that in general it's just as easy to do it with IronRuby or IronPython.
I doubt the DLR itself is going away, so I think using a DLR language is still a good choice for this: you'd be set up to accept other DLR languages with much less effort, and the DLR and languages are redistributable.
Also, the work to host PowerShell only gets you PowerShell -- whereas you can leverage the same work to get IronPython and IronRuby working. Who knows, since PowerShell is a dynamic language, maybe it will be ported to the DLR with proper dynamics support in a future version ... but it's unlikely to ever be redistributable, because Microsoft doesn't consider it a dev tool, but rather a core part of the OS.
Bottom line: using the DLR is much more portable -- and not just to XP but even to Mono (and thus to Linux, OS X, iOS, Android, etc... and even to the web or Windows Phone via Silverlight).
number 2 is true (the dynamic lang teams have been losing headcount for awhile now) and an excellent reason. Ruby and Python aren't MS languages, and as such Iron * is just 'get it working on .NET'. PowerShell is a Microsoft creation, Microsoft-controlled, and Microsoft-supported.
More importantly, multiple Microsoft products have taken deep dependencies on PowerShell (Exchange, SharePoint, etc.) so there's very little question of PowerShell's ongoing support as a language.
Last, PowerShell considers being the scripting lang for other applications as one of its first-class support targets.
I'm in a similar position. I decided to use IronPython scripting but ever since I saw Anders Hejlsberg's talk "The Future of C#", I've had a feeling IronPython was doomed.
It was in Microsoft's interest to get the DLR developed but they ultimately want us to use tools and languages they control. After all, aren't you using C# and not Java? So what will a Microsoft dynamic language look like? How about dynamic, interpreted C# (Iron C#)? Hejlsberg's talk made it clear it isn't that far away. He even had a console window with a REPL interface. That said, there's always a possibility for Iron VB. Talk about closing the loop.
On the plus side for us programmers, Iron C# also solves another problem that I'm having trouble with -- the existence of two parallel object environments, one of .Net objects, one of Python objects. It takes work to get from one to the other. I assume an Iron C# would utilize the .Net class structure.
My advice: Stick with Iron Python and .Net classes. When Iron VB or Iron C# happens, it'll be a quick, maybe automatic, language translation. Besides, if enough of us use IronPython, Microsoft may change their mindset.
I haven't done much Java development in about six years or so. I may have the need soon to port a C# application to Java so as to make it run on both Windows and the company standard flavor of Linux (for reasons I can't discuss). The thing I want to know is, what is the best reading material to brush up on changes to Java since then, so I can make the port as smooth as possible.
I'm currently running on the .NET Framework 3.5 and making use of lambdas, extension methods and LINQ. This is a client side application with no web service calls or database calls. I do use various network protocols to talk to other machines, but I am already researching components to replace the ones we're using now (Dart Telnet, SharpSSH, etc.)
Mostly I'm looking for what has changed in the Java language and BCL since then. I don't recall generics, foreach loops, and boxing and unboxing was a PITA. Is there any equivalent for extension methods, lambdas and LINQ?
Effective Java, Second Edition is probably the starting text. It discusses the new language features and best practices for using them. Some of the stuff is probably familiar, but after six years, a refresher isn't a bad idea.
The various Sun tutorials on the new features are also a good start for the new features.
Effective Java and Java in a Nutshell.
Effective Java to get you thinking in Java and Nutshell as your reference guide.
To answer your final question, there are no equivalents for extension methods, lambdas or LINQ.
Java language development has moved very slowly since the introduction of annotations and generics in Java 5, and the majority of interesting Java language work has occurred with JVM languages such as Scala. If you need to use the JVM, then a more advanced language like Scala may fit your needs (note that Scala will integrate with existing Java libraries)
Going forwards, check out Project Coin, which is the set of proposed language developments for Java 7.
Instead of rewriting your application in Java, you may want to consider Mainsofts products which recompile MSIL to Java byte code.
http://dev.mainsoft.com/Default.aspx?tabid=166
Is anyone attempting to implement C# for the JVM? As a Java developer, I've been eyeing C# with envy, but am unwilling to give up the portability and maturity of the JVM, not to mention the diverse range of tools for it.
I know there are some important differences between the JVM and CLR but is there anything that is a showstopper?
There are very significant differences between the CLR and the JVM.
A few examples:
Java doesn't have user-defined value types
Java generics is completely different to .NET generics
Many aspects of C# depend on elements of the framework - delegates etc. You'd need to port the library as well, even for language aspects.
Java doesn't support things like properties and events at a JVM level. You could fake some of this, but it wouldn't be the same.
I don't believe Java has any equivalent to pass-by-reference parameters, even at the JVM level
Subtleties to do with the different memory models would quite possibly bite, although I'm not sure how much is in the C# spec.
Unsafe code in general probably isn't possible in Java
Interoperability with native code is very different between JNI and P/Invoke. This probably isn't much of a problem for you.
You'd have to fake operator overloading and user-defined conversions
You could probably port a lot of C# - but you'd be left with a pretty unsatisfactory experience, IMO.
Going the other way, are you aware of IKVM? It allows you to run Java code in .NET.
Visit http://code.google.com/p/stab-language
The code below if a Stab language code for JVM
using java.lang;
using stab.query;
public class Test {
public static void main(String[] args) {
// Sorts the arguments starting with "-" by length and then using the default
// string comparison
var query = from s in Query.asIterable(args)
where s.startsWith("-")
orderby s.length(), s
select s;
foreach (var s in query) {
System.out.println(s);
}
}
}
Bytecode transpilers
Grasshopper can take a CLR bytecode and transpile it for JVM. Intended primarily for web apps, it does not provide e.g. JVM implementation of Windows Forms classes. Seems somewhat dated, though. The web talks about ASP.NET 2.0, Visual Studio 2008 and so on. First mentioned by #alex
XMLVM can take CLR or JVM bytecode as input and produce either as output. Additionally it can output Javascript or Objective-C. No releases yet, only Subversion. "Experimental development version that is not to be used in a production environment."
IKVM goes in the other direction than OP wants. It provides a JVM implementation running on CLR, a JVM to CLR bytecode transpiler and a CLR library method stub generator for Java. http://www.ikvm.net/uses.html Mentioned by #Jon Skeet
RPC
Why not have CLR and JVM running alongside and make the communication as much frictionless as possible? This is not what the OP wants, but some other answers are already quite off topic in different ways, so let's cover it.
RabbitMQ, has a free option, it is a RPC server written in Erlang with API libraries for C#, Java and more.
jnBridge, the licence may be too expensive for some prospective users.
gRPC, and similar modern RPC libraries offer wide language support, code generation for client libraries in these languages, language independent wire format for data, advanced features like cascading call-cancellation and so on.
Programming languages
Write once, run everywhere ;)
Haxe, compiles to C#/CLR, Java/JVM, Javascript, Flash, Python, … Provides interop mechanisms for each of the target languages. Can be thought about as an ActionScript3 successor to some degree. Seems pretty solid stuff, with at least one company actually depending on it. Much more trustworthy than Stab, mentioned next.
Stab brings some C# features and Java interoperability. Not very useful, you get some C# features, but what you interact with is Java code which does not use them. https://softwareengineering.stackexchange.com/a/132080/45826 The language is relatively obscure, possibly abandoned, with little promise to become better. First mentioned here by #Vns.
Gust of fresh air for the JVM platform ;)
Scala, Kotlin, others, are fairly nice languages running on top of JVM which bring features that a C# programmer may miss in Java. Especially Kotlin feels like a reasonable alternative to C# in the JVM world. Scala may be a bit too large language for a programmer to get comfortable with in a short time.
Mono
That is certainly an option too. Why transpile to JVM if Mono can run it as it is. First mentioned by #ferhrosa
NEW YORK — Nov. 12, 2014 — On Wednesday, Microsoft Corp. reinforced its commitment to cross-platform developer experiences by open sourcing the full server-side .NET stack and expanding .NET to run on the Linux and Mac OS platforms.
According to this press release from which the quote comes, Visual Studio 2015 will add Linux/Mono as a supported platform.
This is a blog written by the Mono project people about it, from the other side: .NET Source Code Integration (November 2014).
.NET Core
A Windows/Linux multiplatform version of (some of) .Net governed by Microsoft. 'nuff said https://github.com/dotnet/core.
Conclusion
It would be now necessary to give these tools/frameworks a try and see how much friction there is. The OP wants to write in C# for the JVM, which may actually work quite well using Grasshopper.
Doing this with the goal to mix C# and Java world libraries in a single codebase may not work so well.
Sources
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
It might be simpler to write a converter from IL to bytecode. That way you'd automatically get support for any .NET language on the JVM.
However, this is such an obvious idea that if this hasn't already been done, it's probably extremely hard, or hard to do well/usefully.
Look at Grasshopper. It is a Visual Studio-based SDK and patented .NET to Java converter that enables you to run .NET Web and server applications on Linux® and other Java-enabled platforms.
An option for cross-platform development in C# could be mono: http://www.mono-project.com/
You can use a source-to-source compiler to translate C# into a language than runs on the JVM. For example, there are several C# to Java converters that would allow C# applications to run on the JVM after being translated into Java.
This answer may be late for you, but this one is just new. You may want to checkout Kotlin programming language. It offers the syntactic sugars which C# has and its the closest to C# syntax too, other than any Non-Java JVM language. Its from JetBrains.
I can see two reasons why this isn't getting much enthusiasm.
The first thing to realise is that, when it comes to the actual features of the language, C# and Java are very close. Not only are C# amd Java close, they are also moving in similar directions. There are some features that the JVM won't currently support out of the box, but that's not the real problem. You can always fake what is missing. I think people prefer waiting for Java to get some more sugar, than to create an Almost-Java from scratch. By the time the port is ready, Java may have decided to catch up.
Secondly, the reason why developers prefer C# isn't so much the language itself, but the tools around it, their two-way relationship with C# and how Microsoft supports the whole thing. For example, the C#-XAML combo is friendlier than JavaFX, because C# and XAML were hacked for eachother (e.g. partial classes in C#, bindings in XAML and more). Using C# on JavaFX doesn't improve much. To get the C# experience on the JVM, you need to also port the tools, and that's a much bigger project. Not even Mono will bother.
So, my advice to a Java developer, who wants to use a fancier language ontop of familiar tools, is to check out the existing JVM languages.
Mono is an option too, but I have always been skeptical of it. Even though it is C#-.NET and cross-platform, things built with Microsoft's tools won't generally work on Mono. It is essentially its own thing. We'll see what happens now that Microsoft said they'll be collaborating.