Как известно, 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.

Вы могли заметить, что мы опубликовали новые минорные релизы платформы CUBA и CUBA Studio. В новой версии реализованы улучшения, в основном касающиеся текущего функционала, но мы добавили и несколько новых полезных фич.

Под катом:

• Uber JAR
• UI-компонент для предиктивного поиска
• Версионирование REST API
• Балансировка нагрузки в кластере
• Компонент приложения ZooKeeper
• Улучшения в Polymer UI
• Поддержка Bean Validation в CUBA Studio
• Поддержка Groovy в слушателях сущностей

Быстрое развитие технологий и инструментов разработки ПО приводит к тому, что технологии, лежащие в основе информационной системы, теряют свою актуальность и становятся тяжелой ношей. Взять, к примеру, какую-нибудь разработку компании для автоматизации процессов, написанную на Visual Basic 6.0 или Delphi 7, которая, мягко говоря, не сочетается с новыми трендами “все в web, все в облака”, да и не соответствует амбициям разработчиков.

Проблема перевода старой ИС на новые технологии, доходя до руководства, традиционно упирается в деньги: “поживем и так...”. Для разработчиков, в свою очередь, уже перенос модели данных и шаблонное программирование стандартных экранов вызывает негатив. При этом зачастую все усложняется требованием сохранения работоспособности старой ИС на этапе разработки и внедрения новой. Так или иначе, по моему опыту, продукт либо умирает совсем, вызывая мучения как программистов, так и пользователей, либо все же приходит понимание, что обновление ИС — неотложная необходимость.

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

Под катом пошаговая инструкция, как модернизировать устаревшую систему с минимальными усилиями на перенос модели данных и стандартных CRUD экранов.

Недавно мы выпустили новый релиз CUBA Platform и CUBA Studio. Если в версии 6.3 мы сделали акцент на архитектурных и технических новшествах, то этот релиз прибавил к платформе много фич, с которыми процесс разработки стал быстрее и удобнее. Мы добавили новые визуальные компоненты универсального пользовательского интерфейса, централизованный механизм валидации данных, движок для генерации альтернативного фронт-энда на основе Google Polymer и другие важные улучшения. Подробности — под катом.

Disclaimer: статья в первую очередь адресована разработчикам, уже знакомым с платформой CUBA.

Эта статья – традиционный пост, подводящий итоги завершившегося года. А также история о том, что даже хороший продукт нужно уметь правильно продавать.

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


Активные проекты на платформе CUBA

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

Но для того чтобы создать инструмент, способный что-то систематизировать и упорядочивать, нужно для начала самим научиться систематизировать и упорядочивать свои дела. Для нас главное дело — разработка системы документооборота ТЕЗИС. Поэтому неудивительно, что работа над каждым новым релизом системы тоже движется по четкому маршруту — как работа над любым документом в нашей СЭД.

В этой статье мы хотим ненадолго пустить читателя на внутреннюю кухню разработки системы документооборота. Мы расскажем об этапах подготовки к релизу СЭД ТЕЗИС и покажем, как выстроена работа над новыми версиями. Возможно, наш организационный опыт окажется кому-то полезным.

Незаметно пролетели почти три года с момента публикации первой статьи о платформе на Хабре. За это время многое изменилось: мы вышли на международный рынок, перешли к open source лицензии, обновили стек технологий и внесли множество улучшений во фреймворк и средства разработки. Поэтому вместо длинного списка изменений мы решили опубликовать ещё одну обзорную статью о платформе CUBA, которая, я надеюсь, будет интересна разработчикам кровавого энтерпрайза корпоративных информационных систем — как ещё не знакомым с платформой, так и тем, кто уже что-то слышал о ней.

Итак, под катом вы узнаете:

• Что представляет из себя платформа CUBA и какова её архитектура
• Какие решения эффективнее всего разрабатывать на CUBA
• Как платформа помогает сэкономить время разработки корпоративных систем
• Какое окружение необходимо для развертывания CUBA-приложений
• Как мигрировать устаревшую систему на CUBA
• Под какой лицензией распространяется платформа
• Как организована поддержка разработчиков