JVM/CLR Параметры, совместимые с исходным кодом

У меня есть инструмент миграции базы данных Java с открытым исходным кодом (http://www.liquibase.org), который я рассматриваю при переносе на .Net.JVM/CLR Параметры, совместимые с исходным кодом

Большая часть инструмента (по крайней мере, со стороны сложности) находится вокруг логики, например: «если вы добавляете первичный ключ, а база данных - это Oracle, используйте этот SQL. Если база данных MySQL использует этот SQL. Если первичный ключ и база данных Postgres использует этот SQL ".

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

Код, который я искал для конвертации, не содержит каких-либо расширенных возможностей библиотеки (JDBC, System.out и т. Д.), Которые могут значительно отличаться от Java к .Net, поэтому я не думаю, что это будет проблемой (при худший он может быть спроектирован вокруг).

Так что я ищу это:

Язык, в котором я могу кодировать общие части моего приложения в и скомпилировать его в классы используемых на «стандартных» языков на целевой платформе
не добавлять каких-либо требований рабочей среды в системе
Ничто так странно, что отпугивает потенциальных вкладчиков

I К.Н. ow Python и Ruby имеют реализацию для JVM и CLR. Насколько они соответствуют моим требованиям? Кто-нибудь был успешным (или неуспешным), используя эту технику для кросс-платформенных приложений? Есть ли какие-то проблемы, о которых мне нужно беспокоиться?

источник

2009-05-01 Nathan Voxland

Проверьте Fantom programming language. Он имеет свой собственный синтаксис, подобный Java-like/C#, но может быть нацелен на Java VM или .NET CLR.

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

источник

2009-05-01 18:04:22

Я думаю, что вентилятор, кажется, лучший вариант. Jython на Java выглядит так, как будто он не работал некоторое время, а IronRuby на CLR - только в версии 0.3. Мне нужно будет узнать больше о Фанде, чтобы узнать, действительно ли это будет делать, или если проще сделать вилку. –

Последняя версия Jython была в ноябре, и она кажется довольно активной, хотя я согласен с тем, что Fantom лучше подходит в этом случае. – Yishai

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

Единственный другой вариант, который я мог бы предложить, - это портирование кода на J# язык, полный язык .NET (хотя и не первый класс в том смысле, что C# или VB.NET). Язык был разработан таким образом, чтобы различия с Java были минимальными.

источник

2009-05-01 18:07:25 Noldorin

Я думал обо всех этих вариантах, но моя забота о IKVM заключалась в добавлении зависимости, и моя проблема с J # была изделена разработчиками .net. –

@Nathan: Совершенно понятно ...хотя я не думаю, что вы найдете «идеальное» решение так, как вы хотите, в рамках основных технологий. Большинство разработчиков проектов переносят всю базу кода на другой язык (возможно, с помощью других) и вносят любые изменения/исправления кода параллельно всем портам. Я лично думаю, что вы столкнетесь с большими проблемами, чем это стоит, пытаясь использовать одну и ту же базу кода для версий JVM/CLR. Сохранение отдельного порта - это больше усилий, но это стоит того, что мне нужно. – Noldorin

Если вы думаете об эмиссионном подходе, вы можете посмотреть на Lua.

источник

2009-05-03 15:44:38

JVM/CLR Параметры, совместимые с исходным кодом

ответ

Смежные вопросы