Кто-нибудь пытается внедрить С# для JVM? Как разработчик Java, я с завистью смотрел на С#, но я не хотел отказываться от переносимости и зрелости JVM, не говоря уже о разнообразных инструментах для этого.
Я знаю, есть некоторые важные различия между JVM и CLR, но есть ли что-нибудь, что является showstopper?
Существуют очень существенные различия между CLR и JVM.
Несколько примеров:
Вероятно, вы могли бы переносить много С#, но вы останетесь с довольно неудовлетворительным опытом, 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);
}
}
}
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
Почему бы не запустить 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 может быть слишком большим языком для программиста, чтобы получить удобство в течение короткого времени.
Это тоже вариант. Зачем переходить на JVM, если Mono может запускать его так, как есть. Сначала упоминается @ferhrosa
НЬЮ-ЙОРК - 12 ноября 2014 г.. В среду Microsoft Corp. подтвердила свою приверженность кросс-платформенному опыту разработчиков, открыв полный набор .NET-стеков на стороне сервера и расширив .NET до работать на платформах Linux и Mac OS.
Согласно этот пресс-релиз, из которого следует цитата, Visual Studio 2015 добавит Linux/Mono в качестве поддерживаемой платформы.
Это блог, написанный людьми из проекта Mono, с другой стороны: .NET Source Code Integration (ноябрь 2014).
Многоплатформенная версия 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
Может быть проще записать конвертер с IL на байт-код. Таким образом, вы автоматически получите поддержку любого языка .NET на JVM.
Однако это такая очевидная идея, что, если этого еще не сделано, это, вероятно, чрезвычайно сложно или сложно сделать хорошо/полезно.
Посмотрите Grasshopper. Это SDK на базе Visual Studio и запатентованный конвертер .NET в Java, который позволяет запускать .NET Web и серверные приложения на Linux® и других платформах с поддержкой Java.
Вариант кросс-платформенной разработки в С# может быть моно: http://www.mono-project.com/
Этот ответ может быть запоздалым для вас, но этот только новый. Вы можете проверить Kotlin язык программирования. Он предлагает синтаксические сахара, которые имеет С#, и его ближайший к синтаксису С#, кроме любого языка Java Java. Его от JetBrains.
Я вижу две причины, почему это не вызывает большого энтузиазма.
Первое, что нужно понять, это то, что, когда дело доходит до реальных особенностей языка, С# и Java очень близки. Мало того, что С# amd Java закрывается, они также движутся в аналогичных направлениях. Есть некоторые функции, которые JVM в настоящее время не поддерживает из коробки, но это не настоящая проблема. Вы всегда можете подделывать то, чего не хватает. Я думаю, что люди предпочитают ждать, когда Java получит еще больше сахара, чем создать "почти-Java" с нуля. К тому моменту, когда порт будет готов, Java, возможно, решила наверстать упущенное.
Во-вторых, причина, по которой разработчики предпочитают С#, - это не столько сам язык, сколько инструменты вокруг него, их двусторонние отношения с С# и как Microsoft поддерживает все это. Например, комбинация С# -XAML более дружелюбна, чем JavaFX, потому что С# и XAML были взломаны для eachother (например, частичные классы на С#, привязки в XAML и т.д.). Использование С# на JavaFX не сильно улучшается. Чтобы получить опыт работы с С# на JVM, вам необходимо также перенести инструменты и сделать гораздо более крупный проект. Даже Mono будет беспокоить.
Итак, мой совет разработчику Java, который хочет использовать более удобный язык на привычных инструментах, состоит в том, чтобы проверить существующие языки JVM.
Моно тоже вариант, но я всегда скептически относился к нему. Несмотря на то, что это С# -.NET и кросс-платформенная, вещи, созданные с помощью инструментов Microsoft, обычно не работают на Mono. Это, по сути, его собственная вещь. Мы посмотрим, что произойдет сейчас, когда Microsoft сообщит, что они будут сотрудничать.
Вы можете использовать источник-источник-компилятор для перевода С# на язык, чем на JVM. Например, существует несколько С# к конвертерам Java, которые позволят запускать приложения С# на JVM после перевода на Java.