There are very significant differences between 5 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 4 probably port a lot of C# - but you'd be left 3 with a pretty unsatisfactory experience, IMO.

Going 2 the other way, are you aware of IKVM? It allows 1 you to run Java code in .NET.

Visit http://code.google.com/p/stab-language

The code below if a Stab language 1 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 65 for JVM. Intended primarily for web apps, it 64 does not provide e.g. JVM implementation 63 of Windows Forms classes. Seems somewhat 62 dated, though. The web talks about ASP.NET 61 2.0, Visual Studio 2008 and so on. First 60 mentioned by @alex

XMLVM can take CLR or JVM bytecode 59 as input and produce either as output. Additionally 58 it can output Javascript or Objective-C. No 57 releases yet, only Subversion. "Experimental 56 development version that is not to be used 55 in a production environment."

IKVM goes 54 in the other direction than OP wants. It 53 provides a JVM implementation running on 52 CLR, a JVM to CLR bytecode transpiler and 51 a CLR library method stub generator for 50 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 49 option, it is a RPC server written in Erlang 48 with API libraries for C#, Java and more.

jnBridge, the 47 licence may be too expensive for some prospective 46 users.

gRPC, and similar modern RPC libraries 45 offer wide language support, code generation 44 for client libraries in these languages, language 43 independent wire format for data, advanced 42 features like cascading call-cancellation 41 and so on.

Programming languages

Write once, run everywhere ;)

Haxe, compiles to C#/CLR, Java/JVM, Javascript, Flash, Python, … Provides 40 interop mechanisms for each of the target 39 languages. Can be thought about as an ActionScript3 38 successor to some degree. Seems pretty solid 37 stuff, with at least one company actually 36 depending on it. Much more trustworthy than 35 Stab, mentioned next.

Stab brings some C# features 34 and Java interoperability. Not very useful, you 33 get some C# features, but what you interact 32 with is Java code which does not use them. https://softwareengineering.stackexchange.com/a/132080/45826 The 31 language is relatively obscure, possibly 30 abandoned, with little promise to become 29 better. First mentioned here by @Vns.

Gust of fresh air for the JVM platform ;)

Scala, Kotlin, others, are 28 fairly nice languages running on top of 27 JVM which bring features that a C# programmer 26 may miss in Java. Especially Kotlin feels 25 like a reasonable alternative to C# in the 24 JVM world. Scala may be a bit too large 23 language for a programmer to get comfortable 22 with in a short time.

Mono

That is certainly an 21 option too. Why transpile to JVM if Mono 20 can run it as it is. First mentioned by 19 @ferhrosa

NEW YORK — Nov. 12, 2014 — On Wednesday, Microsoft Corp. reinforced 18 its commitment to cross-platform developer 17 experiences by open sourcing the full server-side 16 .NET stack and expanding .NET to run on 15 the Linux and Mac OS platforms.

According 14 to this press release from which the quote comes, Visual Studio 13 2015 will add Linux/Mono as a supported 12 platform.

This is a blog written by the Mono 11 project people about it, from the other 10 side: .NET Source Code Integration (November 2014).

.NET Core

A Windows/Linux multiplatform 9 version of (some of) .Net governed by Microsoft. 'nuff 8 said https://github.com/dotnet/core.

Conclusion

It would be now necessary to give 7 these tools/frameworks a try and see how 6 much friction there is. The OP wants to 5 write in C# for the JVM, which may actually 4 work quite well using Grasshopper.

Doing 3 this with the goal to mix C# and Java world 2 libraries in a single codebase may not work 1 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 5 from IL to bytecode. That way you'd automatically 4 get support for any .NET language on the 3 JVM.

However, this is such an obvious idea 2 that if this hasn't already been done, it's 1 probably extremely hard, or hard to do well/usefully.

Look at Grasshopper. It is a Visual Studio-based SDK 3 and patented .NET to Java converter that 2 enables you to run .NET Web and server applications 1 on Linux® and other Java-enabled platforms.

An option for cross-platform development 1 in C# could be mono: http://www.mono-project.com/

You can use a source-to-source compiler to translate C# into a language 4 than runs on the JVM. For example, there 3 are several C# to Java converters that would allow C# applications 2 to run on the JVM after being translated 1 into Java.

This answer may be late for you, but this 5 one is just new. You may want to checkout 4 Kotlin programming language. It offers the syntactic 3 sugars which C# has and its the closest 2 to C# syntax too, other than any Non-Java 1 JVM language. Its from JetBrains.

I can see two reasons why this isn't getting 33 much enthusiasm.

The first thing to realise 32 is that, when it comes to the actual features 31 of the language, C# and Java are very close. Not 30 only are C# amd Java close, they are also 29 moving in similar directions. There are 28 some features that the JVM won't currently 27 support out of the box, but that's not the 26 real problem. You can always fake what is 25 missing. I think people prefer waiting for 24 Java to get some more sugar, than to create 23 an Almost-Java from scratch. By the time 22 the port is ready, Java may have decided 21 to catch up.

Secondly, the reason why developers 20 prefer C# isn't so much the language itself, but 19 the tools around it, their two-way relationship 18 with C# and how Microsoft supports the whole 17 thing. For example, the C#-XAML combo is 16 friendlier than JavaFX, because C# and XAML 15 were hacked for eachother (e.g. partial 14 classes in C#, bindings in XAML and more). Using 13 C# on JavaFX doesn't improve much. To get 12 the C# experience on the JVM, you need to 11 also port the tools, and that's a much bigger 10 project. Not even Mono will bother.

So, my advice 9 to a Java developer, who wants to use a 8 fancier language ontop of familiar tools, is 7 to check out the existing JVM languages.

Mono is an option 6 too, but I have always been skeptical of 5 it. Even though it is C#-.NET and cross-platform, things 4 built with Microsoft's tools won't generally 3 work on Mono. It is essentially its own 2 thing. We'll see what happens now that Microsoft 1 said they'll be collaborating.