Comments 53
> Команда GWT фактически отказалась от поддержки DevMode — единственной возможности отлаживать код.
Почему? Я вот только-только начал регулярно писать на GWT и DevMode спасает :)
Они как раз недавно обновили плагин для Chrome, для других браузеров, правда, забросили.
Почему? Я вот только-только начал регулярно писать на GWT и DevMode спасает :)
Они как раз недавно обновили плагин для Chrome, для других браузеров, правда, забросили.
Откуда инфа об обновлении плагина для Chrome? Я не слышал. А вот то, что плагин для Chrome уже несколько месяцев как перестал работать — это вполне себе объективная реальность. Вот приведу пару ссылок:
pgt.de/2013/12/13/beyond-devmode-the-future-of-gwt-debugging/ lustforge.com/2014/06/12/restoring-the-chrome-gwt-devmode-plugin/
Не помню точно где, но слышал информацию, что к 2.7 они вообще собираются убрать DevMode.
А вообще, у DevMode есть ещё недостатки. Например, он долговато стартует. Ещё беда в том, что программа фактически работает в настоящей JVM, и иногда в ней нормально работает то, что не очень хорошо работает в GWT. Например, каково было однажды моё удивление, когда программа, нормально работавшая в DevMode, внезапно заглючила на проде. А оказалось вот: code.google.com/p/google-web-toolkit/issues/detail?id=1983
pgt.de/2013/12/13/beyond-devmode-the-future-of-gwt-debugging/ lustforge.com/2014/06/12/restoring-the-chrome-gwt-devmode-plugin/
Не помню точно где, но слышал информацию, что к 2.7 они вообще собираются убрать DevMode.
А вообще, у DevMode есть ещё недостатки. Например, он долговато стартует. Ещё беда в том, что программа фактически работает в настоящей JVM, и иногда в ней нормально работает то, что не очень хорошо работает в GWT. Например, каково было однажды моё удивление, когда программа, нормально работавшая в DevMode, внезапно заглючила на проде. А оказалось вот: code.google.com/p/google-web-toolkit/issues/detail?id=1983
DevMode использовал NPAPI, от которого Chrome отказался. Можете почитать подробнее на английском.
Выше привели ссылки, я не заметил.
Выше привели ссылки, я не заметил.
а вместо GWT не пробовали посмотреть на ZK?
deleted
Ну как бы их банально нельзя сравнивать, потому что ZK работает целиком на сервере, по принципу Vaadin. Соответственно, это трафик по любому поводу + хранение состояния формы на сервере, со всеми последствиями. А что такое GWT? По сути, разработчики слепили в одном продукте две разные технологии. С одной стороны, это компилятор из Java в JS, с другой — целый фреймворк для написания браузерных приложений. Можно вообще не использовать этот фреймворк, и всё равно писать на GWT. Например, уже приведённый мной пример с libGDX.
Если сравнивать ZK с библиотекой виджетов от GWT, то да, первый побеждает. В этом аспекте GWT действительно ужасен. Однако, ZK не умеет в принципе делать того, что можно с GWT. Например, написать игру на Java и распространять её на как на Androd и iOS (через RoboVM), так и через браузер.
Если сравнивать ZK с библиотекой виджетов от GWT, то да, первый побеждает. В этом аспекте GWT действительно ужасен. Однако, ZK не умеет в принципе делать того, что можно с GWT. Например, написать игру на Java и распространять её на как на Androd и iOS (через RoboVM), так и через браузер.
Интересно, а что если байткод Java транслировать в asm.js? Мне кажется, получилась бы очень быстрая VM. :)
Нет, очень быстрая VM не получилась бы, хотя бы потому, что разработчики google chrome не согласны с идеей asm.js и не собираются включать его поддержку в свой браузер. Поддержка ams.js к тому же тянет за собой очень много сложностей. Скажем, придётся полностью написать GC, поддержку исключений, придумать, как сделать взаимодействие с нативным JS из asm.js. А так, скорость и сейчас очень радует.
asm.js уже очень давно поддерживается в chrome, более того поддержку обещали также в ИЕ12.
Ну что же, наверное, в этом я был не прав. В любом случае, у меня вряд ли найдутся силы поддерживать ещё и asm.js, куда будет включаться разработка своего GC, поддержка исключений и поддержка со стороны эмуляции библиотеки JDK. Если у кого найдутся силы и желания — форкайте :-)
А можно узнать, откуда дровишки? Если вы про этот пост: Chrome 28 Beta: A more immersive web, everywhere то там лишь сказано, что asm.js бенчмарки стали быстрее в новой версии хрома относительно предыдущей за счет оптимизаций арифметики в Hydrogen IR (маркетологи такие маркетологи). Что касается полноценной поддержки asm.js с директивой 'use asm' и переключением на оптимизирующий компилятор сразу минуя стадию сборки type feedback как это делает OdinMonkey, то эта тема находится в полумертвом состоянии и пока никто браться за ее реализацию в команде v8 не планирует: Implement «use asm». Относительно firefox на данный момент хром медленнее примерно в 3 раза на asm.js коде, т.к. использует general purpose JIT для него.
Я узнал от opennet.
+ После проверил на демки от Epic Games — Epic Citadel, которая до внедрения этой поддержки у меня просто висела медным тазом, а стало летать.
Но в любом случае, это лучше чем ничего.
+ После проверил на демки от Epic Games — Epic Citadel, которая до внедрения этой поддержки у меня просто висела медным тазом, а стало летать.
Но в любом случае, это лучше чем ничего.
Разработчики asm.js планируют добавить поддержку GC и структур(typed object) — asmjs.org/faq.html
Но видимо это не скоро :( — необходимая фича(typed_objects) перехала из ES6 в ES7.
Но видимо это не скоро :( — необходимая фича(typed_objects) перехала из ES6 в ES7.
Не получится еще и потому что asm.js заточен сугубо под число дробилки, быстрые строки/объекты/коллсайты не завезли. А в общем и целом мономорфный JS (который и получится в случае трансляции с типизированного языка) очень-очень хорошо оптимизируется современными JIT'ами.
Кстати, мне пришла в голову мысль: если уж сам рантайм переписывать долго и муторно (да ещё и есть риск получить огромный JS), то почему бы не попытаться эвристически определять, какие методы можно транслировать в asm.js и выборочно оптимизировать действительно числодробительные методы. Скажем, в jbox2d их предостаточно. Я всё равно собирался делать инлайнинг и escape analysis, а они должны сильно поспособствовать образованию подобного рода asm.js-совместимых числодробилок.
Да, это вариант. С инлайнингом самому лучше не играться и отдать это на откуп JS-движку, т.к. есть вероятность увеличить полиморфность функции и как следствие увеличить количество bailout'ов, а в итоге v8 может вообще забить на оптимизацию такой функции , что выйдет только боком.
Без инлайнинга скорее всего будет мало смысла от эвристики с asm.js. Если с ним аккуратно поиграться, то можно и добиться прироста производительности. Я хотел использовать инлайнинг лишь для того, чтобы открыть простор для дальнейших оптимизаций, того же escape analysis или constant propagation вместе dead code elimination. Можно сделать откат инлайнинга, если после него не удалось сильно оптимизировать метод.
Да, можно попробовать такой механизм, главное что бы накладные расходы на рантайм-профайлинг и откат к незаинлайненой функции не были велики. А self-hosting планируете (с компиляцией в node-тулзу)? Был бы отличный полигон для выявления проблем.
Откат к незаинлайненной функции я не могу делать в рантайме, т.к. TeaVM — это AOT. Имеется в виду, во время компиляции я мог бы делать инлайнинг и смотреть, получилось ли после него сделать оптимизации. Если не получилось, откатывать инлайнинг и дальше уже отправлять исхоный SSA в генератор JS.
А что за self-хостинг?
А что за self-хостинг?
Self-hosting является де-факто показателем зрелости компилятора. Это когда компилятор компилирует сам себя. Вики ссылка на всякий: Self-hosting.
К сожалению, достаточно сложно сделать самокомпиляцию TeaVM, потому что помимо собственно компиляции есть средства расширения компилятора, аналогичные generators в GWT. Допустим, я скомпилирую TeaVM и получу TeaVM.js. TeaVM.js могут подсунуть файл foo-library.jar, в котором предоставлено расширение. Как TeaVM.js загрузит это расширение? Ответ — оперативненько скомпилит его. Но с этим связан ряд сложностей, т.к. TeaVM изначально AOT, и пока я не вижу сильной необходимости делать JIT, т.к. это хоть и выглядит как крутая и интересная задача, но на практике никто не будет использовать такую возможность.
Это учебный проект? Сама по себе задача интересная, но вот с практической точки зрения ни один такой вариант не прокатывал.
В своё время хотел использовать для этого ceylon. Он очень похож на джаву, и так же транслируется в js (вроде). Но времени им заняться небыло…
Ещё раз повторяю: трансляция из языка в язык — дело не слишком благодарное. Например, я показал свой бенчмарк разработчикам Kotlin, которые так же умеют генерировать JS, и они не смогли сделать такой же для сравнения? Почему? Потому что я использую JBox2D, написанную на Java, а не на Kotlin. А вот когда у меня всё-таки дойдут руки реализовать рантайм Kotlin'а, можно будет запускать в браузере приложения на Kotlin, которые используют библиотеки, написанные на Java.
У меня вопрос к автору: чем вам так не понравился superdevmode? По-моему с ним довольно просто дебажить, учитывая возможности хрома и фаирфокса.
Потому что
А FF так вообще очень неудобно сделали отображение стектрейса. Но для любителей дебажить в браузере TeaVM умеет генерировать обычные source maps.
- Приходится переключаться между браузером и IDE при отладке, мне удобнее отлаживать код там же, где я его пишу.
- В IDE есть продвинутые средства навигации по коду, которых нет в браузере. Например, как в Chrome найти нужный класс по части имени? А как найти все реализации метода интерфейса или абстрактного класса? Это уж не говоря про то, что нельзя по Ctrl+Click перейти к нужному мне классу, имя которого я увидел в коде.
А FF так вообще очень неудобно сделали отображение стектрейса. Но для любителей дебажить в браузере TeaVM умеет генерировать обычные source maps.
А зачем переключаться? Ведь по сути дела у вас есть исходный код в дебагере браузера.
В дебаге браузера код, который отдаёт код-сервер GWT. Изменения в нём, очевидно, никак не могут быть сохранены на диск. Допустим, нашёл я причину баги и хочу поправить. Обратно в IDE? А потом обратно в браузер дебажить дальше?
Далее, для поиска баги мне нужно смотреть различные участки кода. В браузере мне приходится искать нужные файлы в дереве исходников.
Далее, для поиска баги мне нужно смотреть различные участки кода. В браузере мне приходится искать нужные файлы в дереве исходников.
Нет поддержки других языков. Для некоторых языков, есть собственный аналоги GWT, например, Scala.js и нативная поддержка в Kotlin. Однако, у них есть другой недостаток: невозможность взаимодействия с существующими Java-библиотеками.
А при использовании серьезных Java библиотек не возникнет ли проблем с быстродействием?
Хороший проект — нужный! Желаю вам скорейшего роста опенсорс комьюнити.
А нет ли online где посмотреть — как у kotlin или go
А так, всегда восхищался людям которые пишут такие большие проекты. Это вам не формочки в вебе выводить.
Можно пример как TeaVM переведёт в javascript какой нибуть pojo — например такой, первое что в голову пришло — pastebin.com/TL9Qi4xZ
Вы крутой) Удачи с проектом.
А так, всегда восхищался людям которые пишут такие большие проекты. Это вам не формочки в вебе выводить.
Можно пример как TeaVM переведёт в javascript какой нибуть pojo — например такой, первое что в голову пришло — pastebin.com/TL9Qi4xZ
Вы крутой) Удачи с проектом.
Спасибо за похвалу :-)
Да, это хорошая идея — сделать онлайн просмотр. К сожалению, это за час не сделается, но я буду работать в данном направлении и когда-нибудь сделаю подобного рода страничку. В перспективе может я научусь запускать через TeaVM сам TeaVM и javac, тогда такую демку можно будет сделать даже без компиляции на сервере. Но это дело совсем уж далёкого будущего.
Pojo в JavaScript переводить нет особого смысла, потому что TeaVM нацелен на перевод кода, который что-то делает. Вот если с этим pojo что-то сделать в методе main, тогда можно получить JavaScript. Но нет, TeaVM не переводит в режиме один класс = один JS. TeaVM скомпилирует сам метод main, те методы pojo, которые были вызваны из main, а так же некоторый минимальный набор методов для поддержания работоспособности рантайма.
А пока остаётся довольствоваться скомпиленными примерами онлайн и архетипом, с помощью которого можно за 5 секунд создать новый проект и поиграться. Благо, для сборки созданного проекта тоже нужно всего лишь запустить mvn clean package.
Да, это хорошая идея — сделать онлайн просмотр. К сожалению, это за час не сделается, но я буду работать в данном направлении и когда-нибудь сделаю подобного рода страничку. В перспективе может я научусь запускать через TeaVM сам TeaVM и javac, тогда такую демку можно будет сделать даже без компиляции на сервере. Но это дело совсем уж далёкого будущего.
Pojo в JavaScript переводить нет особого смысла, потому что TeaVM нацелен на перевод кода, который что-то делает. Вот если с этим pojo что-то сделать в методе main, тогда можно получить JavaScript. Но нет, TeaVM не переводит в режиме один класс = один JS. TeaVM скомпилирует сам метод main, те методы pojo, которые были вызваны из main, а так же некоторый минимальный набор методов для поддержания работоспособности рантайма.
А пока остаётся довольствоваться скомпиленными примерами онлайн и архетипом, с помощью которого можно за 5 секунд создать новый проект и поиграться. Благо, для сборки созданного проекта тоже нужно всего лишь запустить mvn clean package.
Спасибо за ответ, нет под рукой idea чтобы попробовать самому, но буду следить за вашим проектом — по мне выходит хорошая штука.
А вообще как вы докатились до жизни такой, где брали инфу про jvm байт код и прочее в книжках этого к сожалению не пишут.
Я давно пишу на java и сейчас решил подтянуть знания по java annotation preprocessor инфы очень мало даже на Eng где собственно и ищу.
Может есть какая то книга(и) о которых я не знаю, где поднимаются темы наподобие этим. Хотя я вроде слежу за новинками — и в дробпоксе лежит книг 30 по java. Но ни в одной не затрагиваются такие вещи.
А вообще как вы докатились до жизни такой, где брали инфу про jvm байт код и прочее в книжках этого к сожалению не пишут.
Я давно пишу на java и сейчас решил подтянуть знания по java annotation preprocessor инфы очень мало даже на Eng где собственно и ищу.
Может есть какая то книга(и) о которых я не знаю, где поднимаются темы наподобие этим. Хотя я вроде слежу за новинками — и в дробпоксе лежит книг 30 по java. Но ни в одной не затрагиваются такие вещи.
Не обязательно использовать для этого IDEA. Подойдут Eclipse и Netbeans, да и в блокнотике можно поиграться.
Про байткод можно прочитать в VM Spec. Правда, там очень много всего о бинарном формате классов, о тонкостях работы самой JVM и т.д. Полезнее будет почитать шестую главу. Но это только после чтения прекрасного мануала по библиотеке ASM. Докатился я до этого давно, из-за того, что порой приходится на уровне байткода патчить поделия индусокодеров, в случае если нет исходников к jar-файлу. Впрочем, иногда с помощью ASM можно и просто делать крутое метапрограммирование.
Я ещё со школы интересовался построением компиляторов, когда пытался ломать байсик ZX Spectrum. Уже позже, в институте, почитал книгу дракона. Она хоть и содержит устаревшие сведения, всё же полезна для понимания того, как работают компиляторы. В разрезе TeaVM полезны последние главы.
Как узнал про SSA, точно не помню, но узнал при работе над TeaVM. По SSA в сети лежит огромное количество информации, начать можно с классики. Осторожно, в статье приведён неправильный алгоритм устранения φ-функций! Анализ графа вызовов я делал согласно статье Practical Virtual Method Call Resolution for Java, а алгоритм декомпиляции навеян Decompiling Java Bytecode: Problems, Traps and Pitfalls. Эти статьи я нашёл, когда думал, как сделать TeaVM и специально искал в сети полезную информацию по теме.
По annotation processors ничего сказать не могу, не использовал. Вообще, считаю кодогенерацию не лучшей идеей (кстати, именно поэтому меня не устраивает DukeScript). Единственное место, где она пока оказалась действительно уместной — это в QueryDSL.
Про байткод можно прочитать в VM Spec. Правда, там очень много всего о бинарном формате классов, о тонкостях работы самой JVM и т.д. Полезнее будет почитать шестую главу. Но это только после чтения прекрасного мануала по библиотеке ASM. Докатился я до этого давно, из-за того, что порой приходится на уровне байткода патчить поделия индусокодеров, в случае если нет исходников к jar-файлу. Впрочем, иногда с помощью ASM можно и просто делать крутое метапрограммирование.
Я ещё со школы интересовался построением компиляторов, когда пытался ломать байсик ZX Spectrum. Уже позже, в институте, почитал книгу дракона. Она хоть и содержит устаревшие сведения, всё же полезна для понимания того, как работают компиляторы. В разрезе TeaVM полезны последние главы.
Как узнал про SSA, точно не помню, но узнал при работе над TeaVM. По SSA в сети лежит огромное количество информации, начать можно с классики. Осторожно, в статье приведён неправильный алгоритм устранения φ-функций! Анализ графа вызовов я делал согласно статье Practical Virtual Method Call Resolution for Java, а алгоритм декомпиляции навеян Decompiling Java Bytecode: Problems, Traps and Pitfalls. Эти статьи я нашёл, когда думал, как сделать TeaVM и специально искал в сети полезную информацию по теме.
По annotation processors ничего сказать не могу, не использовал. Вообще, считаю кодогенерацию не лучшей идеей (кстати, именно поэтому меня не устраивает DukeScript). Единственное место, где она пока оказалась действительно уместной — это в QueryDSL.
Идея отличная! А Вы один работаете? У Вас сейчас только плагин для Eclipse. А в сторону IDEA не смотрели? Как среда для Java разработки она помощнее Eclipse будет. (не холивара ради — сам активно Eclipse пользовался 4 года, даже плагин писал). Может и для неё плагин написать? А то что она платная, так для Ваших целей, я думаю, выделят бесплатную лицензию — у них, насколько я знаю, есть поддержка open source проектов.
Ещё не понял на счёт поддержки source map в Вашей системе — как в итоге происходит debug? В IDEA есть поддержка source map и dubug в IDE (реализуется с помощью плагина к браузеру, пробовал в Chrome). Пока сырая, но к выходу новой версии (14-й), обещают реализовать.
И как у Вас реализована поддержка Reflection? Ограничение GWT (иногда существенное) — практически полное отсутствие Reflection. Но можно, к примеру, перебрать аннотации к объекту или методу. В статье, Вы указали, что Reflection нет. Т.е. его нет совсем или какие-то возможности присутствуют?
Ещё не понял на счёт поддержки source map в Вашей системе — как в итоге происходит debug? В IDEA есть поддержка source map и dubug в IDE (реализуется с помощью плагина к браузеру, пробовал в Chrome). Пока сырая, но к выходу новой версии (14-й), обещают реализовать.
И как у Вас реализована поддержка Reflection? Ограничение GWT (иногда существенное) — практически полное отсутствие Reflection. Но можно, к примеру, перебрать аннотации к объекту или методу. В статье, Вы указали, что Reflection нет. Т.е. его нет совсем или какие-то возможности присутствуют?
В сторону IDEA смотрел, но т.к. лично я работаю в Eclipse (и писал плагин прежде всего для того, чтобы мне самому было удобнее), и т.к. по интересующим меня темам нашёл больше документации именно для Eclipse, то и плагин написал для Eclipse. В будущих версиях сделаю плагин для IDEA.
Дебаг происходит так. Плагин соединяется с Google Chrome (пока есть поддержка только для него) по remote debugging protocol. Remote debugging protocol общается в терминах JS — для брейкпоинтов принимает номера строк в скрипте, обратно отдаёт стектрейс и значения переменных, как они появляются в скрипте. Плагин умеет делать маппинг. Для этого ему нужна информация о том, какая строка в Java соответствует строке в JavaScript, аналогично с именами переменных, классов, полей и методов. Такой информацией обладает компилятор TeaVM, он её записывает в специальный файлик. Плагин читает этот файлик и знает, как маппить. Этот файлик — это не source maps, потому что в source maps сильно ограничены возможности.
Далее, в Eclipse есть специальный API, который позволяет делать свои дебаггеры. Он посылает ему команды и ожидает от него различные события, такие как resume, suspend, terminate. Я реализую этот API и в нём показываю то, что получается после маппинга.
Reflection почти не поддерживается. В перспективе можно сделать поддержку метаданных: чтение информации о методах и полях классов, аннотаций. Но вот вызов метод через reflection или реализовать Proxy не получится. Вместо этого в GWT предлагается использовать генераторы. В TeaVM есть аналогичный, который я пока не задокументировал.
Дебаг происходит так. Плагин соединяется с Google Chrome (пока есть поддержка только для него) по remote debugging protocol. Remote debugging protocol общается в терминах JS — для брейкпоинтов принимает номера строк в скрипте, обратно отдаёт стектрейс и значения переменных, как они появляются в скрипте. Плагин умеет делать маппинг. Для этого ему нужна информация о том, какая строка в Java соответствует строке в JavaScript, аналогично с именами переменных, классов, полей и методов. Такой информацией обладает компилятор TeaVM, он её записывает в специальный файлик. Плагин читает этот файлик и знает, как маппить. Этот файлик — это не source maps, потому что в source maps сильно ограничены возможности.
Далее, в Eclipse есть специальный API, который позволяет делать свои дебаггеры. Он посылает ему команды и ожидает от него различные события, такие как resume, suspend, terminate. Я реализую этот API и в нём показываю то, что получается после маппинга.
Reflection почти не поддерживается. В перспективе можно сделать поддержку метаданных: чтение информации о методах и полях классов, аннотаций. Но вот вызов метод через reflection или реализовать Proxy не получится. Вместо этого в GWT предлагается использовать генераторы. В TeaVM есть аналогичный, который я пока не задокументировал.
Оч. интересный проект. Сам давно пишу на GWT, писал даже к нему библиотеку для сериализации: code.google.com/p/gwt-streamer/ Не в восторге от платформы.
Интересует несколько вещей:
1. За счет чего все-таки достигается производительность? Разработчики GWT божились, что из .class нельзя получить эффективный JS, что и доказывают проекты вроде Eclipse Java2Script?
2. Насколько я понял, проект должен включать в себя какой-нибудь API для работы с платформой браузера: DOM, Canvas, etc...?
3. Есть какие-нибудь средства для включения нативного JS-кода, как например JSNI?
4. Можно ли расширять или дополнять возможности поддерживаемого API Java не суясь в TeaVM? Что-то вроде GWT super-package?
5. Поскольку в GWT отсутствует рефлексия, все объявления статические. Это напрямую дает легкий способ отсекать неиспользуемый код и обфусцировать его. Как обстоят дела в TeaVM? Таскается весь код или библиотека целиком?
Интересует несколько вещей:
1. За счет чего все-таки достигается производительность? Разработчики GWT божились, что из .class нельзя получить эффективный JS, что и доказывают проекты вроде Eclipse Java2Script?
2. Насколько я понял, проект должен включать в себя какой-нибудь API для работы с платформой браузера: DOM, Canvas, etc...?
3. Есть какие-нибудь средства для включения нативного JS-кода, как например JSNI?
4. Можно ли расширять или дополнять возможности поддерживаемого API Java не суясь в TeaVM? Что-то вроде GWT super-package?
5. Поскольку в GWT отсутствует рефлексия, все объявления статические. Это напрямую дает легкий способ отсекать неиспользуемый код и обфусцировать его. Как обстоят дела в TeaVM? Таскается весь код или библиотека целиком?
1. Я даже не знаю, как сказать. За счёт просто грамотного подхода. Почему разработчики GWT не осилили, я даже не знаю. Вот базовый алгоритм декомпиляции: github.com/konsoletyper/teavm/wiki/Decompilation Правда, до него байткод JVM преобразуется в SSA, этот SSA ещё немного оптимизируется и т.п.
2. Да, есть тонкие обёртки вокруг некоторых браузерных объектов. Но это именно что тонкие обёртки, а не библиотека виджетов как в GWT.
3. Есть возможность писать обёртки вокруг объектов JavaScript: github.com/konsoletyper/teavm/wiki/Interacting-with-JavaScript
4. Можно, но только если это новые классы. Добавить метод к классу не получится.
5. Да, то же самое в TeaVM. Как я и писал, я пожертвовал рефлексией ради возможность отсекать ненужный код. В целом TeaVM генерит немного больше JavaScript, чем GWT, но, как мне кажется, это из-за лишних скобок (пока не дошли руки научить TeaVM приоритету и ассоциативности), а так же из-за явных приведений чисел к целым с помощью операции |0.
2. Да, есть тонкие обёртки вокруг некоторых браузерных объектов. Но это именно что тонкие обёртки, а не библиотека виджетов как в GWT.
3. Есть возможность писать обёртки вокруг объектов JavaScript: github.com/konsoletyper/teavm/wiki/Interacting-with-JavaScript
4. Можно, но только если это новые классы. Добавить метод к классу не получится.
5. Да, то же самое в TeaVM. Как я и писал, я пожертвовал рефлексией ради возможность отсекать ненужный код. В целом TeaVM генерит немного больше JavaScript, чем GWT, но, как мне кажется, это из-за лишних скобок (пока не дошли руки научить TeaVM приоритету и ассоциативности), а так же из-за явных приведений чисел к целым с помощью операции |0.
Круто! А сериализация объектов как сделана, если нет информации о полях? В GWT нужно было писать свой генератор, который вызывается на этапе компиляции и делает сериализатор для класса.
Обертки можно генерировать автоматически из W3C IDL. По-моему так TypeScript по-началу делал.
Обертки можно генерировать автоматически из W3C IDL. По-моему так TypeScript по-началу делал.
Сериализации нет, т.к. я позиционирую TeaVM исключительно как компилятор. Её нужно будет делать в виде отдельного проекта. В TeaVM информация о полях недоступна во время выполнения, но доступна во время компиляции, а так же есть различные механизмы встраивания в процесс компиляции, аналогичные генераторам.
Обёртки из IDL я бы генерить не стал, ибо W3C IDL местами далеки от реальной жизни. Кроме того, всё равно придётся следить за соответствием этих обёрток возможностям JSO и вручную проставлять аннотации.
Обёртки из IDL я бы генерить не стал, ибо W3C IDL местами далеки от реальной жизни. Кроме того, всё равно придётся следить за соответствием этих обёрток возможностям JSO и вручную проставлять аннотации.
Мне нравится подход. Надеюсь, он даст идее трансляции Java в JavaScript второе дыхание, потому что я слышал много негативных отзывов от разных людей о GWT, и почти не слышал позитивных. Сам я написал всего один реальный проект c использованием GWT, и не могу сказать, что так уж всё плохо. Сейчас хочу попробовать TeaVM для написания игрового приложения. Кстати, как вы смотрите на идею создания backend для PlayN?
В GWT есть очень удобная возможность подменять класс на этапе генерации кода. Это требуется, когда трансляция какого-либо класса не может быть выполнена, но этот класс можно заменить native реализацией с проксированием вызовов. Такое возможно в TeaVM? Прежде всего интересует взаимодействие с графикой и звуком. Я знаю, что есть взаимодействие с JavaScript, но меня интересует именно подмена реализации, чтобы искодный код/байткод не нужно было модифицировать. Я почти ничего не знаю про JVM байткод, поэтому, возможно, вопрос глупый, и выделить отдельный класс из всего кода невозможно.
В GWT есть очень удобная возможность подменять класс на этапе генерации кода. Это требуется, когда трансляция какого-либо класса не может быть выполнена, но этот класс можно заменить native реализацией с проксированием вызовов. Такое возможно в TeaVM? Прежде всего интересует взаимодействие с графикой и звуком. Я знаю, что есть взаимодействие с JavaScript, но меня интересует именно подмена реализации, чтобы искодный код/байткод не нужно было модифицировать. Я почти ничего не знаю про JVM байткод, поэтому, возможно, вопрос глупый, и выделить отдельный класс из всего кода невозможно.
На идею создания бэкэнда для PlayN смотрю положительно. Сам делаю бэкэнд для libGDX, думаю, после этого для PlayN будет совсем просто сделать.
Сейчас нельзя подменять отдельные классы, можно подменять целый пакет (так сделана эмуляция классов JDK). Сделать доработку, чтобы можно было подменять отдельные классы, несложно.
Сейчас нельзя подменять отдельные классы, можно подменять целый пакет (так сделана эмуляция классов JDK). Сделать доработку, чтобы можно было подменять отдельные классы, несложно.
Неправильно вы назвали программу, т. к. уже есть icedtea-plugin (IcedTea) — плагин к браузеру для запуска Java-апплетов, во всяком случае есть пакет в Дебиане под названием icedtea-7-plugin
Sign up to leave a comment.
TeaVM — ещё один способ запускать Java в браузере