Почему Sun не делает компилятор байтового кода C # to Java?

Question

Мы хотим запустить наш код C # на JVM

Моя компания имеет большую базу кода C #. Более половины этого кода - наш основной движок для создания, чтения, изменения, расчета и написания книг Excel. Мы часто получаем вопросы от клиентов и потенциальных клиентов, спрашивающих, собираемся ли мы создавать версию нашего движка на Java - многие из них вообще не заинтересованы в пользовательском интерфейсе. У нас даже есть несколько клиентов, которые взяли на себя труд использовать нашу библиотеку .NET из своих Java-приложений.

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

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

Я гуглюл подобные "c # to jvm" каждые несколько месяцев в течение нескольких лет без радости. Потратив ~ 7 лет на разработку аналогичного программного обеспечения для Java, я уверен, что API-интерфейсы .NET, которые мы используем в нашем ядре, могут быть легко инкапсулированы, и мы сможем выполнить все, что нам нужно, с помощью библиотек Java. Так что, если бы у нас был только C # -> JVM-компилятор, мы могли бы построить наш основной движок для Java, и нам больше не пришлось бы отказывать разработчикам Java, которые хотели бы его использовать.

Я не спрашиваю по техническим причинам, почему Sun не делает компилятор C #. Я признаю, что у Java нет свойств или 64-битная длина без знака и т. Д. ... В качестве аргумента просто предположите, что все эти технические проблемы могут быть решены путем расширения JVM и / или других средств.

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

Почему Sun должна делать компилятор C #? (ИМО конечно)

Упрощение запуска кода C # на платформе Java означает больше разработчиков и больше программного обеспечения для платформы. Есть ли что-то более важное для успеха платформы? Джонатан Шварц - программист. Я оставлю это другим, умнее меня, чтобы решить, взял ли он на себя невозможную работу в качестве президента и главного исполнительного директора Sun, но после встречи с Джонатаном вскоре после его вступления в Sun у меня сложилось впечатление, что он понимает программное обеспечение и потребность в большом База разработчиков.

Так почему же Sun не делает компилятор C #?

1. NIH синдром?
2. Призрак Скотт Макнили ?
3. Слишком много разработчиков Java не любят или не доверяют чему-либо, связанному с Microsoft?
4. Они согласились не принимать в качестве части большие деньги ?
5. ???

Должна быть веская причина. Я просто не могу за свою жизнь понять, что это такое ...

Answer 1

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

Это также не так просто, как просто реализовать компилятор, поскольку стандартные библиотеки классов Java отличаются от библиотек базовых классов .net. В конечном итоге вам придется изменить все вызовы API .NET на вызовы API Java.

У Micrsoft был продукт под названием J #, предназначенный для преобразования Java в .NET, но, в конце концов, никто не использовал его, так как API был ограничен до Java 2 API, поэтому он был в основном бесполезен. Было бы то же самое, если бы Sun внедрила части .NET BCL, поскольку только ее основные части стандартизированы и не требуют отчислений. Такие части, как ASP.NET и WPF, WCF и т. Д., Не являются частью стандартов ECMA, и поэтому Sun потребуется разрешение Microsoft для реализации этих API.

Если достаточное количество клиентов хотят, чтобы java-версия имела бизнес-смысл для переноса вашего приложения на java, тогда сделайте это, вы просто не получите никакой помощи от Sun через компилятор C # для JVM.

Answer 2

Почему Microsoft не делает компилятор байтового кода C # to Java? Почему бы вы не сделать это? С каждой стороны есть открытые спецификации ...

Answer 3

Джо Эриксон написал:

Упрощение запуска кода C # на Платформа Java означает больше разработчиков и больше программного обеспечения для платформы.

Это неверное утверждение. Запуск кода C # на JVM не создает программистов на Java, он создает программистов на C #, которые могут выполняться на JVM. Это только расширяет возможности C #, предполагая, что JVM также переводит любые специфические вызовы Microsoft (например, win32) в нечто, не зависящее от платформы. Так что, если Sun переводит IL в Java Bytecode, единственная группа, которой он помогает, это: Microsoft. И, учитывая историю Sun с Microsoft во время первоначального судебного процесса по C # -Java / Visual J ++ ...

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

Если вам нужен C # на платформе не от Microsoft, используйте Mono

Answer 4

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

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

IKVM - это не , что вы хотите. ИКВМ - это три основные вещи .

а. ikvm - CLI-реализация виртуальной машины Java (обратите внимание, что при этом используется Classpath (теперь OpenJDK) для библиотеки классов Java).

б. ikvmc - компилирует байт-код Java в байт-код CLI.

с. ikvmstub - генерирует классы-заглушки Java, которые вызывают код CLI.

Обратите внимание, что все эти инструменты зависят от CLI во время выполнения. То, что вы хотите, - это полная противоположность IKVM, которая, конечно, MVKI (Наиболее почтенный посредник Kompiler):):

а. mvki - Java-реализация виртуальной машины CLI (предположительно, для библиотеки классов будет использоваться Mono или DotGNU ).

б. mvkic - компилирует байт-код CLI в байт-код Java.

с. mvkistub - генерирует классы-заглушки CLI, которые вызывают Java

Обратите внимание, что ни один из них не потребует существующей реализации .NET Framework во время выполнения, поэтому они должны быть удовлетворительными для ваших клиентов только на Java.

К сожалению, насколько я знаю, MVKI не существует, поэтому лучше всего делать ручной порт (который неизбежно будет чище, хотя и потребует больше работы).

