В рамках проекта TeaVM (http://teavm.org/) развивается компилятор, позволяющий компилировать Java-байткод в JavaScript и WebAssembly для последующего выполнения в браузере. Ключевым отличием от проекта GWT (http://www.gwtproject.org/) (Google Web Toolkit) является то, что TeaVM выполняет трансляцию на уровне байткода (может компилировать файлы *.class или *.jar), без привязки к исходным текстам на языке Java, что позволяет компилировать проекты на языках Kotlin и Scala. Код TeaVM распространяется (https://github.com/konsoletyper/teavm) под лицензией Apache 2.0.
Основной целью TeaVM является предоставление средств по созданию web-приложений для разработчиков знакомых с Java, унификации платформы для разработки (фронтэнд на базе те же технологий, что и бэкенд) или при необходимости задействования в web-приложении уже имеющегося кода на Java. TeaVM по возможности сохраняет оригинальную структуру методов, выдавая читаемый и понятный JavaScript. Для разработки одностраничных web-приложений на Java, Kotlin или Scala предлагается web-фреймворк Flavour, похожий на Angular, но базирующийся а идиомах Java, а не JavaScript.
Для ускорения выполнения результирующего кода и сокращения его размера применяется изощрённый оптимизатор, который способен выполнять девиртуализацию виртуальных вызовов в статические вызовы функций, исключать неиспользуемый код, повторно использовать одну и ту же локальную переменную для хранения нескольких переменных, использовать сокращённые имена методов. Важной особенностью является поддержка преобразования в JavaScript многопоточного кода, который разворачивается в линейное представление с эмуляцией нескольких логических потоков в одном физическом потоке.
Также можно отметить фреймворк Substrate VM (https://github.com/oracle/graal/tree/master/substratevm), позволяющий выполнить компиляцию Java-приложений в форму самодостаточных исполняемых файлов или разделяемых библиотек (ELF-64 или 64-bit Mach-O). В Substrate VM применяется полноценная AOT-компиляция (Ahead-of-Time) без симуляции через запуск байткода в виртуальной машине. Фреймворк распространяется под лицензией GPLv2 и развивается компанией Oracle в рамках проекта Graal (https://github.com/oracle/graal) по разработке нового JIT-компилятора и runtime для JVM.URL: https://news.ycombinator.com/item?id=16075933
Новость: http://www.opennet.me/opennews/art.shtml?num=47940
Мы сделали разные языки, каждый из которых решает свою задачу эффективнее.
А теперь мы возмем самый медленный и ограниченный и будем в него транслировать остальные.
Какую же задачу решает Java эффективно?
задачу тормозить
> задачу тормозитьНе путай Java с JS.
Они оба с этой задачей справляются отлично. Благодаря сабжу, я уверен, ещё улучшат свои показатели.
Производительность явы близка к сишной. Производительность JS-а крайне хороша из-за неименьшего iowait-а.
Для меня вполне очевидно, что вы попросту пишите кривой код.
> Производительность явы близка к сишной.Это после нескольких тысяч итераций, когда JIT скомпилировал код. Другими словами, это работает только на высоконагруженных сервисах (где и памяти как грязи) и на бенчмарках.
Большинство же "пишущих кривой код" знакомы с ней по десктопным приложениям: всяким IDE и торрентокачалкам, где ни о каких тысячах итераций речи не идёт, в результате чего получаем фактически интерпретатор с соответствующей производительностью, но с требованиями к памяти как у больших дядь.
> Производительность JS-а крайне хороша из-за неименьшего iowait-а.
> Для меня вполне очевидно, что вы попросту пишите кривой код.Я уверен, что конкретно вы пишете на яваскрипте эффективный и производительный код, пользоваться которым - одно удовольствие. И мне жаль, что в повседневной жизни приходится пользоваться не вашим кодом, а кодом остальных 99.99999% приматов, которым до вас как до Луны пешком.
>> Производительность явы близка к сишной.
> Это после нескольких тысяч итераций, когда JIT скомпилировал код. Другими словами, это
> работает только на высоконагруженных сервисах (где и памяти как грязи) и
> на бенчмарках.Вы правы, Oracle HotSpot не все методы переводит в нативщину, а только те, которые набрали достаточное количество вызовов для того, чтобы их оптимизировать и преобразовать в процессорный код. Единица компиляции JVM - метод. Невызываемые методы, соответственно, никогда не джитятся.
И ещё, в "клиентской" 32-битной версии JRE используются совсем другие стратегии JIT-оптимизаций и сборки мусора, чем в "серверной" 64-битной JRE.
Когда речь заходит о десктопных приложениях - Ява действительно медлительна и прожорлива. Но на Яве (ровно как и на питоне и электроне) десктопные приложения пишут исключительно отбитые люди. Компетенция джавы - исключительно бекенды.
Что касается js - действительно, большинство веб сайтов и электрон приложений тормозит. Вот только вызваны эти тормоза отнюдь не js-ом, а убогостью веб технологий (хтмл, css, dom) и необходимостью из-за их убогости на стороне кода браузера кешировать все подряд, на стороне разработчиков - использовать фреймворк и на каждый чих, со стороны пользователя - покупать девайсы с тоннами оперативки.Сам же по себе js, будь то js из ноды или qtа, довольно производителен. Тебе придется очень постараться чтобы найти лагающее qml приложение. А сама нода так же успешно используется для хаулоуда.
>Тебе придется очень постараться чтобы найти лагающее qml приложениеСпасибо что напомнил - не в курсе как у плазмы чтобы отловить текущий виджет? А то они в процессах как один значатся
>Большинство же "пишущих кривой код" знакомы с ней по десктопным приложениям:Но ведь так и есть. Достаточно сравнить netbeans и geany на не слишком мощной системе. Первая и память отожрет и продолжит тормозить. Вторая летает и не жрет ничего.
Но у netbeans и у geany разные же весовые категории и набор функционала, не? Понятно, что нативное приложение будет меньше и быстрее при прочих равных, но так Вы же сравниваете приложения не одного уровня. Например, на java есть jedit: у него возможностей гораздо меньне, чем у netbeans, но так и по скорости и потреблению памяти он мильно выигрывает
> Но ведь так и есть. Достаточно сравнить netbeans и geany на не
> слишком мощной системе. Первая и память отожрет и продолжит тормозить. Вторая
> летает и не жрет ничего.В netbeans есть встроенный отладчик, профилировщик, интроспекция, фоновая компиляция, разбор и верификация DOM XML, автодополнение кода, куча плагинов. А в Geany что-нибудь из этого есть кроме подсветки синтаксиса и команд на кнопках? Geany надо сравнивать с jEdit, но не никак не с IDE.
Абсолютно согласен, java уже давно не уступает по производительности c/c++. Человек который пишет о том что java тормозит ничего не имеет общего с программированием в целом.
А приведите пример что на ней _не_ тормозит?
Даже если допустить, что не уступает(это не так), то она откусывает столько памяти, что вываливается даже на серверах. Я уже молчу про различные ситуации с джавовскими GC, про них легенды пишут и отдельные доклады рассказывают - как писать приложение под GC и правильно его потом настраивать.
> А приведите пример что на ней _не_ тормозит?Сервак лора - отклик моментальный. Сюрприз.
Дятел :)
LOR - Это почти на 146% - статика. Его можно с RaspberryPi с таким же откликом раздавать если от жабы избавиться и DB на другом серваке держать :-р
Чушь, вопрос был про быстрые приложения, поэтому смотри на время генерации страницы, а не картинки и js/css. Мы видим, что логика + база + рендер в шаблоны отрабатывает моментально.
> А приведите пример что на ней _не_ тормозит?Долгоработающие веб-сервисы на JVM вполне себе живут и здравствуют.
> Даже если допустить, что не уступает(это не так)
Зато она хорошо параллелится. А нынче при дешёвых ядрах это не так уж дурно.
> то она откусывает столько памяти, что вываливается даже на серверах.
Ну так это и плюс, и минус. Интеграторы, например, очень любят продавать решения на JVM, ибо они вкупе с ними продадут ещё и хорошее, дорогое железо. А тем, кто покупает такие решения и железо, как правило пофиг на память: это явно не самая большая статья расходов.
> Я уже молчу про различные ситуации с джавовскими GC, про них легенды пишут
Да, но в целой куче задач GC не сильно критичен. Вот например прокся на яве. Из-за GC каждый сотый запрос обрабатывается не мгновенно, а аж 60 секунд. Неприятно? Да. Критично? Нет. Юзер даже не заметит, что у него этот 1% выстрелил. Перезагрузит страницу, и всего делов-то.
Есть у меня традиция: Раз в пару лет качаю Eclipse на посмотреть, не стал ли он меньше тормозить. Удаляю спустя 10 минут.
Ну а в Android смотрю каждый день. Каждый день у меня наполнен блаженством от "нетормозящей" жабы.
> Есть у меня традиция: Раз в пару лет качаю Eclipse на посмотреть, не стал ли он меньше тормозить. Удаляю спустя 10 минут.На какой JVM вы запускаете Eclipse? Всё на старенькой, из JDK 6.0?
> Ну а в Android смотрю каждый день. Каждый день у меня наполнен блаженством от "нетормозящей" жабы.
В Android нет JVM. Там свой нескучный мирок интерпретаторов байт-кодов.
> В Android нет JVM. Там свой нескучный мирок интерпретаторов байт-кодов.1. Чем это JVM не подходит под определение "интерпретатор байт-кода"?
2. С каких это пор в OpenJDK не входит JVM?
>> В Android нет JVM. Там свой нескучный мирок интерпретаторов байт-кодов.
> 1. Чем это JVM не подходит под определение "интерпретатор байт-кода"?В Android не JVM, интерпретирующая проприетарный формат байт-кода Google.
> 2. С каких это пор в OpenJDK не входит JVM?
JVM входит в OpenJDK, но не входит в Android.
Поскольку Eclipse - это _единственная_ программа на ПК для которой приходится ставить JVM, качается всегда самая свежая. Потом ещё и её удалять приходится, чтобы она каждый день не вопила как истеричка, умоляя себя обновить. А что?
Вот только по сравнению с остальными ОС Андроид остаётся наиболее быстрым и нелагучим, что должно наводить на мысли.
Огласите пожалуйста весь список этих остальных ОС, с которыми проводились сравнения.
Айось, венда, линух, макось.
Никогда у меня не тормозили ни винда ни линукс на 2 ГБ оперативки от запуска целых ТРЁХ программок параллельно или открытия аж целых десяти вкладочек в браузере. А при попытке открытия аж целых пяти программулек андроид начинает биться конвульсиями в луже крови и свопить всё что может.
А тебе не приходила в голову такая простая мысль, что сравнивать надо на одинаковом железе и нагрузках?
Ну вообще-то тормозит, если у тебя приложение начинает отжимать больше 20 гигов, gc не хило так грузить начинает.
Да только отбитый человек может написать такое приложение вы скажете, но увы такое вполне себе бывает.
Ты хоть бы посмотрел требования к нагруженному elasticsearch например, не позорься.
> Абсолютно согласен, java уже давно не уступает по производительности c/c++.Просто компы стали быстрее и тормоза не так заметны
>java уже давно не уступает по производительности c/c++То то в wildfly 11 переключились с JSSE на OpenSSL. А оказывается зря...
Ещё из смешного: генератор биткоиновых адресов на жабке 20к в сек, на си 600к в сек.
> Ещё из смешного: генератор биткоиновых адресов на жабке 20к в сек, на си 600к в сек.Тут еще сильно зависит от программистов каждого генератора. Генератор на Си может писал какой-нибудь Дональд Кнут, а на яве - студент-первокурсник, ругающий себя за то что пошел учиться на программиста. А вообще к яве нарекания только за прорву сжираемой памяти и некоторую "многословность" исходного кода. Ну и временами "jar-hell" (может появившаяся в Java 9 "модульность" что-то упростит).
JSSE тоже первокурсники писали?
И bouncy castle первокурсники?>некоторую "многословность" исходного кода
По сравнению с си? Мусье вообще видел жабу в глаза?
>А вообще к яве нарекания только за прорву сжираемой памяти и некоторую "многословность" исходного кода.Это смотря у кого! Пойдёшь работать в кровавый телеком - быстро вкуришь что первое решается самым простым и я бы даже сказал - вульгарным ;) способом, второе - парит только первые 3 буквы девопса, а вот лаги, _непредсказуемые_ лаги, когда в самое ****ть! не подходящее время оно начинает GC ... это то, что вытесняет жабу в сектор максимум провижинга, а то и в CRM\склад\магазин :-\
Но есть и светлая сторона, Люк! : оттеда жабу не выдавит никто. И это надолго :)
>> Ещё из смешного: генератор биткоиновых адресов на жабке 20к в сек, на си 600к в сек.
> Тут еще сильно зависит от программистов каждого генератора. Генератор на Си может
> писал какой-нибудь Дональд Кнут, а на яве - студент-первокурсник, ругающий себя
> за то что пошел учиться на программиста.Это тоже Кнут с командой первокуров писали?
https://benchmarksgame.alioth.debian.org/u64q/java.html
> задачу тормозить и жратьНе благодари.
> Какую же задачу решает Java эффективно?На Java пишутся системы, которых вам не показывали, которые считают ваши деньги, если они у вас, конечно, есть.
Это те, для которых нужен сервер с кучей оперативной памяти? Которые нужно "прогревать" минут 20 ради офигенного JIT, где нужно создавать сложные файлы с директивами для компилятора и профайлы, чтобы ускорить это все? Это те которые из-за деоптимизаций и очень эффективной сборки мусора считают, что киент может подождать со своим ненужным подсчетом денег?Не, не видели, покажите.
> Это те, для которых нужен сервер с кучей оперативной памяти? Которые нужно
> "прогревать" минут 20 ради офигенного JIT, где нужно создавать сложные файлы
> с директивами для компилятора и профайлы, чтобы ускорить это все? Это
> те которые из-за деоптимизаций и очень эффективной сборки мусора считают, что
> киент может подождать со своим ненужным подсчетом денег?
> Не, не видели, покажите.Показываю: http://samolisov.blogspot.ru/2016/04/java-ee-7-140-10.html
То, что ваш калькулятор денег на Java можно запустить на мейнфрейме как-то связано с его эффективностью?
Попробуйте поискать не случайную статью из интернета, а привести реальный пример, который никто не видел конечно же.
Ещё: https://codeborne.com/ru/2012/12/17/online-bank-from-scratch...Где ещё Java не тормозит: https://www.youtube.com/watch?v=TJUiTA-BluI
Волшебный пример (из 2013 года), ага, и вот что там написано самими аффтарами:
"Мы хотели писать на Java, так как имеем большой опыт с языком и платформой. Java ещё не мертва, если её использовать правильно" :) Но нынче то 2018-ый ...Ну подобьём итог:
- веб сайтик за пол-года. Ну так себе, пыхеры бы ещё быстрей управились бЭ ...
- не тормозит на вводе от юзеров. Аж целых 10\сек согласно аффтараф статьи ... не тормозит да? 8-)
А уж перлы: "Java запускается на Линуксе, администрирование которого в разы проще и быстрее, чем всяких там Виндовсов. Это мне за пивом подтвердили администраторы, намучившиеся с прежними решениями." - многое говорят о том _как_ такую команду допустили к самой мякотке :-))) Сынок чей-то походу, или отнесли назад 80% :-))))
Спасибо, отличные ссылки!
> Ещё: https://codeborne.com/ru/2012/12/17/online-bank-from-scratch...Оттуда же:
> Для маскирования невысокой производительности АБС мы используем интеграцию Play с memcached, что далеко не стандартное решение в мире Java.Что, как бы намекает.
Уже не обязательно прогревать, с 9 версии есть AOT
И работают эти системы на ОС, которые написаны на, внезапно, С.
> И работают эти системы на ОС, которые написаны на, внезапно, С.Работает, внезапно, не код на C, а код в машкодах того процессора, таргет-архитектура которого была указана в опциях компиляции программы на C. Если ОС ставили из бинарника [i386] на 64-битный процессор x86-64, то машкод не увидит расширенных регистров [amd64] и оперативную память больше 4GB. Так и будет оставаться 32-битным.
И как часто ты таскаешь свой старый код по разным архитектурам железа?
>И как часто ты таскаешь свой старый код по разным архитектурам железа?Какое убогое понимание переносимости ПО. Неужели ни разу не пробовал например под CentOS 6 скомпилить какую-нибудь прожку или либу, которая хочет последнюю poco и cmake и gcc и ядро. Гребубли на полдня, оно ведь даже явно не пишет, что ему не нравится. Потом на другом сервере с другим процом бинарник не работает, надо там ещё раз пересобирать.
Я понимаю, что ты уже привык и ничего слаще си не пробовал. Но на жабку зачем гавкать?
Хотя про смену аппаратной платформы ты и сам понимаешь насколько у си ЕЩЁ УЖАСНЕЕ ;)
В мире опенсорса перекомпилировать под другую аппаратную архитектуру это совершенно НОРМАЛЬНО. Поэтому появилась альтернатива Жабе в виде D, который изначально в машкоды компилит и без всяких там JVM.
> Потом на другом сервере с другим процом бинарник не работает, надо там ещё раз пересобирать."Другой проц"... Это на случай, когда вдруг нашли на складе ppc32?
> Гребубли на полдня, оно ведь даже явно не пишет, что ему не нравится.
В binary-based нет проблем собрать пакет, говорили они...
> Но на жабку зачем гавкать?
Может он пытается расшевелить её?
> Хотя про смену аппаратной платформы ты и сам понимаешь насколько у си ЕЩЁ УЖАСНЕЕ ;)
Ну а жаба-то, жаба то там откудавозьмётся?
>> Хотя про смену аппаратной платформы ты и сам понимаешь насколько у си ЕЩЁ УЖАСНЕЕ ;)
>Ну а жаба-то, жаба то там откудавозьмётся?Как обычно - из тины и грязи :)
Не ломай челу заменитель моска, он и так квакает очень уж жалобно :~~-(
Неужели у тебя небыло случая когда аппликуха на джаве требует определённую версию JVM, и это не всегда последняя версия ?
> Неужели у тебя небыло случая когда аппликуха на джаве требует определённую версию
> JVM, и это не всегда последняя версия ?Не было, жаба в обратную сторону совместимая. Со временем ломается только связанное с безопасностью, типа rsa1204bit больше нельзя.
Либо в коде стоит
if (!"blabla".equals(System.getProperty("java.version"))) return;
Можешь пойти и набить морду прогеру. Жаба тут непричём.
>Можешь пойти и набить морду прогеру. Жаба тут непричём.И по аналогии:
Когда ты видишь stack overflow error ... а нас за що?! да?! :-))))
> Какое убогое понимание переносимости ПО. Неужели ни разу не пробовал например под
> CentOS 6 скомпилить какую-нибудь прожку или либу, которая хочет последнюю poco
> и cmake и gcc и ядро.Неужели никогда не пробовал на CentOS 6 запустить какую-нибудь жабопрожку, которая требует распоследний JDK, причём непременно оракловский?
Давай пример проги, которая не работает в штатном jre 1.8
>ОС ставили из бинарника [i386] на 64-битный процессор x86-64, то машкод не увидит расширенных регистров [amd64] и оперативную память больше 4GB.И ровно то же самое произойдёт если ты будешь гонять свою жабу на 32-битной JVM :-))))
Зеня - перестань нюхать клей перед постингом сюды!
А впрочем ... доставляй! :)
>>ОС ставили из бинарника [i386] на 64-битный процессор x86-64, то машкод не увидит расширенных регистров [amd64] и оперативную память больше 4GB.
> И ровно то же самое произойдёт если ты будешь гонять свою жабу на 32-битной JVM :-))))JVM написана на C++ под определённую ОС. Выше головы или жо.ы не прыгнешь;) Зато можно написать программу на Java, которая работает и в 32-, и 64-х системах без необходимости перекомпиляции-пересборки (только нужную JVM подавай). Масштаб ощущаешь?
А в реале половина ваших прог работает только под форточкой а иногда и прибита в определённой версии\вендору JVM\JDK :-pНи и знаменитое - мы из опен сорса ... какая проблема _пересобрать_ то?!?!?! Это вам сырков не дают :-)
> А в реале половина ваших прог работает только под форточкой а иногда
> и прибита в определённой версии\вендору JVM\JDK :-p
> Ни и знаменитое - мы из опен сорса ... какая проблема _пересобрать_
> то?!?!?! Это вам сырков не дают :-)Не подскажешь, почему валится?:
% mate-system-monitor
<...>
(mate-system-monitor:83599): Gtk-CRITICAL **: gtk_tree_store_set_valist: assertion 'VALID_ITER (iter, tree_store)' failed(mate-system-monitor:83599): Gtk-CRITICAL **: gtk_tree_store_set_valist: assertion 'VALID_ITER (iter, tree_store)' failed
(mate-system-monitor:83599): Gtk-CRITICAL **: gtk_tree_store_get_value: assertion 'VALID_ITER (iter, tree_store)' failed
(mate-system-monitor:83599): GLib-GObject-WARNING **: gtype.c:4264: type id '0' is invalid
(mate-system-monitor:83599): GLib-GObject-WARNING **: can't peek value table for type '<invalid>' which is not currently referenced
LibGTop-Server(c=83600): [WARNING] pid 83600 received eof.
Ошибка сегментации
%- весь сишный стек пересобрал, все зависимые библиотеки - не могу победить ошибку сегментации mate-system-monitor при переключении на вкладку "Процессы".
> На Java пишутся системы, которых вам не показывали, которые считают ваши деньги, если они у вас, конечно, есть.Не, биржевое ПО пишут на вещах посерьёзнее. Например на OCaml.
А под JVM пишут в основном менее критичные вещи. Веб, DLP, IGA...
А, или вы про автоматы для оплаты всякой хрени, что в универмагах стоят? Тогда согласен. )
Инвалидная коляска для тех, кто не может писать ни на чём кроме джавы?
Попытка избавиться от джавы там, где легаси-код не перепишешь уже xD
> изощрённый оптимизатор)))
Не проще ли js выучить?
> Не проще ли js выучить?Тогда не будет повода написать еще одну Java машину и рассказать всем в интернете, что вы сделали это.
на pure-js пишут все меньше и меньше. оно превратилось в ассемблер мира web.
... и 100500 JS-фреймворков.
> Не проще ли js выучить?Апплеты не получились. Так хоть тушкой, хоть чучелком Java в web-браузер проберётся...
выучить-то не проблема.
Проблема в другом: если разрабатывать большие проекты с большой командой то он достаточно плох.
Будет много ошибок. язык позволяется слищком много. Компилятор слишком мало проверяет за программиста.
Для этого есть typescript и flow - выбирай на вкус. Или даже closure compiler, если совсем по олдскулу.
для использоватния в крупных проектах проще выучить майкрософтовский Typescript.
> для использоватния в крупных проектах проще выучить майкрософтовский Typescript.Есть ещё Elm-lang, он вообще изумительно ведёт себя в отношении ошибок. Но TS будет действительно проще :)
> Не проще ли js выучить?Не проще, если хорошо знаешь другие языки. И на них уже написаны многие тысячи строк работающего кода (я про веб-приложения, а не про системные утилиты). Сейчас вот напряжешься, выучишь ява-скрипт и перепишешь (за пару лет) все приложения. А позднее придется еще WebAssembly выучить и переписать всё "нажитое непосильным трудом" на него ( на ассемблере, хоть и веб :) ). А потом еще через пару лет несколько лет учить и переписывать все приложения на новый, вошедший в моду, XpенАссембли. Нет уж. Лучше потом с известного тебе (но распространенного) языка скомпилировать прикладухи в очередной новый модный "ассембли". Твой JS когда-то (в очень отдаленном будущем) будет не в своей виртуальной машине крутиться, а в машине ВебАссембли (чтобы две машины в браузере не держать и не распыляться с их поддержкой), как и компилированный код с других языков программирования. Т.е. разницы, что именно учить для веба, не будет, ява-скрипт встанет в один ряд и на один уровень с остальными языками (повторюсь - для веба!). Важно будет для языка наличие компилятора в ВебАссембли и наличие на этом языке мощного веб-фреймворка. Т.е, например, есть тот же GWT. Предположим, что в гугле его очень любят, холят и лелеют и забрасывать не собираются (можно же помечтать). Сейчас приложения в GWT компилятся в ява-скрипт. Через годА наконец-то доведут до ума веб-ассембли (дадут ему все те возможности, которые сейчас имеет ява-скрипт, тот же DOM). Программисты гугла поднапрягутся - и о чудо - в GWT можно будет все существующие старенькие (но очень нужные) приложения перекомпилировать на новую технологию, по минимуму изменяя проекты.
Но ведь Kotlin и Scala итак уже умеют в JS собираться
Битва за то, чтобы пропихнуть копирастическое разное в мир web. Хрен там разберешься, что они втихаря в твой браузер грузят.
Сюрприз - давно пропихнули, минифицированный жабаскрипт читать - всё равно, что тот же байткод
Ну извращение же, нет? Все эти попытки сделать из Web-а полноценный runtime. Изначально же не для этого создавался Web. Какое-то ощущение костылей от всех этих фреймворков... Мой мозг отказывается понимать этот мир. Действительно, столько языков программирования, концепций, компиляторов, богатая история платформ и ПО, сложнейшие вычисления, и что в итоге? Всё есть JavaScript? Ужас.
Деньги.
> Деньги.Уточним: ты на своём оборудовании крутишь неведомое что-то, а деньги за это получает кто-то ещё.
С компиляцией в WebAssembley все не так печально. C, C++, Rust и пр код. И это не JS, а напрямую с VM
Джава апплеты возвращаются?
Новость-то в чём? Это ж древняя хрень уже
Я так понимаю, это единственный способ гонять жабовские программы в каком-то ещё интерпретаторе, ктоме того, в котором находят десяток критических уязвимостей каждый квартал?
В браузерах их находят чаще
> в линейное представление с эмуляцией нескольких логических потоков в одном физическом потоке.ой, чёт у нас веб, кажется, недостаточно тормозит
Еще не ясно нужен ли angular (2?), но уже есть "такое же как angular, только лучше".
Напомните а почему все одно время носились с GWT как с писаной торбой, а потом как-то резко, раз - и все пр него забыли?Не скиснет ли TeaVM точно так же как GWT? Может, сама по себе идея трансляции Java в JavaScript - мертворождённая? Хотя выглядит неплохо.
> Напомните а почему все одно время носились с GWT как с писаной
> торбой, а потом как-то резко, раз - и все пр него
> забыли?так происходит с 95% проектов G. Это нормально.
> Не скиснет ли TeaVM точно так же как GWT?
Предположу первый этап оно пропустит и сразу перейдёт ко второму.
Задача трансляции JVM -> JavaScript не решаемая, потому что эти платформы предоставляют разную функциональность и разные гарантии. Только ограниченный набор программ подвержен трансляции. А это значит, что вы изначально должны учитывать при программирования на Java (или Scala), что ваш код будет исполняться javascript платформой. Во-первых, теряются абстракции языка. Во-вторых, если вы собираетесь программировать под javascript платформу, зачем вам Java, не проще ли сразу писать на javascript.Потому все эти проекты и сдохнут. Ну разве что кто-то безумный перепишет весь рантайм джавы на джаваскрипт и пройдёт JKT, в чём я очень сомневаюсь. А если и получится стандартизировать код, что делать с тормозами от проксирования одной виртуальной машины через другую?
> Напомните а почему все одно время носились с GWT как с писаной
> торбой, а потом как-то резко, раз - и все пр него
> забыли?Там оказалось, что на чистом жс писать таки быстрее чем разбираться как и почему ГВТ скомпилировал неправильно твой код.
Имхо от того, что они притянули в Жаву DOM манипулирование. Если бы на жаве была только pure логика, то норм было бы.
Плюс в Гугле внутри был конкурирующий проект, google closure compiler (не путать с clojure), на котором имхо было проще писать, чем на ГВТ.
> компилировать Java-байткод в JavaScript и WebAssembly для последующего выполнения в браузереС тех пор, как в браузер стало возможно добавить что-либо кроме текста, нам постоянно норовят встроить чуть ли не в мозг что-то «интерактивное». Цель-то их понятна — рекламный телевизор. Но называть это прогрессом…
браузер уже давно не является обычной читалкой:)
Интересно, а что с GCJ?
Вроде же он существовал.
gcj закрыт в 2016 году.
http://tromey.com/blog/?p=911
> gcj закрыт в 2016 году.Даже если он закрыт это ещё не значит, что его нельзя скомпилировать сегодня.
Последний релиз 4 июля 2017 с версией 6.4
>Даже если он закрыт это ещё не значит, что его нельзя скомпилировать сегодня.А завтра? А через год? Тянуть что то что уже на нём ... понятно. Новое плодить :-/
>Последний релиз 4 июля 2017 с версией 6.4Вот Ыманно. Ты можешь предсказать (а лучше - гарантировать) что с ним будет 4 Июля 201_8_ ?! В трэш, тчк.
> А завтра? А через год? Тянуть что то что уже на нём ... понятно. Новое плодить :-/Пока доступны старые версии, собирать можно использовать тоже, улучшать и плодить новое на основе старого. У вас свободы не отнимали на старые версии.
> Вот Ыманно. Ты можешь предсказать (а лучше - гарантировать) что с ним будет 4 Июля 201_8_ ?! В трэш, тчк.
Опять же говорю что его не выбросят, а если приготовят к выбросу то хоть кто-то запросит заранее снэпшот в вэб-архив.
Что попадает в интернет то там и остается.
Джавовский стиль программирования всяко лучше, особенно для крупных проектов. Да и байт-код по идее должен исполняться быстрее, чем код, который еще надо оттранслировать. Но ждать, что производители все поголовно вставят себе java-машины для целей js не приходится. Слишком уж сильна инерция.