Ещё никому не удалось опоздать на свои похороны.
Валентин Домиль

На прошлой неделе команда из Google наконец-то выложила исходники фреймворка J2CL, о котором говорили с 2015 года. Идея трансляции Java в JavaScript далеко не нова, и все уже давно набили шишек с Google Web Toolkit, однако этот продукт сообщество ждало как ни один другой — о нем говорили и делали выступления, но никто его не видел.

    ‌‌‍‍
Прошло больше 3-х лет с первого анонса и, кажется, что продукт потерял рынок даже не родившись. Сегодня у нас есть Scala.js, Kotlin.js и JSweet, не говоря уже о том, что веб-разработка захвачена TypeScript и для Java не осталось места. За такое время многие, даже самые преданные джависты, утратили веру в “Java для Front-end” и обуздали тот или иной JavaScript фреймворк.

Поскольку релиз всё-таки случился, давайте посмотрим, что получилось, и кому это может пригодиться.

GWT – отличный фреймворк. Я — Java-разработчик, и мне доводилось работать с тонкими клиентами с использованием JSP, JSF и GWT. Про JSP говорить особо нечего, технология сейчас практически вымерла, а вот в JSF-е пришлось повариться пару лет на двух проектах, и впечатления, мягко говоря, не из лучших: мешанина JSTL, HTML, JavaScript и прочего доставляет несказанное “удовольствие”, доходящее до экстаза в моменты разбора непонятного поведения какой-нибудь сложной страницы. Да, в примерах все выглядит аккуратно и просто, но реальная жизнь не такая, и JSF-страницы проекта даже среднего размера и, вроде бы, с грамотным неторопливым подходом при проектировании, с использованием шаблонов, все равно начинает “попахивать”, особенно в части читабельности. В GWT все достаточно аккуратно, ведь пишем на родном языке Java, пусть и в урезанном варианте, но того что есть более чем достаточно.

Уважаемые читатели! Хочу поделиться с вами своим open-source проектом, над которым я работаю в своё свободное время уже достаточно давно, TeaVM. TeaVM представляет собой транслятор из байткода Java в JavaScript. Существует несколько попыток создать JVM на JavaScript, одна из самых удачных — Doppio. Однако, кроме академической, никакой ценности они не представляют, так как скорость интерпретации байт-кода оставляет желать лучшего. Более того, для интерпретации байткода необходимо как минимум загрузить этот байткод в браузер, а это вырождается в загрузку десятков мегабайт class-файлов.

В отличие от них, TeaVM не интерпретирует байткод, а генерирует JavaScript, который выполняет ровно то, что делал бы байткод, будь он запущен в реальной JVM. Проще говоря, TeaVM декомпилирует байткод Java, но не обратно в Java, а в JavaScript. Разумеется, всё это верно до определённых пределов. Во-первых, в JavaScript попросту отсутствуют некоторые вещи, привычные Java-разработчикам, такие как потоки, полноценная поддержка Юникода (например, поддержка классов символов, регулярные выражения), блокирующий ввод-вывод. Во-вторых, это обусловлено требованиями, которые я предъявлял к компилятору. Например, в TeaVM очень ограничена поддержка reflection. Это следствие одного из преимуществ TeaVM — сравнительно небольшой размер генерируемого файла. Нет, TeaVM не генерирует минимально возможный JavaScript, однако и не станет генерировать огромные многомегабайтные скрипты на каждый чих. Reflection делает невозможным какой-либо статический анализ, поэтому было принято решение от него отказаться.

Прежде чем я продолжу, я хочу для начала показать, на что способен TeaVM. Во-первых, он способен в реальном времени симулировать физику. Во-вторых, он ещё способен по этой физике рисовать красивые картинки в Canvas. Можно увидеть, что JavaScript-файлы сравнительно небольшие. Кстати, обсчёт физики я сам не реализовывал, я всего лишь взял имеющуюся библиотеку JBox2D.

