А что не так с Kotlin? (Не знаю про него ничего.)

Ну хотя-бы то, что на нем еще ничего не написано, кроме hello world из примеров.

На Ceylon пока тоже.

А ещё непонятно, как на Ceylon сделать WAR-приложение, потому что у него свой собственный рантайм поверх жабовского. Я так понимаю, у Scala с этим проще, оно просто компилируется в байт-код и всё?

А без интеграции с сервлет-контейнерами круг применений резко сужается.

ява

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

После этого разработка на чистом JS просто раем кажется

Мне скорее кажется адом. Причем, неприспособленность для этого самого JS (отсутствие статической типизации в частности) - только часть этой проблемы. Вторая часть - сам HTML/CSS.

А что там не так?

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

Кстати, у вас CRUD головного мозга детектируется, а БД не только для отображения содержимого склада на формах используется. Есть удаленное хранилище, есть многоступенчатые задачи, выгребающие из него данные для последующих обсчетов. Данных может быть много. По новой таблице на результаты каждой задачи - здесь идеальное «секционирование». На jdbc-template это делается легко и непринужденно. На хибернейте - нет.

«DDL низзя» - это предрассудок какой-то, в приличных БД DDL транзакционный, а если его хибернейт не поддерживает (на равне со своими объектами), то это проблема хибернейта.

Мм, может стоит перестать грызть кактус и использовать прекомпилированный GWT в виде Vaadin? У нас от него впечатления весьма положительные.

отсутствие разницы между статическим и динамическим контекстом

Это что за контексты такие?

Это, на сколько мне кажется, может породить сериоус проблемы в многопоточных программах; отсутствие типизации.

Это ж надо столько увидеть в безобидных трех строчках. Такой фантазии любой шизофреник позавидует. Главное, не бросайте рисовать.

что практика показала, что они таки нужны

Чушь. Практика ничего такого не показала. Просто приходящие с C++ толпы баранов слишком громко визжали, что им это якобы «нужно».

Все современные архитектуры Гарвардские, так что проследуй в топку.

По новой таблице на результаты каждой задачи - здесь идеальное «секционирование». На jdbc-template это делается легко и непринужденно. На хибернейте - нет.

Если у таблиц одинаковая структура (а иначе как вы вообще сделаете ORM?) - заводить новый EntityManager на каждую операцию с ручным оверрайдом имени таблицы для соответствующего класса.

Или EclipseLink'овский Dynamic JPA.

Хотя это всё костыли, конечно.

Spring - тормоз, говно и нинужен, при имеющихся JSF и CDI.

JSF? Уж лучше Spring + что-нибудь, чем JSF.

PS CDI по описаниям нашка, но реально не пробовал.

Чушь. Практика ничего такого не показала. Просто приходящие с C++ толпы баранов слишком громко визжали, что им это якобы «нужно».

Достаточно посмотреть на примеры кода на legacy Java без дженериков и аннотаций, чтобы понять, какие килотонны boilerplate-кода они экономят.

Я уж молчу про типобезопасность и отлов ошибок на стадии компиляции.

blunt self promotion

Есть ли для Java такой ORM, который вам нравится

Интересная дискуссия про ORM. Я вот перенес куски ORM, которые были нужны, на SpringJdbc:
- результаты запросов в виде итераторов
- маппинг результатов на immutable объекты
- Criteria API для бедных
- генерилка typesafe интерфейсов (для параметров запросов и результатов) и glue-кода по SQL запросам

Велосипеды, велосипеды, велосипеды. Да ещё и прибитые гвоздями к Спрингу, я так понимаю.

А что мешает использовать уже существующий, активно развивающийся и оттестированный querydsl-sql?

А можно сделать DI без мутабельности?

Я выше давал ссылку http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di/

Да не то что бы не так. Но, вот в яве 8 введут пресловутые дефолт методы в интерфейсах, в циклоне это одна из «фишек». Обобщения у них сделаны неплохо, но синтаксис по моему неудобный. В общем субъективщина, плюс в ява 8 будет что то из фишек цейлона, так зачем он тогда. В общем полное шерстение тура показало мне, что нет, все же посижу пока на яве :)

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

Кстати, я так понимаю, ява авторы пошли на поводу у моды в определенном смысле...идея примесей сейчас витает в воздухе у многих языков.

Я знаю ответ. Это LISP. Он заменит все имеющиеся сейчас языки и технологии.

Разве не очевидно?

в общем, очевидно, но не всем. проблема в том, что IT — отрасль, в которой мало умных людей, среднестатистический жабакодер соответствует слесарю 40 лет назад, т.е. это уровень ПТУ, а не университета или хотя бы института. и вот таким людям всё это совершенно не «очевидно».

boilerplate-кода

Придумали себе ламеры ругательство. Boilerplate, boilerplate - а чем это, собственно, плохо? Многословно, но зато повышает читаемость, имеет более предсказуемое поведение, требует меньше ментальных сил для понимания.

Я уж молчу про типобезопасность и отлов ошибок на стадии компиляции.

