Александр Косарев

Попробуй сделать что-то вроде этого перед инициализацией клиента:

// ...
import java.net.Authenticator;
import java.net.PasswordAuthentication;
// ...
        Authenticator myAuth = new Authenticator() {
            @Override
            protected PasswordAuthentication getPasswordAuthentication() {
                return new PasswordAuthentication(username, password.toCharArray());
            }
        };

        Authenticator.setDefault(myAuth);
// ...

Если нужно перевести что-то с GWT с наименьшими потерями, то один из лучших вариантов - Vaadin, который основан на GWT.

Если есть желание переписывать Java-бекенд на Java EE, тогда можно использовать JSF совместно с RichFaces/PrimeFaces, либо Rest-сервисы Spring/Jersey и фронтенд на любом JS-фреймворке (хоть Angular, хоть ExtJS)

Как сказал Ivan Sokolov, если не было выброшено ошибок, то всё ок. Если ты являешься разработчиком rest-сервиса, который дёргаешь, то уверенности может добавить правильные модульные и интеграционные тесты.

лучше Spring WebMVC сложно что-то придумать, особенно учитывая экосистему Spring

Возможно, это можно разрулить, используя профили Spring, и в каждом OSGI bundle указывать нужный профиль.

Что бы из SQL-запроса Hibernate возвращал объекты конкретного типа, нужно этот тип явно указывать при помощи метода addEntity():

List tariffs = session.createSQLQuery(sql).addEntity(Tariff.class).list();

Да и вопрос - зачем использовать SQL в данном случае?

ExtJS, GWT, PrimeFaces

Книги (лучше на англ. языке найти):
Spring 4 In Action
Spring 4 Pro

Сайты:
Официальная документация (ИМХО, эталонная)
Гайды

В своё время писал что-то подобное на основе Netty, использовал протокол RTSP и сопряжённые с ним (RTP, RTCP). В целом задача несложная, если жать медиапоток на стороне автора: получил фрейм, отдал всем подписчикам; но если требуется жать медиапоток на стороне сервера или хранить видео в каком-нибудь "неживом" формате, то на сервере нужно ещё писать обработку потока, что уже сложнее.
Принцип достаточно прост, нужно реализовать две связи:
1. Автор -> сервер, где автор передаёт данные серверу через протокол. Полученные данные можно хранить в сыром формате, что бы потом склеивать данные потока в файл обычного формата.
2. Сервер -> подписчики. Тут задачка усложняется выбором протокола. Если используются клиенты вроде VLC, то можно использовать тот же RTSP, если видео встраивается в флеш-плеер, то удобнее RTMP, а если есть желание использовать встроенный в браузер плеер, то это уже HLS или MPEG-DASH. Самая проблема - писать переход между протоколами.

ИМХО:
Бекенд: Spring Boot (+MVC) без внешнего сервлет-контейнера (но если сильно надо, то можно и с ним)
БД: JPA (Spring Data JPA) и PostgreSQL

Хотя про БД всё зависит от целей. У меня встречались проекты, которые MySQL не вывозил, но с которыми PostgreSQL справлялся на ура.

Проверяемые исключения нужны, что бы знать, где может возникнуть исключительная ситуация и правильно обработать. Да, если при ошибке ты просто пишешь в лог что-то вроде "Эй, чувак, у тебя с БД что-то нетак", а не пытаешься завершить действие каким-нибудь иным способом, то проверяемые исключения тебе будут мешать (по принципу "плохому танцору ...").
Хороший пример работы с проверяемыми исключениями - транзакции при работе с БД.

Для начала прочитай Изучаем Java (К. Сьерра, Б. Бейтс), хотя можно начать и с книг Хорстмана. Ещё попутно рекомендую прочитать Объектно-ориентированный анализ и проектирование. Одновременно или сразу после этого можно пройти курс на JavaRush (или другом каком-нибудь аналогичном ресурсе). После этого можно браться за изучение Spring и Java EE попутно добивая пробелы в знаниях SE книгами Java 8 полное руководство (Г. Шилдт) и Язык программирования Java SE 8. Подробное описание (Дж. Гослинг). Остальное - дело практики.

Если вся команда использует lombok, то понимание кода не изменится. Но самостоятельно применять такой подход, будучи в команде, я бы не стал. Если код пишется правильно, и длина методов имеет разумные размеры, то проблем в понимании не должно возникнуть.

Но, ИМХО, подобные "инструменты" лучше обходить стороной.