Наше JEE приложение сделало скачок версии GWT с 1.7 сразу до 2.6.1. Когда-то были небольшие танцы с бубном для того, чтобы в среде разработки IntelliJ Idea настроить возможность отладки клиентской части. Отладка заключается в возможности ставить точки останова (breakpoint-ы) в Java-коде, но попадать в них из браузерного JavaScript-а, сгенерированного GWT из Java-кода. После обновления версии GWT старая конфигурация запуска отладки работать перестала, и мне пришлось познакомиться с GWT Super Dev Mode (SDM). После этого «знакомства» я понял, что выше упомянутые «танцы» были на самом деле предельно простой и понятной настройкой, по крайней мере, в сравнении с SDM. Надеюсь, кому-то эта статья очень поможет сэкономить пару-тройку дней блужданий по форумам и избавит от нескольких новых седых волос. В статье я расскажу про опыт запуска режима SDM в следующем окружении: IntelliJ Idea 14, JBoss EAP 6, GWT 2.6.1 с применением в проекте GWT RPC, браузер Chrome. Несмотря на то, что при релизе Idea 14 сообщили о доработках касательно отладки в GWT, думаю, что для версии 13 всё нижеописанное также применимо. Используемый сервер приложений также вряд ли как-то влияет на настройку SDM. Насчет версий GWT: для 2.6.0 применимо почти один-в-один, то же касается и 2.7.0 (сам не проверял, вычитал в Сети по ходу проведения исследований).