Для тех редких случаев, когда надо избегать кастов из/в Object, делаются типобезопасные обертки над контейнерами. Без всяких жёнериков.

Многословно, но зато повышает читаемость

/0

Для тех редких случаев, когда надо избегать кастов из/в Object

Ничего себе редких.

делаются типобезопасные обертки над контейнерами

Ну удачи - копипастить один и тот же код -дцать раз. Кстати, такая обёртка банально не сможет реализовать интерфейс List. Ведь дженерики в интерфейсах и covariant return types мы тоже выбрасываем, да?

Велосипеды, велосипеды, велосипеды. Да ещё и прибитые гвоздями к Спрингу, я так понимаю.

100% верно.

querydsl-sql

В продакшене не использовали, смотрели его достаточно давно, когда выбрасывали хибернейт перед новым проектом. querydsl ограниченный сильно, он typesafe за счет мертвой привязки таблиц к генеренным классам. А нам не нужны были ни привязка к таблицам, ни сама генерация классов (для typesafe запросов они не обязательны). Кроме того, он большой очень. Проблема стояла - передать в SQL запрос типизированные параметры (класс а не Map), получить из запроса типизированные ответы, при изменении набора параметров/колонок ответов - упасть на этапе компиляции, а не выполнения. Было общее мнение, что querydsl здесь больше проблем создаст, чем решит. Ну и criteria-на-стероидах не нужны были по большому счеты, большая часть запросов plain-sql и в criteria все равно не укладываются. Может с тех пор он сильно лучше стал - не знаю.

Брр, ничего не понял про мутабельнось, поясните медленному жабакодеру плиз.

Вот есть у меня иммутабельный класс1, все поля у него иммутабельны и зафиналены. Я его без спринга создаю. Есть такой же класс2 со спрингом, поля с @Inject не зафиналены, но сеттеров нет.

Поля класса1 я не могу поменять через API класса (так как зафиналены), а через reflection могу (я через него все могу).
Поля класса2 я не могу поменять через API класса (так как сеттеров нет), а через reflection могу (см. выше).

Защита компилятором полей от присвоения внутри методов этого же класса - это булшит, мой класс же и медоды мои, а поля в еклипсе другим цветом. Защита компилятором вызова конструктора со всеми параметрами - тоже фигня, никто клиенту не мешает в конструктор null'ов напихать, а дерево объектов задолбаешься конструкторами собирать.

И в чем здесь разница?

querydsl ограниченный сильно, он typesafe за счет мертвой привязки таблиц к генеренным классам.

Использовать сгенерённые классы необязательно, можно использовать свои и генерировать Q-классы с помощью @QueryEntity. Либо можно вообще отказаться от Q-классов и использовать PathBuilder, передавая имена свойств строками.

Для возвращаемых значений можно опять же использовать любые свои классы (необязательно те, которые замаплены на таблицы) либо QTuple.

Ещё раз: зачем вешать @Inject на поля? Это какая-то спрингоспецифичная практика? Документация по Guice рекомендует инжектить конструкторы, хотя инжект полей и сеттеров он тоже поддерживает.

отсутствие статической типизации в частности

Вот что что, а статическая типизация для этого не нужна.

Сейчас не очень хочется копать справку querydsl, есть подозрения, что такое «нестандартное» (для querydsl) использование, будет либо менее развитое, либо глючное, либо с потерей всех основных преимуществ (typesafe), либо все это вместе.

Если вы глубоко погружены в querydsl, то можете описать, как в нем будет выглядеть:
1) маппинг результатов SQL запроса (с джойнами и window функциями) на объект. Запрос при этом должен храниться в SQL файле (его могут править в продакшене)
2) передача входных параметров в такой запрос

Часть полей в @PostConstruct заполняется, который в спринге вызывается сильно после создания объекта. Т.е. все поля все равно не запихать в конструктор, поэтому они все @Inject не финальные.

И рекомендации гуиса - это очень хорошо, но неплохо бы технические аргументы приводить, а не ссылки на авторитеты.

Строгая статическая типизация нужна чтобы вылавливать грабли на этапе компиляции, а не когда-то потом, когда их тестировщики пропустят.

Строгая статическая типизация нужна чтобы вылавливать грабли на этапе компиляции, а не когда-то потом, когда их тестировщики пропустят.

А плюс к этому такая небольшая мелочь, как скорость работы кода, которая достигается при наличии статической типизации.

И рекомендации гуиса - это очень хорошо, но неплохо бы технические аргументы приводить, а не ссылки на авторитеты.

• Это единственный вид инжекта, позволяющий гарантировать неизменяемость объекта на уровне языка.
• Доступ к private-полям извне - это нарушение инкапсуляции. Хотя, конечно, этот аргумент убедит только пуристов.
• Класс можно создать вручную, без DI. Гибкость. Но если это не нужно, достаточно просто сделать конструктор protected или package-private.
• Если добавить в конструктор новый параметр, то все тесты, создающие класс вручную, перестанут компилироваться. По сравнению с инжектом сеттеров это гарантирует, что разработчик не забудет поправить тесты, передав в них новый параметр.
• Конструктор - в том числе конструктор производного класса - не может доступиться к полям, инжектируемым не в конструкторе, потому что на момент выполнения конструктора они ещё не инициализированы.
• При инжекте полей класс не имеет контроля над инициализацией этих полей. Например, при присваивании полей изменяемого типа (например, Date или коллекций) по-хорошему нужно их копировать, чтобы предотвратить их непредвиденное изменение сторонним кодом. Это можно сделать только в конструкторе или в сеттере, но не при прямой инициализации полей.

