Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
Вот бы написать конвертер .Net-байткода в Java-байткода…
А то люблю шарп, но джава на большем кол-ве платформ есть…
В том числе и на андроиде)
А то люблю шарп, но джава на большем кол-ве платформ есть…
В том числе и на андроиде)
посмотрите в сторону Grasshopper
по-моему, не получится с его помощью писать под андроид на C#
под андроид вряд-ли, для «А то люблю шарп, но джава на большем кол-ве платформ есть…» вполне может сгодиться.
хотя я на него смотрел много лет назад, еще когда они из альфы только вылупливались. тогда оно мне не пригодилось и до сих пор жесткой необходимости не возникало, за сим не колупал и не в курсе что оно может а что нет…
хотя я на него смотрел много лет назад, еще когда они из альфы только вылупливались. тогда оно мне не пригодилось и до сих пор жесткой необходимости не возникало, за сим не колупал и не в курсе что оно может а что нет…
я тоже подумал что надо ждать обратного — .NET CLR, работающего поверх JVM
не получиться, JVM имеет более скупой набор команд.
Возможно в обе стороны.
Как раз писал статью про современную трансляцию. Кому-нибудь будет интересно, как оттранслировать из Java в Objective-C, Cocoa приложение под iPhone?
- Если говорить о трансляции байт-кода, то, например &mdash XMLVM.
- Если говорить о CLR на JVM, то — Grasshopper.
- Если говорить о JVM на CLR, то — IKVM.NET.
Как раз писал статью про современную трансляцию. Кому-нибудь будет интересно, как оттранслировать из Java в Objective-C, Cocoa приложение под iPhone?
Кстати, сейчас многие из сообщества Java разработчиков смотрят в сторону Clojure.
А сообщество .NET разработчиков интересуется F#. Но и C# с Java развиваются и эволюционируют.
Главная цель, как сказал Эндерс Хэйлсбер (Anders Hejlsber) все нововведения призваны повысить производительность программистов.
А сообщество .NET разработчиков интересуется F#. Но и C# с Java развиваются и эволюционируют.
Главная цель, как сказал Эндерс Хэйлсбер (Anders Hejlsber) все нововведения призваны повысить производительность программистов.
Проет супер интеерсен, но ни Sun ни MS друг друга поддерживать не будут… Не те у них отношения ;) ИМХО
Учёные скрестили слона с ежом, ну так, чисто посмотреть, что из этого выйдет, и как будет происходить.
Но на самом деле — выдающийся язык среди клонов на CLR. Прикольно.
Но на самом деле — выдающийся язык среди клонов на CLR. Прикольно.
Но с другой стороны — непонятно зачем. Ведь есть C# с очень похожим си-подобным синтаксисом. А очень многие opensource-библиотеки для Java портированы на .NET.
судя по блогам разработчиков — цель проста. запускать Java приложения (в идеале даже без перекомпиляции) на .NET
Для запуска Java-приложений есть IKVM, статья о котором в Википедии появилась в 2005 году, а самому продукту уже лет пять, наверное…
> непонятно зачем
Есть множество мощных библиотек на Java, их перенос и поддержка под дотнет — сложный и затратный процесс, поэтому многие порты умирают в отсутствие добровольцев.
Пример — удачная библиотека FOP и не особенно удачный порт NFop.
Есть множество мощных библиотек на Java, их перенос и поддержка под дотнет — сложный и затратный процесс, поэтому многие порты умирают в отсутствие добровольцев.
Пример — удачная библиотека FOP и не особенно удачный порт NFop.
всегда считал такие скрещивания опасными для конечной производительности продукта…
это разные языки и использовать их нужно там, где ими пользоваться… выгоднее и рациональнее…
а подобные эксперименты нужны для интереса, проб, и, возможно, проектирования (даже если это не цель, а только следствие) новых языков…
это разные языки и использовать их нужно там, где ими пользоваться… выгоднее и рациональнее…
а подобные эксперименты нужны для интереса, проб, и, возможно, проектирования (даже если это не цель, а только следствие) новых языков…
На самом деле эти две виртуальные машины довольно похожи. Где-то видел даже фразу о том что в них используются одни и те же алгоритмы сборки мусора. Кстати, .NET мог бы основываться на Java, но от этого пришлось уйти, в основном по причинам того что в MS хотели более тесной связи с найтивным кодом и COM.
Так что эти две технологии ближе чем кажется…
Так что эти две технологии ближе чем кажется…
Кстати, .NET мог бы основываться на Java, но от этого пришлось уйти, в основном по причинам того что в MS хотели более тесной связи с найтивным кодом и COM.Там было перетягивание каната: и Sun и Microsoft хотели иметь контроль над платформой. Боливар не выдержал двоих — и вот теперь мы имеем то, что имеем.
Они достаточно сильно отличаются. .Net использует JIT компиляцию, Java — интерпретацию.
Алгоритмы сборки мусора это не совсем то, что характеризует «схожесть» платформ. Многие алгоритмы реализованы уже для достаточно большого количества сред исполнения.
Однако, Вы правы обе платформы используют похожие алгоритмы сборки мусора. Этих самых алгоритмов, на самом деле, не так уж и много, вариаций алгоритмов, гораздо больше. Но есть некоторые «существенные» различия, например, реализация обобщений (generics).
Я сравнивал (и участвовал в реализации для Apache Harmony) алгоритмов сборки мусора для OpenJDK, Apache Harmony, Jikes RVM, CLR (по статьям исследователей и разработчиков алгоритмов сборки мусора для платформы) и проект Mono. Если это будет интересно некоторому количеству людей, то можно написать статью об этом.
Однако, Вы правы обе платформы используют похожие алгоритмы сборки мусора. Этих самых алгоритмов, на самом деле, не так уж и много, вариаций алгоритмов, гораздо больше. Но есть некоторые «существенные» различия, например, реализация обобщений (generics).
Я сравнивал (и участвовал в реализации для Apache Harmony) алгоритмов сборки мусора для OpenJDK, Apache Harmony, Jikes RVM, CLR (по статьям исследователей и разработчиков алгоритмов сборки мусора для платформы) и проект Mono. Если это будет интересно некоторому количеству людей, то можно написать статью об этом.
Первая мысль после прочтения заголовка была: «На хрена козе баян?»
Прочитал и задумался.
А потом решил, что вполне можно учить один язык в сравнении с другим (:
Прочитал и задумался.
А потом решил, что вполне можно учить один язык в сравнении с другим (:
хм… Жаннет… красиво звучит :)
> на свет появилось уникальное творение — JVM, работающая под Microsoft .NET Framework
Прям так уж и уникальное. А как же IKVM.NET?
en.wikipedia.org/wiki/IKVM
Прям так уж и уникальное. А как же IKVM.NET?
en.wikipedia.org/wiki/IKVM
«Ja.NET uses the J# model. For the standard Java libraries, they are recompiling Apache Harmony source code directly into IL assemblies.»
Я конечно не изучал тонкости отличия Ja.Net от IKVM, но вопрос. Разве в IKVM не используется тоже скомпилированный JDK(OpenJDK)? — IKVM.OpenJDK.ClassLibrary.dll.
ЗЫЖ не хочу сказать, что проект Ja.Net ненужен, но просто статья написано, словно они первые. При это на IKVM.NET уже давно запускаются проекты уровня эклипс.
ЗЫЖ не хочу сказать, что проект Ja.Net ненужен, но просто статья написано, словно они первые. При это на IKVM.NET уже давно запускаются проекты уровня эклипс.
Используется. Но авторы Ja.Net, похоже, не любят GPL, потому ухватились за Harmony. Мой прогноз: всё заглохнет. Много желающих попользоваться «халявой», предоставляемой Apache License, мало желающих что-либо разрабатывать. Если бы они делали свою собственную платформу (a-la Android) — был бы шанс, а так… Ну много ли бужет желающих пыжится-пыжится — и всего лишь получить возможности OpenJDK если свободно доступен сам OpenJDK?
их основная работа сейчас — компилятор.
А это — вообще тупик. Пустая трата времени. Если вы посмотрите на GCJ (до версии 4.3), то обнаружите что компиляция по дорожке .java->.class->.o даёт почти ту же скорость что и прямая компиляция .java->.o. В версии 4.3 от «прямого пути» отказались вообще — вместо этого немного подправили имеющийся компилятор чтобы он сохранял чуть больше информации в .class файле.
В общем: не стоит овчинка выделки. Кроме собственно языка Java над JVM надстроено много чело, так что делать хороший компилятор .class->CRL им всё равно придётся — иначе весь проект Ja.NET окажется мёртворождённым. А на два сложных проекта их вряд ли хватит.
В общем: не стоит овчинка выделки. Кроме собственно языка Java над JVM надстроено много чело, так что делать хороший компилятор .class->CRL им всё равно придётся — иначе весь проект Ja.NET окажется мёртворождённым. А на два сложных проекта их вряд ли хватит.
насколько я понял разницу (а я мог и ошибиться, скорее всего даже ошибся), IKVM — это только портированная под .NET ява-машина, интерпретирующая JVM-код. а Ja.NET — предлагает еще и компилятов из Java в MSIL (виртуальную машину для запуска native-Java они как раз еще не достроили). и потому Ja.NET — быстрее, но требует перекомпиляции. со временим они сделают и запуск NativeJava, и взаимодействие JVM — CLR, но со временем.
IKVM — это только портированная под .NET ява-машина, интерпретирующая JVM-кодНифига подобного. Прямо на главной странице написано: Just-in-time compiles Java Byte Code to CIL.
а Ja.NET — предлагает еще и компилятов из Java в MSIL (виртуальную машину для запуска native-Java они как раз еще не достроили).Вообще всё это напоминает потуги пары студентов: товарищи из Ja.NET схватились за самую прикольную, самую вкусную, самую опциональную часть проекта в первую очередь. Ну неинтересно им заниматься рутиной. Я бы понял если бы они сделали свой компилятор как дополнение к существующией платформе (тому же IKVM), но когда люди начинают делать торт с создания красивой розочки из крема, то возникает вопрос: а они вообще в своём уме?
и потому Ja.NET — быстрее, но требует перекомпиляцииБенчмарки есть?
со временим они сделают и запуск NativeJava, и взаимодействие JVM — CLR, но со временем.Отлично! Гениально! Грандиозно! Отличный способ угробить проект! 99% гарантия. Делать не то, что нужно пользователям вашего проекта, а то, что интересно вам — это типичная ошибка «студенческих проектов» из которых ничего никогда не вырастает. Сначала нужно сделать что-то, чем можно пользоваться, потом заниматься его улучшением. «Прямой» компилятор .java=>CLR вообще не является частью «базового комплекта»: загрузчик .class-файлов вам нужен всё равно (без этого куча вещей не будет работать), так зачем вам «прямой» компилятор до того как ваша платформа может быть реально использована?
ну замечательно. вы высказались. раскритиковали все. кому от этого стало лучше кроме вас?
никому.
то что Ja.NET — явно еще на никакой стадии развития — видно невооруженным взглядом. применимость — тоже под большим вопросом.
но ведь проект от этого не становится менее интересным для того чтобы с ним позанкомиться.
а так — уж простите, складывается впечатление что вас прям щаз заставляют портировать весь Netbeans на Ja.NET, а вы приводите аргументы против. :-)
никому.
то что Ja.NET — явно еще на никакой стадии развития — видно невооруженным взглядом. применимость — тоже под большим вопросом.
но ведь проект от этого не становится менее интересным для того чтобы с ним позанкомиться.
а так — уж простите, складывается впечатление что вас прям щаз заставляют портировать весь Netbeans на Ja.NET, а вы приводите аргументы против. :-)
ну замечательно. вы высказались. раскритиковали все. кому от этого стало лучше кроме вас?Всем кто интересуется запуском Java под .NET, очевидно.
то что Ja.NET — явно еще на никакой стадии развития — видно невооруженным взглядом. применимость — тоже под большим вопросом.Именно. И зачем оно кому-то надо? Когда есть работающая альтернатива (про которую, кстати, авторы Ja.NET даже не упоминают — почему, интересно?).
но ведь проект от этого не становится менее интересным для того чтобы с ним позанкомиться.Смотря для чего. Если вы хотите реально помочь людям у которых есть подобная же потребность — для вас есть IKVM. Для интеллектуальных упражнений лучше haskell или Erlang.
а так — уж простите, складывается впечатление что вас прям щаз заставляют портировать весь Netbeans на Ja.NET, а вы приводите аргументы против. :-)А зачем оно мне есть шансов на то, что я там смогу запустить Eclipse (Netbeans не пользуюсь) в ближайшем будущем примерно нуль? Посмотрите на письмо Linus'а хотя бы. Видите разницу? Вместо Our vision is simple: Establish a community of interest, together with a set of projects, focused on delivering the tools and middleware required to leverage the enormous investments that exist today in Java software on the .NET platform. мы имеем I've currently ported bash(1.08) and gcc(1.40), and things seem to work.. Things seem to work ведёт к Linux'у, vision ведёт к HURD'у — что вы предпочитаете? Если вам уж так нечем заняться — займитесь лучше HURD'ом. Там цели ещё грандиознее, а шансов на успех ещё меньше.
Давайте я помогу.
«разработчики», «кропотливого», «заброшенный», «в отличие», «серьёзная», «именитые », «в отличие», «надеяться».
«разработчики», «кропотливого», «заброшенный», «в отличие», «серьёзная», «именитые », «в отличие», «надеяться».
Если бы портировали .NET окружение в Java, я бы ещё понял — это даст дотнету кросплатформенность.
А какие могут быть причины для того, чтобы делать обратное действие?
А какие могут быть причины для того, чтобы делать обратное действие?
«студенты» не любят java. они любят.НЕТ и потому сделали свой «студенческий проект» каким им захотелось
По поводу кроссплатформенности могу порекомендовать Mono. Проект очень интенсивно развивается.
Mono всегда будет позади .NET'a, потому что только догоняет его по определению. Как сейчас, так и в будущем это отставание будет на несколько больших шагов. Mono отлично подходит если надо портировать что-то с Windows на Linux, но изначально выбирать обрезок в качестве платформы — абсурд.
Ваше утверждение не совсем верно. Например одно из нововведений, о которых говорил Anders Hejlsberg — компилятор как сервис (Compiler as Service) уже реализован в Mono и уже реализована REPL (read-eval-print-loop) консоль. Также Mono работает и на BSD и Mac OS X, причем есть Cocoa# для создания оригинальных (для Mac) интерфейсов.</P
Благодаря Mono есть такие приложения как: Tomboy, Banshee, Incollector. Mono очень активно развивается, и если Вы посмотрите на этот проект изнутри, то увидите, что это по-настоящему серьезный проект.
Благодаря Mono есть такие приложения как: Tomboy, Banshee, Incollector. Mono очень активно развивается, и если Вы посмотрите на этот проект изнутри, то увидите, что это по-настоящему серьезный проект.
Основная суть Mono — это синхронность с .NET, чтобы как в Java «написал однажды, запускаешь везде».
В Java так и есть и было бы странно, если бы на Linux было одно множество функций, предоставляемых SDK, а на Windows — другое. Java никто не использовал бы в этом случае.
Будущее Mono мне видится не менее туманным, чем будущее Wine: как костыль при портировании сойдет, а реальных преимуществ при написании нового проекта перед той же Java — нет, даже наоборот.
В Java так и есть и было бы странно, если бы на Linux было одно множество функций, предоставляемых SDK, а на Windows — другое. Java никто не использовал бы в этом случае.
Будущее Mono мне видится не менее туманным, чем будущее Wine: как костыль при портировании сойдет, а реальных преимуществ при написании нового проекта перед той же Java — нет, даже наоборот.
Вы правы в том что, Mono следует и скорее всего будет следовать, курсом за CLR и будет догонять основную платформу.
Я всего лишь хотел сказать, что уже есть проекты написанные для Mono под Linux. Mono уже входит в стандартную поставку Ubuntu Linux, также как и проекты написанные для Mono, например, Tomboy.
Перспективным, также, на мой взгляд, является Moonlight — Silverlight от Mono team. Я активно слежу за развитием платформы CLR, но также и за развитием Mono. Это очень динамично развивающиеся проекты.
Будущее Mono стало чуть менее туманным после покупки Novell'ом основных разработчиков Mono — Ximian, затем и ещё чуть менее туманным после заключения договора между Novell и Microsoft.
Я всего лишь хотел сказать, что уже есть проекты написанные для Mono под Linux. Mono уже входит в стандартную поставку Ubuntu Linux, также как и проекты написанные для Mono, например, Tomboy.
Перспективным, также, на мой взгляд, является Moonlight — Silverlight от Mono team. Я активно слежу за развитием платформы CLR, но также и за развитием Mono. Это очень динамично развивающиеся проекты.
Будущее Mono стало чуть менее туманным после покупки Novell'ом основных разработчиков Mono — Ximian, затем и ещё чуть менее туманным после заключения договора между Novell и Microsoft.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ja.NET — Java для .NET