От переводчика: GraalVM — новая, интересная технология, но на Хабре по ней не так много статей, которые бы могли показать примеры возможностей Graal. Статья ниже — это не просто перечисление того, что GraalVM умеет, но ещё и небольшой мастер-класс, аналогичный тому, который Chris Seaton и Олег Шелаев проводили на Oracle CodeOne 2018. Вслед за автором, призываю — пробуйте делать примеры из статьи, это действительно интересно.

В GraalVM много всего разного, и, если вы слышали это название раньше, или даже видели доклады, то все равно есть много вещей, о которых вы наверняка ещё не знаете, но которые GraalVM может делать. В этой статье мы рассмотрим разнообразные возможности, которые предоставляет GraalVM и покажем, что с их помощью можно сделать.

1. Быстрое выполнение Java
2. Уменьшение времени старта и потребления памяти для Java
3. Комбинирование JavaScript, Java, Ruby и R
4. Исполнение программ, написанных на платформо-зависимых языках
5. Общие инструменты для всех языков программирования
6. Дополнение JVM приложений
7. Дополнение платформо-зависимых приложений
8. Код Java как платформо-зависимая библиотека
9. Поддержка нескольких языков программирования в базе данных
10. Создание языков программирования для GraalVM

От переводчика: LambdaMetafactory, пожалуй, один из самых недооценённых механизмов Java 8. Мы открыли его для себя совсем недавно, но уже по достоинству оценили его возможности. В версии 7.0 фреймворка CUBA улучшена производительность за счет отказа от рефлективных вызовов в пользу генерации лямбда выражений. Одно из применений этого механизма в нашем фреймворке — привязка обработчиков событий приложения по аннотациям, часто встречающаяся задача, аналог EventListener из Spring. Мы считаем, что знание принципов работы LambdaFactory может быть полезно во многих Java приложениях, и спешим поделиться с вами этим переводом.

В этой статье мы покажем несколько малоизвестных хитростей при работе с лямбда-выражениями в Java 8 и ограничения этих выражений. Целевая аудитория статьи — senior Java разработчики, исследователи и разработчики инструментария. Будет использоваться только публичный Java API без com.sun.* и других внутренних классов, поэтому код переносим между разными реализациями JVM.

В процессе разработки CUBA мы применяли все три основных инструмента сборки — начали с Ant, потом перешли на Maven на короткое время, а сейчас используем Gradle и, похоже, что в ближайшее время останемся с ним.

Не так давно вышел Gradle 5.0. В этой версии появилось большое количество новых возможностей, которые помогут разработчикам писать более сложные сценарии и собирать свои проекты ещё быстрее и безболезненнее.

1. Вступление

В этом туториале мы рассмотрим важный API, представленный в Java 7 и расширенный в новых версиях, java.lang.invoke.MethodHandles.

Мы узнаем, что такое method handles, как их создавать и использовать.

Скрипты — один из самых распространенных способов сделать приложение более гибким, с возможностью поправить что-то прямо на ходу. Конечно же, у этого подхода есть и недостатки, нужно всегда помнить про баланс между гибкостью и управляемостью. Но в этой статье мы не будем рассуждать “в общем” по поводу плюсов и минусов использования скриптов, мы рассмотрим практические способы реализации этого подхода, а также представим библиотеку, которая предоставляет удобную инфраструктуру для добавления скриптов в приложения, написанные на Spring Framework.

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

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

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

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

Как известно, HTTP 1.1 — это текстовой протокол передачи данных. HTTP сообщения закодированы, используя ISO-8859-1 (которую условно можно считать расширенной версией ASCII, содержащей умляуты, диакритику и другие символы, используемые в западноевропейских языках). При этом в теле сообщений можно использовать другую кодировку, которая должна быть обозначена в заголовке «Content-Type». Но что делать, если нам необходимо задать non-ASCII символы не в теле сообщения, а в самих заголовках? Наверное, самый распространенный кейс — это проставление имени файла в «Content-Disposition» заголовке. Это, казалось бы, довольно распространенная задача, но ее реализация не так очевидна.

TL;DR: Используйте кодировку, описанную в RFC 6266, для «Content-Disposition» и преобразуйте текст в латиницу (транслит) в остальных случаях.

От переводчика: мы активно работаем над переводом платформы на рельсы Java 11 и думаем над тем, как эффективно разрабатывать Java библиотеки (такие как YARG) с учётом особенностей Java 8 / 11 так, чтобы не пришлось делать отдельные ветки и релизы. Одно из возможных решений — multi-release JAR, но и тут не всё гладко.

