Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

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

Итак, почему Sun не делает компилятор С#?

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Если у вас должен быть С# на платформе, отличной от Microsoft, используйте Mono

Ответ 3

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

Ответ 4

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

EDIT: для более тяжелых сценариев использования стоит обратить внимание на Windows Communication Foundation (WCF). У этого есть встроенная конфигурируемая поддержка безопасности, потоковой передачи, различных транспортных сценариев (HTTP, TCP/IP, локальных именованных каналов). Вы не ограничены кодировкой сообщений SOAP, но это, вероятно, самый простой способ взаимодействия с Java.

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 10

Удачи.

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

Ответ 11

Вы можете запускать свой код .NET и код Java в одном и том же интерпретаторе! См. IKVM.NET-совместимая JVM и Boo и Java wiki-страница для примера использования (с использованием языка Boo на .NET для написания приложений с использованием библиотек Java).

Ответ 12

Джо, я предлагаю вам исследовать IKVM. Вы можете найти что-то там, что царапины зуд

Ответ 13

Я думаю, вы обнаружите, что инструмент Mainsoft, Enterprise Edition позволяет запускать большинство /, возможно, весь ваш код .NET под Java JVM... Кажется, что больше сосредоточено на ASP.NET, но позволит С#. Он был доступен в течение некоторого времени, жаль, что они не публикуют его лучше!

Далее следует предупреждение.

Mainsoft® - это Java-.NET совместимости программного обеспечения, которое позволяет ИТ-организациям перейти на Платформы с поддержкой Java, такие как Linux при сохранении существующих инвестиций в коде .NET и навыках. Программное обеспечение легко интегрируется в Visual Studio®, включение С# и Visual Basic разработчикам стремительно развиваться и поддерживать сервер и веб-приложения которые работают на платформах Windows, Java EE или и то, и другое, тем самым уменьшая применение затраты на разработку и обслуживание, времени производства и общей стоимости собственность.

Ответ 14

Если бы я делал что-то вроде кросс-языковой поддержки кросс-платформы, я бы создал "общий api", так как языки схожи в синтаксисе, вы могли бы сделать переводчик достаточно простым. Затем вместо вызова java или .net apis непосредственно из ядра вы бы назвали ваш "общий api", который бы повторно реализовал java и .net apis, которые вам понадобятся. Таким образом, вы можете создать песочницу с перекрестными языками, если хотите. Поскольку основные отличия в java и С# являются объектными определениями, я бы получил их, отразив DLL С#, а затем восстановил конструкции, тогда было бы легко заставить интерпретатор пропустить и реализовать тела функций и преобразовать свойства в сеттеры getters уже зная структуру файлов. Это, конечно, предполагает .net 2.0, некоторые из функций 3.0 и 3.5 становятся очень трудными для интерпретации

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

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

Ответ 15

Simple. Потому что Sun скорее не будет предъявлять иск Microsoft. И хотя мы, как программисты, не видим никакой обоснованной причины для иска, имейте в виду, что Microsoft является довольно крупной компанией, чем Sun, и имеет право наставлять их.

Sun, к счастью, в состоянии быть более открытым, чем Microsoft. Если такой спрос существует, либо open source, либо сторонний разработчик мог бы сделать этот компилятор для Java, а Sun не потребовалось бы тепла.

Ответ 16

JACIL - это, по-видимому, мертвый проект, который пытается сделать обратное IKVM. Возможно, некоторые мотивированные люди могут использовать его в качестве отправной точки для жизнеспособного компилятора .Net для JVM.

Ответ 17

Я думаю, лучший вопрос заключается в том, почему не вы пишите компилятор кода байта С# в Java, если хотите, чтобы он существовал. Ждать корпоративных повелителей, чтобы что-то сделать, это плохая идея.

Предложение для создания такой реализации: взять Mono или .GNU С# переднего конца. Не утруждайте себя написанием.

Ответ 18

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

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

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