Внедрение С# для JVM

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

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

Ответ 1

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

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

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

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

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

Ответ 2

Посетите 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);
        }
    }
}

Ответ 3

Преобразователи байтового кода

Grasshopper может принимать байт-код 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 байт-кода transpiler и CLB-библиотечный метод-заглушка для Java. http://www.ikvm.net/uses.html Упоминается @Jon Skeet

RPC

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

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

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

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

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

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

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

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

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

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

Mono

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

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

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

Это блог, написанный людьми из проекта Mono, с другой стороны: .NET Source Code Integration (ноябрь 2014).

.NET Core

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

Заключение

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

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

Источники

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

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

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