Java 9 включает новую опцию Java-рантайма под названием multi-release JARs. Это, возможно, одно из самых противоречивых нововведений в платформе. TL;DR: мы считаем это кривым решением серьезной проблемы. В этом посте мы объясним, почему мы так думаем, а также расскажем, как вам собрать такой JAR, если вам сильно хочется.

Multi-release JARs, или MR JARs, — это новая функция платформы Java, появившаяся в JDK 9. Здесь мы подробно расскажем о значительных рисках, связанных с использованием этой технологии, и о том, как можно создавать multi-release JARs с помощью Gradle, если вы ещё хотите.

По сути, multi-release JAR — это Java-архив, включающий несколько вариантов одного класса для работы с разными версиями среды исполнения. Например, если вы работаете в JDK 8, среда Java будет использовать версию класса для JDK 8, а если в Java 9, используется версия для Java 9. Аналогично, если версия создана для будущего выпуска Java 10, рантайм использует эту версию вместо версии для Java 9 или версии по умолчанию (Java 8).

Под катом разбираемся в устройстве нового формата JAR и выясняем нужно ли это всё.

Этот текст посвящен различным подходам к валидации данных: на какие подводные камни может наткнуться проект и какими методами и технологиями стоит руководствоваться при валидации данных в Java-приложениях.

Я часто видел проекты, создатели которых вообще не утруждались выбором подхода к валидации данных. Команды работали над проектом под невероятным давлением в виде сроков и размытых требований, и в итоге у них просто не оставалось времени на точную, последовательную валидацию. Поэтому, код валидации у них разбросан повсюду: в сниппетах Javascript, контроллерах экранов, в бинах бизнес-логики, сущностях предметной области, триггерах и database constraints. В этом коде было полно операторов if-else, он выбрасывал кучу исключений, и попробуй разберись, где там у них валидируется этот конкретный кусок данных… Как результат, по мере развития проекта становится тяжело и дорого соблюдать и требования (зачастую довольно путаные), и единообразие подходов к валидации данных.

Так есть ли какой-то простой и изящный способ валидации данных? Способ, который защитит нас от греха нечитаемости, способ, который соберет всю логику валидации воедино, и который уже создан за нас разработчиками популярных Java-фреймворков?

Да, такой способ существует.

В большинстве моих собеседований на технические позиции есть задача, в которой кандидату необходимо реализовать 2 очень похожих интерфейса в одном классе:

Реализуйте оба интерфейса одним классом, если это возможно. Объясните, почему это возможно или нет.

interface WithPrimitiveInt {
  void m(int i);
}

interface WithInteger {
  void m(Integer i);
}

От переводчика: Эта статья не призывает вас задавать такие же вопросы на интервью. Но если вы хотите быть во всеоружии, когда этот вопрос зададут вам, то добро пожаловать под кат.

Представления, или views, это одна из концепций платформы CUBA, не самая расхожая в мире веб-фреймворков. Понять её — значит уберечь себя от глупых ошибок, когда из-за неполностью подгруженных данных приложение внезапно перестает работать. Давайте посмотрим, что представляют из себя представления (каламбур) и почему это на самом деле удобно.

Проблема незагруженных данных

Возьмём предметную область попроще и рассмотрим проблему на её примере. Предположим, у нас есть сущность Customer, которая ссылается на сущность CustomerType в отношении много-к-одному, иными словами, покупатель имеет ссылку на некий тип, его описывающий: например, "дойная корова", "грубиян" и т.п. Сущность CustomerType имеет атрибут name, в котором хранится имя типа.

И, наверное, все новички (а то и продвинутые пользователи) в CUBA рано или поздно получали такую ошибку:

IllegalStateException: Cannot get unfetched attribute [type] from detached object com.rtcab.cev.entity.Customer-e703700d-c977-bd8e-1a40-74afd88915af [detached].

Признайтесь, вы же тоже это видели своими глазами? Я — да, в сотне разных ситуаций. В этой статье мы рассмотрим причину этой проблемы, почему она вообще существует и как её решить.
Для начала — небольшое введение в концепцию представлений.

Что такое представление?

Представление в CUBA — это, по сути, набор столбцов в базе данных, которые должны быть загружены вместе единым запросом.

TL;DR: SDKMAN CLI будет переписан на Golang

Шесть лет прошло с тех пор как мы выпустили первую версию SDKMAN. В более ранних версиях он был известен как GVM и использовался для управления Groovy и связанным с ним инструментарием. Вскоре стало очевидно, что он не должен ограничиваться экосистемой Groovy, и может также применяться к другим SDK на JVM. В этот момент GVM был переименован в SDKMAN. Хотя название и изменилось, основная технология осталась прежней.

