Хтось намагається застосувати C # для JVM? Як розробник Java, я дивився на C # із заздрістю, але не хочу відмовлятися від мобільності та зрілості JVM, не кажучи вже про різноманітний набір інструментів для неї.
Я знаю, що є деякі важливі відмінності між JVM та CLR, але чи є щось, що є шоустопом?
Відповіді:
Існують дуже суттєві відмінності між CLR та JVM.
Кілька прикладів:
Можливо, ви могли б перенести багато C # - але у вас залишився б досить незадовільний досвід, IMO.
Ідучи іншим шляхом, чи знаєте ви про IKVM ? Це дозволяє запускати код Java у .NET.
Відвідайте 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);
}
}
}Коник може взяти байт-код CLR і перевести його для JVM. Призначений переважно для веб-програм, він не передбачає, наприклад, реалізацію класів Windows Forms у JVM. Здається, дещо застаріле. В Інтернеті йдеться про 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
Чому б не запустити 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 може бути занадто великою мовою для програміста, щоб за короткий час почути себе комфортно.
Це, звичайно, теж варіант. Навіщо транспілювати в JVM, якщо Mono може запустити його як є. Вперше згадується @ferhrosa
НЬЮ-ЙОРК - 12 листопада 2014 р. - У середу корпорація Microsoft зміцнила свою прихильність досвіду розробників міжплатформенних платформ, відкривши джерело повного стеку .NET на стороні сервера та розширивши .NET для роботи на платформах Linux і Mac OS.
Згідно з цим прес-релізом, з якого випливає цитата, Visual Studio 2015 додасть Linux / Mono як підтримувану платформу.
Це блог, написаний людьми з проекту Mono з іншого боку: Інтеграція вихідного коду .NET (листопад 2014 р.).
Мультиплатформна версія Windows / Linux (деякі) .Net, керована корпорацією Майкрософт. 'nuff сказав https://github.com/dotnet/core .
Зараз потрібно було б спробувати ці інструменти / фреймворки і подивитися, наскільки велике тертя. OP хоче писати на C # для JVM, який насправді може працювати досить добре, використовуючи Grasshopper.
Зробити це з метою поєднання бібліотек світу C # та Java в одній кодовій базі може не працювати так добре.
Джерела
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
Може бути простіше написати перетворювач з IL в байт-код. Таким чином ви автоматично отримаєте підтримку будь-якої мови .NET на JVM.
Однак це настільки очевидна ідея, що якщо цього ще не було зроблено, це, мабуть, надзвичайно важко, або важко зробити добре / корисно.
Подивіться на Коник . Це SDK на основі Visual Studio та запатентований конвертер .NET to Java, який дозволяє запускати веб-програми та серверні програми .NET на Linux® та інших платформах із підтримкою Java.
Варіантом крос-платформної розробки в C # може бути моно: http://www.mono-project.com/
Ви можете використовувати компілятор джерело-джерело для перекладу C # на мову, яка працює на JVM. Наприклад, існує кілька перетворювачів C # в Java, які дозволять програмам C # працювати на JVM після перекладу на Java.
Ця відповідь може запізнитися для вас, але ця лише нова. Можливо, ви захочете перевірити мову програмування Kotlin . Він пропонує синтаксичні цукри, які є в C #, і їх найближчий до синтаксису C # теж, крім будь-якої мови JVM, що не є Java. Це від JetBrains .
Я бачу дві причини, чому це не викликає особливого ентузіазму.
Перше, що слід усвідомити, це те, що коли мова заходить про фактичні особливості мови, 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 заявила, що вони будуть співпрацювати.