В IDEA 13-ой версии, в отличие от Eclipse, при запуске проекта GWT с помощью стандартного плагина (и, как в последствие выяснилось, и без него, а просто запуск GWT DevMode — приложение для запуска в режиме разработки и debug'а, а конкретно com.google.gwt.dev.DevMode из gwt-dev.jar — как Java Application) при изменении UI кода нужно обновлять браузер, что бы изменения сработали. В случае GWT это очень критично — так как при обновлении страницы происходит повторное подключение к Code Server (сервер с исходным кодом проекта, нужен, что бы можно производить debug Java кода), а это занимает от 10 секунд до нескольких минут. Здесь я расскажу о способе, как менять код практически без перезагрузки страницы.

Добрый день!

В этой статье я рассмотрю unit/integration тестирование в GWT с использованием UI компонентов GWT и GXT и MVP (с Passive View) архитектуры для разделения логики и внешнего вида приложения.
GWT и GXT здесь выделены не случайно — Google разработал несколько framework'ов, которые облегчают поддержку паттерна MVP (точнее, более общее — разделение логики и представления) в GWT. Это Activity and Place для разделения логики приложения на модули, GWT Editor для автоматического мапинга POJO объектов на widget, UiBinding для декларативного описания интерфейса.
Всё это поддерживается ещё и UI framework'ом GXT. Т.ч. по сути не будет большой разницы в использовании UI компонентов GWT или GXT.

В результате получим легко тестируемое приложение без поднятия тяжёлого framework'а GWT.

Всем привет, давно я не писал статьи о жизни проекта на хабре, решил исправиться и начну пожалуй с того над чем сейчас работаю а именно Consulo UI API.

Consulo — это форк IntelliJ IDEA Community Edition, который имеет поддержку .NET(C#), Java

Всякая перемена, даже перемена к лучшему,
всегда сопряжена с неудобствами

Ричард Хукер

Как вы возможно знаете, Vaadin — один из самых популярных web-фреймворков на Java:

• Java Web Frameworks Index: February 2017
• 10 Best Java Web Frameworks to Use in 2018

Совсем недавно вышел новый релиз этого фреймворка для разработки web UI — Vaadin 10. Про Vaadin 10 и Vaadin Flow пока довольно мало публикаций на русском, и этот пост призван восполнить этот пробел.


Создатели позиционируют Vaadin Flow как новый Java web-фреймворк для разработки современных web-приложений и web-сайтов (вот тут я им не совсем верю). Это часть Vaadin Platform, которая приходит на замену другому продукту — Vaadin Framework, она позволяет разрабатывать web-приложения (а если быть точным, то web UI) с применением стандарта Web Components на Java.

Тут у читателя в голове скорее всего всё уже смешалось, все эти Vaadin Bla Bla, фреймворк, платформа и прочее. Что происходит?

Мы используем Vaadin в составе своей платформы CUBA для UI back-office систем на протяжении 7 лет и за это время накопили большой опыт работы с ним, поэтому нас не может не волновать его судьба. Под катом вы найдёте мои спекуляции на тему Vaadin 10.

История развития построения веб-приложений на языке программирования Java с примерами их использования на временном промежутке от появления спецификации сервлетов до сегодняшнего дня.

В пятницу 12 числа прошло такое знаменательное событие, как Google Developers Day 2010 в Москве. Это предпоследнее событие в серии GDD, следующее будет в Праге 16 ноября, а предыдущие прошли в Токио, Сан-Паулу и Мюнхене. GDD — значимое событие для всех разработчиков и попасть туда хотели 4000 человек, именно столько заявок было подано. Прошло всего 1500 и я был одним из счастливчиков. О том, каким GDD 2010 был для меня, я и хочу рассказать.

Днепропетровская группа пользователей технологий Google приглашает всех на нашу первую встречу в 2011 году.

Дата: 14 января, пятница
Время: 18:30
Место: ул. Серова, 4.

Докладчики и темы:
— Алексей Устенко (Ciklum) — программирование Android приложений для различных разрешений экранов
— Антон Зимарёв (Ciklum) — Spring Roo Rocks! Ready-to-use web application out of the box (GWT, Spring, JPA)
— Андрей Ясинецкий (со-координатор KievGTUG Center, Epam) — Chrome и HTML5 и рассказ про московский GDD2010
— Антон Данильченко — GAE framework — простой путь к Google App Engine и Python

Участие в мероприятии свободное, но желательно предварительно заполнить регистрационную форму

Оффсайт

UPD: еще один докладчик — Антон Данильченко

Когда я писал топик об использовании шаблона Command для организации RPC-вызовов в GWT то упоминал об MVP-паттерне для построения архитектуры GWT-проектов. Сразу после выступления товарища Ray Rayan’а с докладом о проектировании сложных приложений на GWT трудящиеся по всему миру принялись реализовывать озвученные идеи в виде библиотек и фреймворков. Результатом этих трудов стали средства, позволяющие применять как некоторые моменты MVP-подхода (GWT-Presenter) так и его целиком (Mvp4G). Это все замечательно, но мне лично (уверен, что и остальным GWT-разработчикам) хотелось бы иметь стандартизированный (если можно так сказать) фреймворк/подход для организации GWT-приложений по MVP-схеме. И вот команда, которая отвечает в Google за GWT, наконец-то в версии 2.1 наряду с остальными вкусными плюшками предложила встроенный MVP-фреймворк.
В данной заметке я постараюсь осветить основные моменты встроенного GWT MVP-фреймворка. Как пример будет использовано небольшое приложение, построенное с применением этого подхода.
Данная заметка является вольным трактатом (GWT MVP Development) и на уникальность подхода никоим образом не претендует. Если кого-то заинтересовало такое немаленькое введение

Вышла обновленная версия фреймворка GWT (Google Web Toolit) с номером 2.3
Качать тут
А так же обновился Google Plugin for Eclipse (GPE)

Фреймворк позволяет создавать Web-приложение на Java с последующей компиляцией клиентской части в JavaScript.

Среди главных изменений в новой версии числятся:
Easy Discovery and Access to Google APIs
Import Projects from Project Hosting
One Login, Many Services
Local Storage APIs

См. видео по новым возможностям

Любите ли вы GWT так, как люблю его я? Недавно возникла задача, повесить Sonar на проект, где используется GWT. Проблема возникла в тот момент, когда врубается Clover. Подробности этой истории под катом.

JavaScript-библиотеки Ext JS и Ext GWT известны, помимо прочего, одним из лучших наборов визуальных компонентов — как по дизайну, так и по кроссбраузерности, да и по стабильности работы. Потому и руки сами тянутся к любому проекту на GWT добавить Ext и заменить скучные гугловые виджеты на симпатичные формы и окошки.

Однако интеграция Ext GWT и GWT до сих пор оставляла желать лучшего — по сути, вторая версия Ext GWT полностью вытесняет все средства компоновки интерфейса GWT, предлагая собственные API для всего, вплоть до обработки событий. Поэтому для третьей версии библиотеки, доступной сейчас в виде developer preview, разработчики из Sencha активно переписывают скриптовое наследие Ext JS, используя паттерны и идиомы, принятые в GWT. Главное ожидаемое преимущество — более корректная интеграция с GWT и, как следствие, более компактный и оптимизированный код интерфейса: генерация и обфускация JavaScript и CSS происходит на этапе GWT-компиляции, с использованием механизма deferred binding, за счёт чего исключаются фрагменты кода, не использующиеся в текущем проекте.

Добрый день.
Думаю, многие из вас знают о выходе Java 8, и о том, какие нововведения она несет. К сожалению, последняя версия GWT(2.6.0) на данный момент до сих пор не поддерживает лямбды и default-методы в интерфейсах. Поскольку фреймворк GWT довольно востребован, многим приходится часто сталкиваться с разработкой именно на нем, мне не терпелось попробовать писать на GWT с использованием вновь добавленных в язык фич.

Фреймворки Google Web Toolkit и Vaadin достаточно хорошо себя показывают, когда вы просто используете их. Если вдруг вам понадобилось расширить их функциональность, то вам придётся серьёзно попотеть. В этой статье я хочу рассказать, как написать простой компонент на GWT, добавить к нему серверную часть Vaadin и использовать в своём приложении. Я не буду создавать некий совсем пустой GWT/Vaadin проект и с самого начала настраивать компиляцию GWT, вместо этого возьму приложение на базе CUBA.Platform, в котором и реализую сам компонент, а затем попробую в деле. Так будет видно, насколько хорошо всё впишется в настоящее приложение. Отдельное внимание я бы хотел уделить отладке компонента, поскольку она нетривиальна и всегда вызывает трудности у разработчиков.

Хочу предупредить, что не всё описанное в статье относится к GWT и Vaadin, часть шагов и приёмов применимы только в контексте использования CUBA.Platform, за счёт этого сильно упрощена настройка окружения и некоторые рутинные действия.

Привет, Хабр!

JUG.EKB — Java User Group Екатеринбурга, на встречах JUG.EKB мы обсуждаем различные технологий из мира Java, делимся опытом и пьем кофе во имя Java!
Мы регулярно проводим встречи JUG.EKB с лекциями Java экспертов на самые интересные темы.
Наш сайт jugekb.ru, сообщество в ВК — vk.com/jugekb.

Приглашаем всех java разработчиков на четвертую встречу JUG.EKB.

Довольно давно я опубликовал на Хабре статью, где рассказал про свой проект, TeaVM. С тех пор много всего произошло с ним, в том числе одна важная вещь, про которую речь пойдёт ниже и ради которой я решил снова написать на Хабр. Но для начала кратко напомню, про что проект.

Итак, TeaVM — это компилятор байт-кода Java в JavaScript. Идея создания TeaVM пришла мне, пока я работал full-stack Java разработчиком и использовал для написания фронтэнда GWT. В те времена (а это где-то лет 5 назад) не были широко распространены инструменты вроде node.js, webpack, babel, TypeScript; Angular был в первой версии, а альтернатив вроде React и vue.js не было вообще. Тогда ещё на полном серьёзе люди тестировали сайты в IE7 (а некоторые, кому не повезло с заказчиками, даже IE6). В целом, экосистема JavaScript была гораздо менее зрелой, чем сейчас, и без боли писать на JavaScript было нельзя.

GWT мне нравился тем, что на фоне всего этого он казался адекватным решением, хотя и не лишённым своих недостатков. Основные проблемы перечислены под катом: