В свете иска Oracle к Google из-за Android-а и из-за планов Oracle по разделению JVM на бесплатную и платные версии, озадачился вопросом:
А почему бы какому-нибудь крупному игроку IT-рынка не сделать новый язык, для которого Java будет всего лишь синтаксическим подмножеством? С трансляцией не в Java-овский байт-код, а, скажем, в нативный код.
Ну, например, Google забьет на Java и сделает Goava. И пофигу тогда будут попытки Oracle заработать на JVM для Android-ных устройств. Если для Goava обычные Java программы/библиотеки будут лишь частным случаем Goava программ, тогда Android-ный софт достаточно будет лишь перекомпилировать. Да и аппаратных платформ особо много поддерживать не нужно – ARM, Intel x86. Ну, может, еще MIPS какой-нибудь подтянется. Впрочем, сложностей особых здесь все равно не должно быть, ведь в GCC-ном бэк-енде все эти платформы сейчас, AFAIK, поддерживаются.
Впрочем, Google все это вряд ли нужно (если только от нового языка они не получат прироста производительности для своих server-side Java-приложений).
А вот, например, взять Intel. Есть же у Intel-а классный C++ный компилятор, который генерирует чуть ли не лучший код для Intel-овских процессоров. Взяли бы и сделали аналогичный но для Iava с сильной оптимизацией нативного кода для своих Atom-ов. А то ведь на рынке портативных устройств у Atom-ов сильный конкурент в лице ARM-а.
И совсем фантастическая идея – Microsoft. Возьмут и сделают новый язык для платформы .NET, который будет иметь Java-синтаксис, но генерировать будет MSIL. А потом на нем под .NET портируют Apache Harmony :)
Ну или просто какая-то компания выпускает свой язык и транслятор под него. И живет за счет продаж транслятора (например, как в варианте с EiffelStudio/GNATPro где есть бесплатная и платная версии среды разработки), тогда как runtime языка остается бесплатным.
Такие вот мысли вслух.
По ходу проблема только в патентах. Как показывает Android задача "переписать JVM с нуля оставив совместимость на уровне исходников" вполне себе по силам крупной и амбициозной конторе за вполне вменяемое время.
ОтветитьУдалитьЯ думаю, что проблема не в патентах. Имхо, Oracle хочет выжать деньги из двух огромнейших ниш, в которых Java рулит: большой server-side и мобильные платформы (читай Android-устройства).
ОтветитьУдалитьИ если в первой нише все более-менее спокойно -- при той стоимости корпоративных систем, затраты на платную JVM не будут чем-то серьезным как для разработчиков, так и для пользователей.
А вот с мобильными устройствами ситуация иная. Там даже очень низкая стоимость лицензии на JVM, но помноженная на количество устройств (а их будут миллионы, если не сотни миллионов) означает существенные убытки для производителей устройств. Но и серьезную прибыль для Oracle.
Поэтому Oracle и не хочет давать возможность создать альтернативную JVM. А патенты здесь только средство для того, чтобы это сделать. Может быть, не единственное.
вслух пишется слитно...
ОтветитьУдалитьGo для этой цели не подойдет? :)
Вообще ИМХО платформа - понятие абстрактное.. JRE в этом плане ничем не отличается от native x86 или ARM... В смысле, весь вопрос в соответствующем трансляторе...
Тот же Dalvik... он видимо достаточно серьезно отличается от JVM, чтобы Google мог спать спокойно. Не знаю что у него внутри.
Оракл вообще маздай. Все сообщество против себя настраивают. Офис, Жаву, Солярку зажали... Денег наверное больше хотят.
>вслух пишется слитно...
ОтветитьУдалитьСпасибо, исправил.
>Go для этой цели не подойдет? :)
Не, тут нужна близкая к 100% совместимость с существующим Java-кодом на уровне исходников. Чтобы разработчики Java-приложений могли просто оттранслировать свои наработки новым транслятором и все.
>Денег наверное больше хотят.
Ага:
But Oracle's not a developer-oriented company (like Sun)...it's a profit-oriented company (unlike Sun, sadly)
>Тот же Dalvik... он видимо достаточно серьезно отличается от JVM, чтобы Google мог спать спокойно. Не знаю что у него внутри.
ОтветитьУдалитьНасколько я понял, проблема с Dalvik-ом в том, что это все-таки разновидность виртуальной машины для Java путь и со своей системой команд (а на java байт-кодом). Поэтому-то Oracle раскопала какие-то патенты, которые касаются именно особенностей работы виртуальной машины.
>>Go для этой цели не подойдет? :)
ОтветитьУдалить>Не, тут нужна близкая к 100% совместимость с существующим Java-кодом на уровне исходников. Чтобы разработчики Java-приложений могли просто оттранслировать свои наработки новым транслятором и все.
Собственно я про это и говорил в плане платформ... В принципе можно что угодно оттранслировать во что угодно... gcj, если не ошибаюсь может обычный бинарный код из java генерировать, или ошибаюсь?
Собственно java - это просто язык.. что подразумевается под java++ - новый язык? Дык это никак не связано с jvm...
Или кто-то должен разработать jvm++? Чтобы Оракл уже наконец таки проглотил свои патенты... :)
Дык есть Dalvik. Который видимо ради того и разрабатывался. Но на хитрую задницу... Всего не учтешь.
>gcj, если не ошибаюсь может обычный бинарный код из java генерировать, или ошибаюсь?
ОтветитьУдалитьРаньше точно умел, но потом, вроде бы проект заглох за ненадобностью. Выхлоп получился ну уж очень слабым. И, помнится, не все там из Java поддерживалось.
>что подразумевается под java++ - новый язык?
Да, новый язык. Более современный и мощный. Но в который Java будет входить как подмножество. Типа того, как было с C++ и C.
>Дык это никак не связано с jvm...
В том-то и дело, что JVM идет лесом в таком случае.
>Дык есть Dalvik. Который видимо ради того и разрабатывался.
Да ради этого. Но Dalvik все-таки виртуальная машина. Плюс это все-таки Java, которой владеет Oracle. Посему и наезд.
А если и не Java, и ни виртуальная машина, то тогда Oracle не у дел :)
Вроде D почти является таким языком, во всяком случае я слышал что первоначальную версию DWT http://www.dsource.org/projects/dwt транслировали автоматически.
ОтветитьУдалить@Rustam:
ОтветитьУдалитьДа, почти автоматически транслировали (после трансляции что-то допиливали напильником, но по-мелочам).
Однако, это не вариант. Нужно чтобы те же самые исходники можно было компилятору скормить без преобразования.
Разве что компилятор будет промежуточное представление в D создавать...
Но тут еще важно, чтобы новый язык вкусные плюшки разработчику давал. Т.е. хочешь чистую Java -- нет проблем, а хочешь -- вот тебя лямбды, unsigned-целые, необязательные спецификации исключений...
Долго ржал на Iava :-) Не хватает только Йava.
ОтветитьУдалитьgcj действительно существует, есть Compiled Native Interface вместо JNI... давно я на него не глядел
а что так на яву потянуло?
>Долго ржал на Iava :-)
ОтветитьУдалитьСпасибо, я старался :)))
>gcj действительно существует
Что-то там все новости 2009-м годом датированы. И у GNU Classpath-а тоже. Мож они не живые уже?
>а что так на яву потянуло?
Потянет тут, когда на фирме больше 80% разработчиков на Java программируют... Тем более, что у меня с Java заклятая любовь с первого взгляда :)
> Что-то там все новости 2009-м годом датированы. И у GNU Classpath-а тоже. Мож они не живые уже?
ОтветитьУдалитьнасчет GNU Classpath не знаю (а он вообще нужен при наличии исходников JDK?), но поддерживать gcj на плаву думаю несложно -- в дебиане он есть во всех 3 ветках
gcj можно рассмотреть как способ посадить мартыш^Wявиста в проект, где пишут плюсисты (я не говорю, что это будет работать; раньше давно например явовские исключения конфликтовали с плюсовыми исключениями -- а щас не знаю)
а вот как посадить плюсиста в команду, пишущую на яве, не очень понятно
в принципе, поверх JVM можно поменять синтаксис языка; можно видимо инстанциировать шаблоны, чтобы специализовать коллекции типа vector; но бороться c отсутствием беззнаковых потребует своей JVM (а это ФАТАЛЬНО); как бороться с обязательностью исключений тоже не ясно
гораздо проще, по-моему, добавить какие-то расширения в gcj или написать что-то похожее на gcj
опять же вопрос -- зачем нужна ява? ради библиотек? ну и где там что-то похожее на libcurl например?
а если ради фич языка -- то сделать красивенький и безопасный язык со сборкой мусора поверх с++ полезно; дальше конечно полезно было бы уметь *конвертировать* явовский код в него
за счет некоторого общего снижения производительности можно сделать realtime compacting GC -- т.е. сборщик мусора будет гарантированно размораживать мир через 5 мс например (при этом не-рост объема мусора требует достаточную мощность проца)
имхо сделать что-то совместимое с jvm на 2-3 десятичных порядка сложнее, чем сделать свой realtime compacting GC для с++ на х86, совместимый только с самим собой (хотя конечно надо посмотреть на llvm)
* чтобы специализовать коллекции типа vector< bool >
ОтветитьУдалитьИ совсем фантастическая идея – Microsoft. Возьмут и сделают новый язык для платформы .NET, который будет иметь Java-синтаксис, но генерировать будет MSIL.
ОтветитьУдалитьJ#? Так он, по-моему, уже не развивается.
@Quaker:
ОтветитьУдалить>J#? Так он, по-моему, уже не развивается.
Вроде того. Но, во-первых, все-таки нужна не еще одна Java, а новый язык (более мощный), для которого "чистая" Java будет только подмножеством.
Во-вторых, когда MS работала над J#, то смысла в нем было не много, т.к. у Sun-а не было никаких планов по монетизации стандартной JVM. Сейчас ситуация изменилась.
@имя:
ОтветитьУдалить>опять же вопрос -- зачем нужна ява? ради библиотек?
Я вижу ситуацию так: Oracle хочет зарабатывать на Java деньги. Простой способ достичь этого -- заставить производителей мобильных устройств платить за каждую копию JVM на своих устройствах. Т.е. продает Sony 500K телевизоров с Android-ом на борту -- будь любезна заплатить по $0.5 (или $1.5) за лицензию для каждого телевизора.
Понятно, что если такое произойдет, то производителям будет не с руки связываться с JVM -- это же убытки. И тут появляется кто-то, кто говорит -- вот вам компилятор нового языка, полностью совместимого с Java. Средства разработки стоят, например, $10K, но зато скомпилированный код никакими дополнительными лицензиями не облагается. И вам достаточно просто свой софт перекомпилировать -- всех делов, и никаких больше отчислений Oracle.
А Java тут нужна для того, чтобы миллионы строк уже написанного Java кода не пришлось ни выкидывать, ни переписывать.
насчет оракул версус гугль -- я думаю, в гугле не дураки были, и точно, что им патенты были предъявлены *до* того, как они сделали андроид -- посему ставлю на то, что оракл уйдет из суда, поджав хвост
ОтветитьУдалитьно даже и если, вдруг, суд найдет нарушение -- то гугль может найти какое-то нестандартное решение, вроде он-лайн сервиса компиляции исходников
а насчет расширения явы чем-то там -- могут быть проблемы, вот микрософт же погорела на этом
> новый язык (более мощный), для которого "чистая" Java будет только подмножеством.
ОтветитьУдалитьЯ искренне надеюсь что такого никогда не случится. А то получится ещё один C++ - так нафига это надо...
В нынешних реалиях правильный язык можно написАть только с нуля (я о языке а не о платформе), чтобы максимально выкорчевать всё жуткое наследие C.
>посему ставлю на то, что оракл уйдет из суда, поджав хвост
ОтветитьУдалитьПосмотрим. Я боюсь, что это будет дело не быстрое.
>чтобы максимально выкорчевать всё жуткое наследие C.
ОтветитьУдалитьКроме синтаксиса :)
> Кроме синтаксиса :)
ОтветитьУдалитьСинтаксис - в первую очередь.
Хотя тут дело такое - во-1 кто что понимает под синтаксисом - для одних синтаксис у джавы и си одинаковый, для других нет. Ну а во-2 мне по большому счёту плевать на то какой будет синтаксис - практика показывает что к синтаксису питона или хаскеля привыкаешь довольно быстро, так что эта штука не слишком для меня принципиальная.
@Left:
ОтветитьУдалить> А то получится ещё один C++ - так нафига это надо...
У C++ было так: взяли простой, но небезопасный язык, а сделали сложный и еще более небезопасный.
У Scala происходит так: взяли в меру простой, но безопасный язык, а сделали сложный, но безопасный язык.
Имхо, из Java можно сделать более простой, но все еще безопасный язык.
Си нифига не простой язык. С соотношением сложность / фичерность у него всё офигеть как плохо. Сравни к примеру с паскалем - при +/- той же фичерности сложность паскаля в разы меньше, синтаксис намного проще и исключений в синтаксисе в разы меньше.
ОтветитьУдалить>практика показывает что к синтаксису питона или хаскеля привыкаешь довольно быстро, так что эта штука не слишком для меня принципиальная.
ОтветитьУдалитьА вот у меня с Python-овским синтаксисом не сложилось. И ML-евский синтаксис идет с трудом (хотя более-менее привыкнуть можно).
А вот C-шный или Pascal-евский без проблем.
К тому же я думаю, что синтаксис не последнее дело в популярности языка. Керниган и Ричи какую-то очень удачную комбинацию нашли.
>Си нифига не простой язык.
ОтветитьУдалитьВидно давно я на plain-C не писал. Что-то я там не помню сложностей. Разве что неоднозначности синтаксиса местами.
А Pascal -- да, образец продуманности. Но, почему-то в массы промышленных программистов не пошел. Ни он, ни Modula-2. Остались где-то в узких нишах.
Под сложностью языка я в данном контексте понимаю размер его спецификации + количество волос вырваных из задницы разработчика при имплементации компилятора по этой самой спецификации. Где-то так, ага.
ОтветитьУдалить@Left: да, с такой метрикой сложности соглашусь. Я же говорил о сложности использования языка разработчиком.
ОтветитьУдалитьИ тут появляется кто-то, кто говорит -- вот вам компилятор нового языка, полностью совместимого с Java.
ОтветитьУдалитьА где гарантии того, что Oracle под различными предлогами не придушит этого кого-то, завалив судебными разбирательствами?
p.s. Что касается Си, то вежде при возможности стараюсь использовать библиотеку Glib (http://en.wikipedia.org/wiki/GLib), там много всяких дополнений/улучшений.
>А где гарантии того, что Oracle под различными предлогами не придушит этого кого-то, завалив судебными разбирательствами?
ОтветитьУдалитьДык, вроде, синтаксис языка не патентовали :)
Хотя кто его знает в этой помешанной на тяжбах Американдии :)))
>Что касается Си, то вежде при возможности стараюсь использовать библиотеку Glib
Так отсюда, вроде, уже и до Vala недалеко. Не используете? ;)
Так отсюда, вроде, уже и до Vala недалеко. Не используете? ;)
ОтветитьУдалитьСпасибо за наводку, пока использовать не доводилось. Возможно стоит попробовать. Единственное, что пока это еще несколько сырая разработка (http://habrahabr.ru/blogs/linux/99885/). Да и реальных приложений немного. Возможно, стоит присмотреться также к Mono - проект быстро развивается.
p.s. А Вы, Евгений, программируя на C++, используете какие-нибудь подобные библиотеки (не относящиеся к GUI), например модуль QtCore от Qt?
>Единственное, что пока это еще несколько сырая разработка
ОтветитьУдалитьЕсли не ошибаюсь, то Vala активно развивается уже года 3-4. Раньше на LOR-е регулярно были анонсы о релизах языка.
>например модуль QtCore от Qt?
QtCore -- нет, не используем. Когда вышла Qt4 мы не сразу купили на нее лицензию, поэтому успели много чего написать и без Qt.
В качестве базовых библиотек у нас ACE и POCO. Может со временем решимся и на Boost.