Подобно тому, как GVM однажды перерос своё имя, SDKMAN перерос технологию, на которой он был построен. Несмотря на то, что сервисы бэкенда были заменены лучшими альтернативами, CLI клиент остался прежним и стал нашим самым большим источником разочарования.

Примечание переводчика: развитие фреймворка CUBA порождает большое количество R&D проектов. В ходе одного такого проекта выяснилось, что нам нужно вызывать default методы интерфейсов из прокси классов. Наткнулись на очень полезную статью, мне кажется, что опыт, изложенный в ней, будет, как минимум интересен, как максимум — полезен широкому кругу разработчиков.

Когда дело касается доступа к default методам интерфейсов в Java через рефлексию, гугление не очень помогает. Например, решение на StackOverflow работает только в определенных ситуациях и не на всех версиях Java.

В этой статье будут рассмотрены различные подходы к вызовам default методов интерфейсов через рефлексию, это может быть нужно, например, при создании прокси-классов.

TL;DR Если вам не терпится, то все способы вызова default методов, описанные в этой статье, доступны по этой ссылке, а также эта проблема уже решена в нашей библиотеке jOOR.

Когда вы читаете требования к очередному корпоративному веб-приложению для внутреннего использования, то обычно (сужу по своему опыту) это один и тот же набор: реляционная база для хранения данных, зачастую доставшаяся от предыдущей версии приложения, большое количество форм разного уровня сложности (но одновременно типовых) для ввода данных, множество форм отчетности, сложная бизнес-логика, интеграции с другими приложениями — от бухгалтерии до управления поставками, несколько тысяч одновременно работающих пользователей. Что обычно приходит в голову?

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

Ричард Хукер

Как вы возможно знаете, 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.

Насколько безопасным должно быть приложение? Для кого-то этот вопрос не имеет смысла. "Настолько, насколько это возможно. Чем безопасней, тем лучше". Но это не исчерпывающий ответ. И он не помогает сформировать security политику в проекте. Более того, если придерживаться только этой директивы ("чем больше security, тем лучше"), мы можем оказать медвежью услугу самим себе. Почему? Ответ под катом.

Вы не поверите, но в 2018 году всё ещё нужно разрабатывать Desktop приложения.

Представьте себе такой клуб анонимных Java программистов, запойных и беспробудных, которые сидят и делятся своими проблемами.

— Здравствуйте, меня зовут Юрий, я пишу Desktop приложения в 2018 году.
— Здравствуй, Юрий, давайте ему похлопаем, он смог поделиться своей проблемой!

Да, действительно, мы всё ещё пишем Desktop приложения. Обычно, не очень хочется этим заниматься, чаще всего это legacy проекты. Но бывает, что нужно писать и новые настольные приложения.

Зачем мы всё ещё это делаем, если есть web с его новыми продвинутыми возможностями: Progressive Web Apps, Service Worker, Web RTC, Web GL и т.д?

Под катом расскажу как с этим жить и при чём тут Java.

Как я обещал в прошлом посте, я рад представить план развития Платформы на этот год. Это стратегический план, в который мы включили только крупные изменения, но безусловно будут иметь место и сотни мелких улучшений.

Дисклеймер: Этот план не является догмой, и мы наверняка реализуем что-то сверх него, а что-то наоборот отложим. Однако в целом мы собираемся придерживаться этого плана, и предлагаем сообществу разработчиков на Платформе CUBA также на него ориентироваться.

Тизер: CUBA Studio будет встроена в IntelliJ IDEA!

Итак, поехали!

На заре 2018 хочется подвести итоги, и рассказать об изменениях в платформе CUBA за прошлый год. Если 2016 стал для нас революционным благодаря переходу в опенсорс, то 2017 стал годом планомерного развития: мы сфокусировались на предложении новых фич и услуг нашему сообществу.

Sql, RegExp, Gradle — что их объединяет? Всё это примеры использования проблемно-ориентированных языков или DSL (domain-specific language). Каждый такой язык решает свою узконаправленную задачу, например, запрос данных из БД, поиск совпадений в тексте или описание процесса сборки приложения. Язык Kotlin предоставляет большое количество возможностей для создания собственного проблемно-ориентированного языка. В ходе статьи мы разберемся, какие инструменты есть в арсенале программиста, и реализуем DSL для предложенной предметной области.

Весь синтаксис, представленный в статье, я объясню максимально просто, однако, материал рассчитан на практикующих инженеров, которые рассматривают Kotlin, как язык для построения проблемно-ориентированных языков. В конце статьи будут приведены недостатки, к которым нужно быть готовым. Используемый в статье код актуален для Kotlin версии 1.1.4-3 и доступен на GitHub.