Кто-нибудь пытается реализовать C # для JVM? Как Java-разработчик, я с завистью наблюдал за C #, но я не желаю отказываться от переносимости и зрелости JVM, не говоря уже о разнообразии инструментов для нее.

Я знаю, что между JVM и CLR есть некоторые важные различия, но есть ли что-нибудь, что может помешать?

Между CLR и JVM есть очень существенные различия.

Несколько примеров:

• В Java нет определяемых пользователем типов значений
• Дженерики Java полностью отличаются от дженериков .NET
• Многие аспекты C # зависят от элементов структуры - делегатов и т. Д. Вам также потребуется перенести библиотеку, даже для языковых аспектов.
• Java не поддерживает такие вещи, как свойства и события на уровне JVM. Вы можете подделать некоторые из них, но это будет не то же самое.
• Я не верю, что Java имеет какой-либо эквивалент параметрам передачи по ссылке, даже на уровне JVM
• Тонкости, связанные с различными моделями памяти, вполне могли бы укусить, хотя я не уверен, сколько из них указано в спецификации C #.
• Небезопасный код вообще, вероятно, невозможен в Java
• Совместимость с машинным кодом сильно отличается между JNI и P / Invoke. Вероятно, для вас это не проблема.
• Вам придется подделывать перегрузку оператора и пользовательские преобразования

Вы, вероятно, могли бы перенести много C #, но у вас остались бы довольно неудовлетворительные впечатления, IMO.

И наоборот, знаете ли вы об IKVM ? Он позволяет запускать Java-код в .NET.

Посетите http://code.google.com/p/stab-language.

Код ниже, если код языка Stab для 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);
        }
    }
}

Транспилеры байт-кода

Кузнечик может взять байт-код CLR и перенести его для JVM. Предназначенный в первую очередь для веб-приложений, он не предоставляет, например, JVM-реализацию классов Windows Forms. Хотя кажется несколько устаревшим. В сети рассказывают об ASP.NET 2.0, Visual Studio 2008 и так далее. Первое упоминание @alex

XMLVM может принимать байт-код CLR или JVM в качестве входных данных и производить либо в качестве выходных данных. Кроме того, он может выводить Javascript или Objective-C. Релизов пока нет, только Subversion. «Экспериментальная версия для разработки, не предназначенная для использования в производственной среде».

IKVM идет в другом направлении, чем того хочет OP. Он предоставляет реализацию JVM, работающую в среде CLR, транспилятор байт-кода JVM в CLR и генератор заглушек метода библиотеки CLR для Java. http://www.ikvm.net/uses.html Упомянул @Jon Skeet

RPC

Почему бы не использовать CLR и JVM одновременно и сделать общение максимально простым? Это не то, что хочет OP, но некоторые другие ответы уже по-разному не соответствуют теме, поэтому давайте рассмотрим это.

RabbitMQ имеет бесплатную опцию, это RPC-сервер, написанный на Erlang с библиотеками API для C #, Java и др.

jnBridge , лицензия может быть слишком дорогой для некоторых потенциальных пользователей.

gRPC и подобные современные библиотеки RPC предлагают широкую языковую поддержку, генерацию кода для клиентских библиотек на этих языках, независимый от языка формат передачи данных, расширенные функции, такие как каскадная отмена вызовов и т. д.

Языки программирования

Пиши один раз, беги везде;)

Haxe , компилируется в C # / CLR, Java / JVM, Javascript, Flash, Python,… Предоставляет механизмы взаимодействия для каждого из целевых языков. В некоторой степени его можно рассматривать как преемника ActionScript3. Кажется, довольно солидный материал, от которого зависит как минимум одна компания. Намного более надежен, чем упомянутый далее Стаб.

Stab предлагает некоторые функции C # и совместимость с Java. Не очень полезно, вы получаете некоторые функции C #, но вы взаимодействуете с кодом Java, который их не использует. https://softwareengineering.stackexchange.com/a/132080/45826 Язык относительно невразумительный, возможно, заброшенный и мало обещающий стать лучше. Впервые упомянуто здесь @Vns.

Порыв свежего воздуха для платформы JVM;)

