Реализация C # для JVM

Question

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

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

Answer 1

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

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

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

Возможно, вы могли бы портировать лот C # - но у вас останется довольно неудовлетворительный опыт, ИМО.

Если пойти другим путем, знаете ли вы IKVM ? Позволяет запускать код Java в .NET.

Answer 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);
        }
    }
}

Answer 3

байт-код транспортеров

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

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

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

RPC

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

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. Особенно Котлин чувствует себя как разумная альтернатива C # в мире JVM. Scala может быть слишком большим языком для программиста, чтобы освоиться за короткое время.

Mono

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

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

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

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

.NET Core

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

Заключение

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

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

Источники

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

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

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

Answer 9

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