К сожалению разобрать байт код нельзя, потому что, чтобы его получить, нужно скомпилировать код. А зависимости мы ищем как раз для того, чтобы этот самый код скомпилировать.
Вы читаете мой комментарий или сразу отвечаете? Я спросил только про Build Tool. SBT один из самых противоречивых инструментов сборки, который даже в родном Scala сообществе воспринимается как нечто не в меру странное. Чуть ли не половина разработчиков на Scala используют не его, а Gradle.
Все GC в Java определяют достижимость объектов от корней кучи. Если объект недостижим — он кандидат на отстрел, циклические ссылки не могут препятствовать отстрелу по определению.
А откуда вы вообще взяли, что Lucene и Activiti имеют какие-то проблемы с масштабируемостью? Lucene — де-факто стандарт в своей области, как и Activiti, активно используемый в Alfresco.
Мы используем свежие версии Vaadin 7.6 (в скором времени 7.7), но интерфейсы компонентов и декларативная разметка для экранов у нас своя. Мы не хотим распыляться на несколько UI фреймворков, поскольку мы сами тоже пишем компоненты для UI, кроме того, для custom веб-сайтов мы предлагаем модуль интеграции со Spring MVC и свой generic REST-API.
C WebSocket в 7.6 всё довольно хорошо, сложных проблем ещё ни разу не возникало.
Стандартные библиотеки для интеграции Spring и Vaadin не используем, у нас свой слой интеграции, и Vaadin используется только и исключительно как UI toolkit.
Ну а уж на вопрос про покрытие тестами вы можете ответить сами, юнит тесты лежат прямо в проекте cuba на github. Тестовое покрытие наших премиальных компонентов мы, пожалуй, можем раскрыть только нашим клиентам.
Я думаю поддерживается, но не для всего приложения. Сущности JPA придётся оставить на Java, а вот код сервисов и экранов можно будет писать на Scala. Мы проверим насколько хорошо можно использовать Scala с CUBA, как сделали это для Groovy. Groovy сейчас поддерживается даже в Studio.
Могу перефразировать, "с явного одобрения происходяшего компанией". Иначе в описании спикера не стали бы писать, что "человек руководит тем то и тем то важным".
Хм, про Jetbrains могу уверенно сказать, что доклад был под эгидой компании. И многие смотрели доклад, ожидая другой материал, который бы соответсвовал имиджу компании.
В прошлом году было два доклада про Scala. Тот что от Jetbrains был совсем глупый и бесполезный, хотя с зазывающим названием. Зато доклад от Sociohub был приятный, в этом году есть доклад от того же спикера: Страх и ненависть в распределённых системах.
Из ваших заметок пока видится только один посыл: не критикуйте MySQL. Лучше бы побольше писали про настоящие недостатки, на которые нужно смотреть при сравнении с Postgres.
>> Vaadin это Java фреймворк для создания современных высокопроизводительных веб приложений
Это совсем плохое описание Vaadin, высокопроизводительные это не про них, больше подошло бы:
Vaadin — фреймворк для разработки веб-приложений с server-side моделью программирования и состоянием UI на сервере.
Groovy намного ближе к Java, чем Scala. Использовать для Java проектов SBT я бы не стал. При этом в Gradle отличная поддержка всех трёх языков: Java/Groovy/Scala.
И вас устраивает количество мусора в проекте? Разные build.sbt, pligins.sbt и отдельная папка project? Уж лучше лаконичный Gradle с одним скриптом build.gradle, чем этот вынос мозга.
Этот выбор был сделан нами очень давно (более 5 лет назад) и с тех пор мы смотрели несколько веб фреймворков — ZK, Smart GWT, и даже JS фреймворки. Но ни разу мы не находили необходимой нам функциональности и гибкости. Наработок по Vaadin у нас очень много и в перспективе мы не планируем от него отказываться.
Мы тестируем пользовательский интерфейс платформы при помощи Selenium, но это действительно требует времени. Дополнительно мы тестируем код компонентов и код UI слоя при помощи тестов с Mock-объектами, когда большая часть инфраструктуры мокается. Но всё же это далеко от хорошего покрытия тестами UI.
У нас всё усугубляется тем, что прикладной UI код исполняется на стороне сервера, но код компонентов исполняется и на стороне браузера. Из-за такого размазывания приходится больше полагаться на Selenium тесты, если тестируем компоненты и сложный UI.
MVP к сожалению нам не подошло, у нас больше компонентный подход к UI.
У нас довольно богатый функционал UI — есть таблицы, деревья, фильтры (задаваемые пользователем в UI и исполняемые в виде преобразованного SQL), много разных полей ввода, поиска. Использование платформы может сильно помочь в проектах с большим количеством форм ввода, таблиц, графиков. Никаких сложностей при создании CRUD в приложениях на платформе мы давно в глаза не видывали.
Наши приложения сильно отличаются от классических Java + Spring MVC, и больше тяготеют к большим десктоп-решениям.
Знаете, а я сильно ненавижу гугл за возможность удалять программы удалённо с моего телефона. И вот такой способ блокирования тоже может вредить пользователям, ведь достаточно взлома гугл аккаунта, чтобы доставить реальные физические проблемы с ноутбуком.
Ну вы уж сделайте поправку на то, что это с одной стороны демонстрационный пример, а с другой — готовый для использования на сервере компонент, с поддержкой биндинга данных и полноценным Java API.
GWT для Vaadin нет в виде отдельного SDK. Все классы GWT перепакованы в jar файлы Vaadin. А IDEA хочет видеть жарники GWT. Вероятно есть какой-то вариант решения это проблемы, но видимо не простой.
Мы используем 2.7 (он включён в Vaadin 7.3), перекомпиляция быстрая. Мы вообще не очень часто правим GWT код, поскольку у нас стабильный набор серверных компонентов.
К сожалению GWT плагин для Idea требует GWT SDK, а Vaadin использует свою сборку GWT (форк с фиксами). При попытке использования плагина в ClassPath попадают версии исходников из GWT SDK, а некоторым классам Vaadin требуются классы из их GWT сборки.