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


91

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

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


3
Я также написал много-много полностью мультиплатформенных приложений на Java - это повседневная вещь для меня и моей команды. Обычно мы выполняем план тестирования на каждой платформе, которую мы официально «квалифицируем», но я думаю, что прошли годы с тех пор, как ошибка тестирования была связана с различием в платформе.
Джаред

1
Наш основной продукт работает в Windows, OS X и Linux без изменений. Это действительно несложно.
Торбьёрн Равн Андерсен,

1
Я занимаюсь Java в Windows, другой парень делает свою часть в OSX, CI выполняет все тесты под Linux, и мы развернули программное обеспечение на самых разных серверах Windows и Linux и даже в Solaris. Так что я думаю, что могу сказать, что уже какое-то время пишу действительно, полностью многоплатформенные программы на Java.
Esko

1
JavaVM реализована в .NET; .NET реализация Java LIBS; совместимость обоих миров -> IKVM.NET ( ikvm.net )
gsscoder

1
Мне кажется, что если вы можете преобразовать .NET в JavaScript (например, JSIL делает это), вы сможете преобразовать его в Java ...
BrainSlugs83

Ответы:


93

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

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

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

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

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


7
В Java есть финализаторы, и финализация .NET тоже не детерминирована. Между ними могут быть некоторые тонкие различия, но я не могу придумать ничего навскидку. Я подозреваю, что тесты на достижимость Java сильнее, чем тесты .NET: никакой финализации, пока другой поток все еще выполняет метод экземпляра
Джон Скит,

3
Я думаю, вы могли бы сопоставить типы значений с ссылочными типами. Просто сделайте каждое задание мелким клоном!
Дэниел Эрвикер,

3
@Earwicker: ... и изменить распределение массивов и другие места, где семантика имеет значение? Я подозреваю, что было бы очень сложно заставить его работать, если это возможно, и результат не был бы тем, что вы хотели бы использовать.
Джон Скит,

4
Я думаю, что дженерики тоже можно было бы решить. Вам нужно будет сгенерировать класс java с дополнительными полями для хранения объектов Class для параметров типа, поэтому это добавит некоторые накладные расходы, но тогда будут доступны новые T () и typeof (T).
Дэниел Эрвикер,

30
@Jon Skeet: Это худшее из обоих миров: несколько устаревший язык Java на проприетарной платформе Microsoft.
Bart van Heukelom 02

43

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

7
stab предоставляет большую часть мяса языка C # для JVM, но делает это таким образом, чтобы обеспечить взаимодействие с Java. Таким образом, это не совсем исходный код, совместимый с кодом C #, написанным для .NET CLR, но он позволяет программисту Java пользоваться языком, очень похожим на C #, получая при этом сгенерированный байтовый код такого же качества и имея неимпедансную совместимость с библиотеками и фреймворками Java. Это правильный подход для установки C # на JVM.
RogerV

1
Хороший язык, хорошая платформа ... Хотел бы я наткнуться на это много лет назад.
Jefferey Cave,

15

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

Кузнечик может взять байт-код 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


Отличный ответ! Как разработчик C #, который недоволен необходимостью перехода на Java (как можно жить без свойств ?!) и сомневается в Scala, здесь действительно хорошо представлены варианты.
Gilthans

9

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

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


6
Вы столкнетесь с большинством перечисленных мною проблем - с разными типами и т. Д.
Джон Скит,

8
Это именно то, что делает Grasshopper (см. Ответ @ alex выше), это действительно очень сложно (я работал над Grasshopper).
Мотти,

7

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


2
У вас есть практический опыт работы с ним? Также обратите внимание, что лицензия на бесплатную версию является драконьей.
Торбьёрн Равн Андерсен,

13
Вы потеряли мой интерес в тот момент, когда произнесли слово «запатентованный». Вздох.
Stephen C

2
Просто некоторые новости: Grasshopper теперь бесплатен , без поддержки и гарантии (как и большинство продуктов с открытым исходным кодом).
fernacolo

1
Майнсофт кажется полностью мертвым, и ссылки Grasshopper больше не работают.
Дэвид Гивен

1
Тогда очевидно, что это просто чистое колебание. Обе ссылки сейчас работают. К сожалению, сейчас я не могу вспомнить, почему я этого хотел ...
Дэвид Гивен



0

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


0

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

Первое, что нужно понять, это то, что когда дело доходит до реальных возможностей языка, 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 заявила, что они будут сотрудничать.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.