Редактировать: Основываясь на описании Mainsoft, оно похоже на MVKI, хотя я не уверен, что они делают для библиотеки классов, и в отличие от IKVM это не FOSS.

Answer 5

http://jsc.sourceforge.net/ - это кросс-компилятор c #, который может конвертировать .NET-код в Java (среди прочего).

Answer 6

Представьте свой .NET API в качестве веб-служб ASMX, и вам будет хорошо.

РЕДАКТИРОВАТЬ: Для сценариев более интенсивного использования, было бы целесообразно изучить Windows Communication Foundation (WCF). Это имеет встроенную, настраиваемую поддержку безопасности, потоковой передачи, различных транспортных сценариев (HTTP, TCP / IP, локальные именованные каналы). Вы не ограничены кодированием сообщений SOAP, но это, вероятно, самый простой способ взаимодействия с Java.

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

Answer 7

Должна быть веская причина. Я просто не могу за свою жизнь понять, что это такое ...

Легко поверить, что компании - это некоммерческие организации, в основе которых лежат ваши интересы. Легко забыть, что цель для котируемой компании - заработать деньги для ее акционеров. Это юридическое обязательство, и директора / руководители были уволены / поданы в суд, если акционеры не считают, что они этого не сделали.

Sun делает Java бесплатной, потому что она помогает продавать их оборудование, как это делает деньги на Java. IBM делает Java бесплатной, поскольку она помогает им зарабатывать больше денег на консультациях.

Если бы Sun потратила деньги на конвертер C #, как бы они вернули эти деньги и получили прибыль? Представьте, что вам нужно убедить акционеров Sun. Если вы можете, Sun сделает конвертер C #.

Answer 8

Интересно, мог бы проект Mono сделать меньше работы для себя, ориентируясь на JVM вместо того, чтобы разрабатывать и поддерживать свою собственную виртуальную машину с нуля. Работа по разработке могла бы быть сосредоточена на кросс-компиляторе C # и переносе реализаций чистых комнат библиотек .NET на JVM. Вроде как версия с открытым исходным кодом того, что сделал Mainsoft. Затем можно включить межязыковые вызовы между кодом Java и C # в той же JVM и развернуть приложения Applets и Java Web Start, написанные на C #.

Answer 9

Я знаю, что это может быть не то, что вы ищете, но вот некоторые возможные альтернативы, которые (если не вам) могут быть полезны для других.

1. C: Вы можете перенести как можно больше данных на C. Теперь вы можете создать оболочку на C # и Java (и на любом другом языке, который может общаться с C), чтобы он чувствовал себя родным для их языка во время программирования. Теперь проблема в том, что вы (или они, в зависимости от вашей лицензии) должны построить часть C для каждой платформы.

2. Fantom *: язык программирования, который соответствует их домашней странице, это:

   • Переносимость: запись кода, переносимого на Java VM, .NET CLR и JavaScript, в браузере.
   • Знакомый: синтаксис Программисты на Java и C # будут чувствовать себя как дома с эволюционным синтаксисом Fantom.
   • Объектно-ориентированный: все подклассы от Obj. Типы значений, когда вам нужна производительность.
   • Функциональный: функции и замыкания запекаются.
   • Статический и динамический тип: не любите крайности - возьмите середину дороги.

3. Haxe *: (произносится как шестнадцатеричный) - кроссплатформенный язык, который компилируется с другими языками. Скоро C # и Java будут поддерживаться. В настоящее время поддерживает:

   • Javascript: Вы можете скомпилировать программу Haxe в один файл .js. Вы можете получить доступ к API DOM типизированного браузера с автозаполнением поддержка, и все зависимости будут решены при компиляции время.

   • Flash: Вы можете скомпилировать программу Haxe в файл .swf. Haxe совместим с Flash Player от 6 до 10 с любым «старым» Flash 8 API или новейший AS3 / Flash9 + API. Haxe предлагает очень хорошую производительность и языковые возможности для разработки Flash-контента.

   • NekoVM: Вы можете скомпилировать программу Haxe в байт-код NekoVM. Это может использоваться для программирования на стороне сервера, такого как динамические веб-страницы (используя mod_neko для Apache), а также для командной строки или рабочего стола приложения, поскольку NekoVM может быть встроен и расширен с некоторыми другая DLL.

   • PHP: Вы можете скомпилировать программу Haxe в файлы .php. Это позволит вам использовать строго типизированный язык высокого уровня, такой как haXe сохраняя полную совместимость с вашей существующей серверной платформой и библиотеки.

   • C ++: Теперь вы можете генерировать код C ++ из исходного кода Haxe с необходимыми файлами Makefile. Это очень полезно для создания нативных приложения, например, при разработке iPhone.

   Сообщество Haxe. (2011 г., 11 марта). Haxe Введение. Получено 29 января 2011 г., http://old.haxe.org/doc/intro

   Вы можете узнать больше о том, почему Haxe полезен здесь .

* Я никогда не использовал этот язык, и я не знаю, насколько хорошо это будет работать.

Answer 10

Я сделал комментарий, который действительно должен был быть ответом:

На данный момент технически невозможно реализовать спецификацию C # на JVM. C # поддерживает указатели, неподписанные типы, определяемые пользователем типы значений, истинные обобщения, передачу по ссылке и множество других вещей. Для очень похожего на C # языка JVM, проверьте Stab .

Mainsoft подделывает. Я уверен, что это требует огромных усилий с их стороны.