Scala , Kotlin и другие - довольно хорошие языки, работающие поверх JVM, которые предоставляют функции, которые программист на C # может упустить в Java. Особенно Kotlin кажется разумной альтернативой C # в мире JVM. Scala может быть слишком большим языком для программиста, чтобы освоить его за короткое время.

Мононуклеоз

Это тоже вариант. Зачем переносить на JVM, если Mono может запускать его как есть. Первое упоминание @ferhrosa

НЬЮ-ЙОРК - 12 ноября 2014 г. - В среду корпорация Microsoft подтвердила свою приверженность межплатформенному опыту разработчиков, открыв исходный код полного стека .NET на стороне сервера и расширив .NET для работы на платформах Linux и Mac OS.

Согласно этому пресс-релизу, из которого сделана цитата, Visual Studio 2015 добавит Linux / Mono в качестве поддерживаемой платформы.

Этот блог написан людьми проекта Mono об этом с другой стороны: Интеграция исходного кода .NET (ноябрь 2014 г.).

.NET Core

Многоплатформенная версия Windows / Linux (часть) .Net, управляемая Microsoft. 'Нуфф сказал https://github.com/dotnet/core .

Вывод

Теперь было бы необходимо попробовать эти инструменты / фреймворки и посмотреть, сколько там трения. OP хочет писать на C # для JVM, которая может действительно хорошо работать с Grasshopper.

Выполнение этого с целью смешивания мировых библиотек C # и Java в одной кодовой базе может не работать так хорошо.

Источники

http://blog.pluralsight.com/new-course-making-java-and-c-work-to General-jvm-and-net-clr-interop

Может быть проще написать преобразователь из IL в байт-код. Таким образом, вы автоматически получите поддержку любого языка .NET на JVM.

Однако это настолько очевидная идея, что, если этого еще не было сделано, это, вероятно, чрезвычайно сложно или трудно сделать хорошо / с пользой.

Посмотрите на Кузнечика . Это SDK на основе Visual Studio и запатентованный конвертер .NET в Java, который позволяет запускать веб-приложения .NET и серверные приложения на Linux® и других платформах с поддержкой Java.

Вариант кроссплатформенной разработки на C # может быть моно: http://www.mono-project.com/

Вы можете использовать компилятор «исходный код» для перевода C # на язык, который не запускается на JVM. Например, существует несколько конвертеров C # в Java , которые позволят приложениям C # запускаться на JVM после преобразования в Java.

Этот ответ может быть для вас запоздалым, но этот новый. Вы можете попробовать язык программирования Kotlin . Он предлагает синтаксические сахара, которые есть в C #, а также его синтаксис, наиболее близкий к C #, кроме любого языка JVM, отличного от Java. Это от JetBrains .

Я вижу две причины, почему это не вызывает особого энтузиазма.

Первое, что нужно понять, это то, что когда дело доходит до реальных возможностей языка, C # и Java очень близки. Не только C # и Java близки, но и движутся в том же направлении. Есть некоторые функции, которые JVM в настоящее время не поддерживает из коробки, но это не настоящая проблема. Вы всегда можете подделать то, чего не хватает. Я думаю, что люди предпочитают ждать, пока Java получит больше сахара, чем создавать почти Java с нуля. К тому времени, когда порт будет готов, Java, возможно, решит наверстать упущенное.

Во-вторых, причина, по которой разработчики предпочитают C #, не столько в самом языке, сколько в инструментах, связанных с ним, их двусторонних отношениях с C # и в том, как Microsoft поддерживает все это. Например, комбинация C # -XAML более удобна, чем JavaFX, потому что C # и XAML были взломаны друг для друга (например, частичные классы в C #, привязки в XAML и т. Д.). Использование C # в JavaFX не сильно улучшается. Чтобы получить опыт работы с C # на JVM, вам также необходимо перенести инструменты, а это гораздо более крупный проект. Даже Моно не побеспокоит.

Итак, мой совет Java-разработчику, который хочет использовать более изящный язык поверх знакомых инструментов, - проверить существующие языки JVM .

Моно - тоже вариант, но я всегда скептически относился к нему. Несмотря на то, что это C # - .NET и кроссплатформенный, вещи, созданные с помощью инструментов Microsoft, обычно не работают на Mono. По сути, это отдельная вещь. Посмотрим, что произойдет сейчас, когда Microsoft заявила, что они будут сотрудничать.