Ну чтож поделать, люди действительно часто неосиливают такие мощные языки, как Scala или там C++. В них много концепций и сложных закавык, а люди хотят чуток посидеть-побыдлокодить в офисе и пойти на хрен оттуда. Kotlin это вполне позволит.

Это единственный вид инжекта, позволяющий гарантировать неизменяемость объекта на уровне языка.
неизменяемость объекта

Это неверно, через reflection я могу поменять final поле (заданное через конструктор).

Доступ к private-полям извне - это нарушение инкапсуляции. Хотя, конечно, этот аргумент убедит только пуристов.

Здесь инкапсуляция будет на уровне бина спринга, а не на уровне класса java. После создания бина спрингом - он отлично инкапсулирован

Класс можно создать вручную, без DI. Гибкость. Но если это не нужно, достаточно просто сделать конструктор protected или package-private.

Нет, нельзя, и гибкость липовая. В класс могут быть заинжектены ресурсы, до которых очень непросто без спринга достучаться (например, транзакции сами будете разруливать). В реальности тесты также гоняются через спринг (с урезанным тестовым контекстом).

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

См. выше. Тесты будут через спринг.

Конструктор - в том числе конструктор производного класса - не может доступиться к полям, инжектируемым не в конструкторе, потому что на момент выполнения конструктора они ещё не инициализированы.

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

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

Никто не мешает объявить поля в виде DateTime и ImmutableList соответственно. Если нужно immutable поле, зачем же в нем использовать mutable типы? Если очень нужно что-то с данными сделать при создании (защитная копия как у вас), то это можно из @PostConstruct сделать.

Вообще похоже, что вы сводите дискуссию о иммутабельности DI к дискуссии об иммутабельности вообще. Я только за иммутабельность, все value-классы держу такими (а создаю через билдеры). Но для сервис-классов, над которыми DI выполняется, иммутабельность создает больше проблем, чем решает.

А еще людям приходится поддерживать проекты на мощных языках, в которых используются все возможнные концепции и закавыки.

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

Сочувствую. Переходите на жабу. Тут больше денег и меньше работы.

Уже перешел, недавно вот переводил небольшой scala проект на жабу. Скала, она наверное хороша, если только со скальными фреймворками использовать, такая замена для руби. А с жабобиблиотеками - ну ее нафиг, с совместимостью полная труба. Ну и время компиляции скалы (и ограниченно рабочий fsc) делало меня плакать.

два главных тормоза в Java enterprise apps - это мавен и аннотации.

А то что то они совсем уже застабилизировались...аж мхом поросли.

Не пользовать религия не позволяет? Юзай дудНЕТ со звонками и свистками.

Совместимость - это лучшее, что есть в Java.

PL/I (олдфаги меня поймут, а школоло - учить матчасть) в свое время на этом слил C.

Кстаті, стандартный C только в 2011г узнал про multi-threading.

Вообще, следующим стандартом станет то, что будет работать на стороне браузера и сервера. Пока решением является компиляция в яваскрипт (многие выкатывают, гугл вот «дарт» выкатил). Еще обратное появилось, яваскрипт на сервере.

Ты этот «яваскрипт на сервере» кушал? Я больше не хочу.

Клева, некоторые могут мозг включать при проектировании языка (Страуструп), а некоторые не могут (Гослинг). Но при этом кричат, что старое надо отбросить, потому как небезопасно, а потом вводят откинутое, так как понимают, что без него трудно.

Это и раздражает у всяких резволюционеров.

Старым мир нахрен разрушим, и новый яркий построим.

Но, поскольку, люди/задачи/подходы что в старом, что в новом мире практически одинаковы, то выходит все опять по-старому.

http://ceylon-lang.org/documentation/1.0/tour/types/ http://ceylon-lang.org/blog/2012/12/21/tuples-and-functions/

Ява сосет. Скала посасывает. А жаль, надеюсь Оракл или Мартин перетянут это из Цейлона.

И да, все отписавшиеся выше моего первого поста не шарят.

Они гибридные, гарвардские они только на уровне L1 кэша и ядра, все остальное представление является фон Неймановским. И да, гарвардская от фон неймановской не далеко ушла в плане масштабируемости.

некоторые могут мозг включать при проектировании языка (Страуструп), а некоторые не могут (Гослинг).

Ога, Страуструп так хорошо моск включал, что на поделку Гослинга для пылесосов накинулись, как на ману небесную.

Неосиляторы и хороший маркетинг.

В чем именно посасывает скала?

хороший маркетинг

Популярность говноплюсов ничем другим объяснить тоже нельзя.