Comments 104
Очень не хватает варианта: «Да, страдаем» ;)
Так много людей сидят на JavaEE? Я, честно говоря, думал, что это технология вымирает из-за своей сложности и монструозности. Как в свое время вымерла CORBA.
Помимо JavaEE есть ещё всякие вещи типа ATG, которые куда хуже :)
Да, и будут сидеть. Эта технология будет популярной, пока есть enterprise, а именно пока есть закостенелый enterprise. Увы, но это так.
Некоторые куски EEшного стека облагородились и стали куда приятнее. Мы, например, используем JAX-RS и чуток CDI (как legacy), хотя запускается это уже не на jboss as 7, а в embedded jetty (связка weld + resteasy).
В голосовании в отношении EE указывал "не используем".
Я думаю почти весь корпоративный сектор сидит на java EE, а их там очень много.
А у корпоратов часто выбора-то и нет. Если сказано, что покупная софтина за десятки миллионов работает в аппсервере под EE 5, то там будет сертифицированный аппсервер с техподдержкой, никто и не пикнет. И 1.4.2 будет, если понадобится.
С другой стороны, куча мелких соплей и верёвочек (в хорошем смысле) может работать на Java SE или, например, в tomcat'е/jetty. Сервлеты, конечно, часть EE, но столь привычная, что вроде под EE сервлеты давно никто не воспринимает.
Часто? Я вот видел подход десятка крупнейших банков. Он бывал любой — от «используйте то, что считаете нужным, включая опенсорс» до «ваш выбор Weblogic такой-то версии». Покупной софтины требующей сервера вообще ни видел никогда — обычно сервер просто входит в ее комплект (это IBM BPM к примеру — вебсфера внутри). Покупали вообще мало — значительно больше делают сами. Выбор Java EE всегда был осознанным и своим (хотя и не всегда все с этим были согласны). А все известные попытки написать свой велосипед с транзакциями и JMS на коленке — провалились.
Крайние версии JavaEE 6 и 7 не являются такими сложными и монструозными, как прежние, а JEE Web Profile вообще прост и удобен (пример JEE 6 Web Profile: http://tomee.apache.org )
Спасибо Spring за здоровую конкуренцию :-)
Спасибо Spring за здоровую конкуренцию :-)
Она не столько сложная, сколько неюзабельная, изначально неверная и по-большому ненужная. Монолитное приложение, деплоящееся в отдельный контейнер напрочь убивает возможность и желание что-то делать. Всякие хаки типа Arquillian и Embedded OpenEJB вмеремешку со своими костылям, конечно, помогают, но не панацея от напасти.
Тем не менее, клиент один раз потративший килодоллары на JEE платформу, хочет ее амортизировать и заставляет писать под нее. В этом случае действует четкое правило при работе с клиентом. Соглашаться на проект, если выполняются оба эти пункта:
1. Клиент с баблом
2. Он дебил
Если не выполнен первый пункт, смысла связываться нет — прогорите на поддержке. Если не выполнен второй — следует вразумить клиента, что есть более стабильные способы достижения результата, и что его задача — сконцентрироваться на самой проблеме, а не на способе ее решения.
Тем не менее, клиент один раз потративший килодоллары на JEE платформу, хочет ее амортизировать и заставляет писать под нее. В этом случае действует четкое правило при работе с клиентом. Соглашаться на проект, если выполняются оба эти пункта:
1. Клиент с баблом
2. Он дебил
Если не выполнен первый пункт, смысла связываться нет — прогорите на поддержке. Если не выполнен второй — следует вразумить клиента, что есть более стабильные способы достижения результата, и что его задача — сконцентрироваться на самой проблеме, а не на способе ее решения.
Ктож вас-то заставляет монолитное писать? Кстати, если в проекте нет контейнера — то с модульностью там обычно все еще хуже, чем когда он есть. А все без исключения виденные мной лично попытки заменить Java EE своим велосипедом как правило были намного хуже — впрочем, я это и сегодня живьем наблюдаю. Какой только фигни там не встретишь.
Стандартный вопрос: а что такого особенного дает вам контейнер JEE, что нельзя сделать отдельно от него? Единственно верный ответ — JTA, ради которого все и задумывалось. Однако мало того, что в 90% случаев он попросту не нужен, даже если работа идет с разными ресурсами, то в оставшихся 10% он вреден и создает ложное ощущение надежности. А JTA креши случаются, и если обычная программа как правило знает как выбраться из такой ситуации (это предусмотрено самой логикой), то в случае JTA все глухо лежит до тех пор, пока не поднимут с постели админа, который судорожно будет рыться в интернетах на вопрос как откатить рухнувшую транзакцию в конкретном контейнере. А в мире есть всего полтора человека, которые делали это.
Кроме того, вызов сраного вебсервиса, реста или даже простого remote EJB нарушает всю JTA, т.к. вызов не координируется с remote-контейнером.
Все остальное делается лучше и проще без JEE. Отдельные части как JPA, Servlets доступны ввиде библиотек и фреймворков, к тому же есть over9000 схожих альтернатив. А микросервисная архитектура становится мейнстримом. И вроде как over9000 высоконагруженных проектов в интернетах живет и здравствует без JEE.
Кроме того, вызов сраного вебсервиса, реста или даже простого remote EJB нарушает всю JTA, т.к. вызов не координируется с remote-контейнером.
Все остальное делается лучше и проще без JEE. Отдельные части как JPA, Servlets доступны ввиде библиотек и фреймворков, к тому же есть over9000 схожих альтернатив. А микросервисная архитектура становится мейнстримом. И вроде как over9000 высоконагруженных проектов в интернетах живет и здравствует без JEE.
Стандартный ответ — вы обобщаете свой ограниченный опыт на всех, и делаете ошибку. Нет, не JTA вовсе. А скорее управляемость кода в целом, как при разработке, так и в эксплуатации. В самом широком смысле.
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
Опустим презентационную часть, еще раз, что конкретно есть такого в JEE, что нельзя или слишком затратно сделать без него? Все технологии доступны по отдельности. Что такого важного и необходимого делает контейнер?
Ваши аргументы сводятся к вашему личному опыту сравнения с решениями, написанными по-ходу неквалифицированными программистами. И Вы делаете вывод, что виновато отсутствие JEE. Отчасти, конечно, Вы правы. Вместе с JEE идет набор стандартных паттернов для реализации типовых задач, которые пользователи недолго думая, копипастят в свой код. То же справедливо и для других фреймворков.
Согласно моему опыту, во-первых, мало людей среди тех, кто пишет на JEE понимает как он работает. А во-вторых, для большинства задач, где используется JEE хватило бы и простого stand-alone приложения, естественно, написанного человеком, умеющим писать на Java. Я не пытаюсь Вас переубедить в чем-то. Если Вы счастливы с JEE — очень хорошо. У меня за 10 лет работы с ним такого ощущения не сложилось. Кроме того, я просто не доверяю технологии, которая стартует больше трех секунд для выполнения элементарного теста.
> Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно
В теории да. На практике — геморрой с правильной запаковкой и classpath.
> контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая
Консоль — это фишка отдельно взятого контейнера, и не входит в стандарт JEE. JMX вообще изначально не относится к JEE и лежит где-то сбоку. Для реализации MBean-а не нужен контейнер. Для JMX есть jvisualvm плюс любая система мониторинга может с ним работать.
> remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
Попробуйте подружить контейнеры двух разных производителей и обеспечить транзакционность вызовов через remote. Все контейнеры фиговые. И бажные. Независимо от версии. Не верите — откройте багтрекер любого.
> Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
На то и инструменты: ZooKeeper, Consul, Eureka, etc… NGinx для Restful. Используются только когда реально требуется.
Опять же распределение портов никак не относится к JEE. То, что у Weblogic есть универсальный t3, который врапится через http, дает бонус только Weblogic, но не JEE как таковому.
> (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
Посмотрите чтоли презентации с jug.ru, например компании Codeborne. Тоже занимаются банковским софтом для крупных банков.
https://www.youtube.com/watch?v=y96fZdOoeiA
Ваши аргументы сводятся к вашему личному опыту сравнения с решениями, написанными по-ходу неквалифицированными программистами. И Вы делаете вывод, что виновато отсутствие JEE. Отчасти, конечно, Вы правы. Вместе с JEE идет набор стандартных паттернов для реализации типовых задач, которые пользователи недолго думая, копипастят в свой код. То же справедливо и для других фреймворков.
Согласно моему опыту, во-первых, мало людей среди тех, кто пишет на JEE понимает как он работает. А во-вторых, для большинства задач, где используется JEE хватило бы и простого stand-alone приложения, естественно, написанного человеком, умеющим писать на Java. Я не пытаюсь Вас переубедить в чем-то. Если Вы счастливы с JEE — очень хорошо. У меня за 10 лет работы с ним такого ощущения не сложилось. Кроме того, я просто не доверяю технологии, которая стартует больше трех секунд для выполнения элементарного теста.
> Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно
В теории да. На практике — геморрой с правильной запаковкой и classpath.
> контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая
Консоль — это фишка отдельно взятого контейнера, и не входит в стандарт JEE. JMX вообще изначально не относится к JEE и лежит где-то сбоку. Для реализации MBean-а не нужен контейнер. Для JMX есть jvisualvm плюс любая система мониторинга может с ним работать.
> remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
Попробуйте подружить контейнеры двух разных производителей и обеспечить транзакционность вызовов через remote. Все контейнеры фиговые. И бажные. Независимо от версии. Не верите — откройте багтрекер любого.
> Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
На то и инструменты: ZooKeeper, Consul, Eureka, etc… NGinx для Restful. Используются только когда реально требуется.
Опять же распределение портов никак не относится к JEE. То, что у Weblogic есть универсальный t3, который врапится через http, дает бонус только Weblogic, но не JEE как таковому.
> (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
Посмотрите чтоли презентации с jug.ru, например компании Codeborne. Тоже занимаются банковским софтом для крупных банков.
https://www.youtube.com/watch?v=y96fZdOoeiA
> Опустим презентационную часть, еще раз, что конкретно есть такого в JEE, что нельзя или слишком затратно сделать без него? Все технологии доступны по отдельности.
Интеграция и стандартизация же. Да, есть отдельно Weld, отдельно Jersey, отдельно к нему можно привинтить Arjuna. Нужны CMT — иди прикручивай AspectJ. Нужна система событий? Удачи с прикручиванием этого добра и пробросом зависимостей. Нужны распределенные транзакции? Идем читать маны по Hazelcast. Разработчик забил на поддержку Hazelcast? Начинаем переписывать километры интерфейсов, которые были под него заточены. И не надо мне рассказывать, что идеальные программисты из вашего окружения сразу разрабатывают идеальные интерфейсы, позволяющие легко интегрировать технологии, которые в момент написания этих интерфейсов еще не были придуманы.
Да, бывают баги. Да, некоторые конттейнеры ведут себя по-разному. Да, Weld в Glassfish ломается на выражениях, которые жует Weld из JBoss. Но без Java EE это было бы не «более надежно», этого бы вообще не было. Ваш путь — уничтожить Enterprise-платформу и поверх нее создать новую, коммунистическую Программу, которая будет сама все делать и обо всем знать — утопичен по своей сути. Есть у вас есть время и средства разрабатывать Enterprise-стек для каждого вашего нового проекта, это здорово, но большинству нужны рабочие приложения, а не идеальные схемы распределенной микросервисной архитектуры, промазанной костылями для решения проблем, которые в JEE решаются одной аннотацией.
Интеграция и стандартизация же. Да, есть отдельно Weld, отдельно Jersey, отдельно к нему можно привинтить Arjuna. Нужны CMT — иди прикручивай AspectJ. Нужна система событий? Удачи с прикручиванием этого добра и пробросом зависимостей. Нужны распределенные транзакции? Идем читать маны по Hazelcast. Разработчик забил на поддержку Hazelcast? Начинаем переписывать километры интерфейсов, которые были под него заточены. И не надо мне рассказывать, что идеальные программисты из вашего окружения сразу разрабатывают идеальные интерфейсы, позволяющие легко интегрировать технологии, которые в момент написания этих интерфейсов еще не были придуманы.
Да, бывают баги. Да, некоторые конттейнеры ведут себя по-разному. Да, Weld в Glassfish ломается на выражениях, которые жует Weld из JBoss. Но без Java EE это было бы не «более надежно», этого бы вообще не было. Ваш путь — уничтожить Enterprise-платформу и поверх нее создать новую, коммунистическую Программу, которая будет сама все делать и обо всем знать — утопичен по своей сути. Есть у вас есть время и средства разрабатывать Enterprise-стек для каждого вашего нового проекта, это здорово, но большинству нужны рабочие приложения, а не идеальные схемы распределенной микросервисной архитектуры, промазанной костылями для решения проблем, которые в JEE решаются одной аннотацией.
> Интеграция и стандартизация же.
Чего? API? Стандартизация чисто теоретическая. На практике контейнеры хоть и поддерживают стандарт, но всегда пытаются подсадить на свой vendor-lock. Возьмите хотя бы тот же Weblogic и посмотрите их мануали. Разработать портируемое приложение на JEE стоит усилий, несмотря на все стандарты.
По поводу интеграции: во-первых, есть Spring, где все уже прикручено, легко конфигурируется, и подключается по мере необходимости. А во-вторых, пусть программа сама прикручивает и сама конфигурирует API, которые она будет использовать, нежели делать это где-то ручками отдельно в контейнере через консольку или файлы конфигурации.
А вот стандартизация методики разработки — это вообще отсутствует как таковое. Стандарт JEE не говорит ни слова об этом. Как писать тесты к JEE модулям? Как автоматизировать запуск тестов? Как автоматически деплоить в контейнер? Как менять конфигурацию контейнера для тестов? Как дебагить код в контейнере? Как на лету деплоить изменения?
— TDD? Нет, не слышали.
Большинство все делают ручками: скомпилировать-запаковать-задеплоить-проверить. Можно судить о качестве такого кода и времени его разработки. Благо есть поделки типа Arquillian-а и JRebel-а которые хоть что-то облегчают в этом процессе, но это для особо умных.
Я не предлагаю уничтожить JEE платформу. Она уже давно себя изжила и уничтожилась сама. Просто долго агонизирует благодаря финансовой поддержке Oracle и IBM, а также ребятам из Redhat, которым удалось сделать процесс разработки и тестирования более-менее удобоваримым. Я лишь за то, чтобы люди трезво оценивали реальную необходимость той или иной технологии в проекте. Когда требуется простенький вебсервис, я делаю так:
@WebService
public class AddService {
@WebMethod
public int add(int a, int b){
return a+b;
}
public static void main(String[] args ){
Endpoint.publish(«http://localhost:1234/AddService», new AddService());
}
}
И это работает! А 95% людей, услышав слово webservice, полезли бы в JEE.
Чего? API? Стандартизация чисто теоретическая. На практике контейнеры хоть и поддерживают стандарт, но всегда пытаются подсадить на свой vendor-lock. Возьмите хотя бы тот же Weblogic и посмотрите их мануали. Разработать портируемое приложение на JEE стоит усилий, несмотря на все стандарты.
По поводу интеграции: во-первых, есть Spring, где все уже прикручено, легко конфигурируется, и подключается по мере необходимости. А во-вторых, пусть программа сама прикручивает и сама конфигурирует API, которые она будет использовать, нежели делать это где-то ручками отдельно в контейнере через консольку или файлы конфигурации.
А вот стандартизация методики разработки — это вообще отсутствует как таковое. Стандарт JEE не говорит ни слова об этом. Как писать тесты к JEE модулям? Как автоматизировать запуск тестов? Как автоматически деплоить в контейнер? Как менять конфигурацию контейнера для тестов? Как дебагить код в контейнере? Как на лету деплоить изменения?
— TDD? Нет, не слышали.
Большинство все делают ручками: скомпилировать-запаковать-задеплоить-проверить. Можно судить о качестве такого кода и времени его разработки. Благо есть поделки типа Arquillian-а и JRebel-а которые хоть что-то облегчают в этом процессе, но это для особо умных.
Я не предлагаю уничтожить JEE платформу. Она уже давно себя изжила и уничтожилась сама. Просто долго агонизирует благодаря финансовой поддержке Oracle и IBM, а также ребятам из Redhat, которым удалось сделать процесс разработки и тестирования более-менее удобоваримым. Я лишь за то, чтобы люди трезво оценивали реальную необходимость той или иной технологии в проекте. Когда требуется простенький вебсервис, я делаю так:
@WebService
public class AddService {
@WebMethod
public int add(int a, int b){
return a+b;
}
public static void main(String[] args ){
Endpoint.publish(«http://localhost:1234/AddService», new AddService());
}
}
И это работает! А 95% людей, услышав слово webservice, полезли бы в JEE.
Вы путаете «идеальную интеграцию» и «хоть какую-то». Spring вообще не панацея, по своей сути это еще один Java EE сервер, только с собственными нескучными API (хоть они и пытаются в последних версиях поддерживать стандартные, например, CDI Inject). Spring Boot превращает ваш софт в Bloatware, которое возит за собой тонны ненужных вещей, заботливо им сконфигуренных, и все такое прочее. То, что Spring легче конфигурить, чем, например, Wildfly — это, вообще говоря, неправда, вопрос привычки, не более.
Я по вашим ответам уже вижу, что вы «стиляга от разработки» — TDD, code coverage, continuous integration и вот это все. Я не отрицаю ваше право заниматься всем этим. Действительно, если потребитель каждый день ждет новых смайликов с котиками на вашем сайте, все это работает. Но поймите и вы, что есть совершенно другой мир. Есть мир, где деплой не проходит без одобрения службы безопасности, и где перед тем, как вы начнете писать модульные тесты на модульные тесты микросервисов к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире. Есть мир, где модные технологии правят, а есть мир, где правят отлаженные процессы и репутация вендоров. Какой бы медлительной не была WebSphere, она и поставляемое с ней добро, вроде message broker'ов, работают на сотнях тысяч инсталляций по всему миру, и если ко мне придет дядя с миллиардом долларов, и спросит, кому лучше доверить тот самый миллиард, уродливому Oracle, или модной MongoDB, я выберу первое, пусть я и терпеть его не могу. Потому что мода — это проходящее, а путешествие в лес в багажнике редко бывает чаще раза в жизни, и это неспроста.
Я по вашим ответам уже вижу, что вы «стиляга от разработки» — TDD, code coverage, continuous integration и вот это все. Я не отрицаю ваше право заниматься всем этим. Действительно, если потребитель каждый день ждет новых смайликов с котиками на вашем сайте, все это работает. Но поймите и вы, что есть совершенно другой мир. Есть мир, где деплой не проходит без одобрения службы безопасности, и где перед тем, как вы начнете писать модульные тесты на модульные тесты микросервисов к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире. Есть мир, где модные технологии правят, а есть мир, где правят отлаженные процессы и репутация вендоров. Какой бы медлительной не была WebSphere, она и поставляемое с ней добро, вроде message broker'ов, работают на сотнях тысяч инсталляций по всему миру, и если ко мне придет дядя с миллиардом долларов, и спросит, кому лучше доверить тот самый миллиард, уродливому Oracle, или модной MongoDB, я выберу первое, пусть я и терпеть его не могу. Потому что мода — это проходящее, а путешествие в лес в багажнике редко бывает чаще раза в жизни, и это неспроста.
Ну вот мы и вернулись к изначальному тезису.
1. У дяди есть миллиард
2. Он уперт и ограничен. Не понимает процессов автоматизации. Любит покупать красивые и дорогие штучки из линии Websphere и подобных.
В этом случае имеет смысл использовать JEE — любая музыка за ваши деньги. Хотите дорого и плохо, без нормальных тестов и всех этих «модных» штучек — ради бога.
1. У дяди есть миллиард
2. Он уперт и ограничен. Не понимает процессов автоматизации. Любит покупать красивые и дорогие штучки из линии Websphere и подобных.
В этом случае имеет смысл использовать JEE — любая музыка за ваши деньги. Хотите дорого и плохо, без нормальных тестов и всех этих «модных» штучек — ради бога.
Слушайте, ну не надо утрировать. Я вам могу еще раз повторить — у меня было с десяток вполне успешных проектов сравнительно разного размера, и нигде, повторяю — нигде выбор JavaEE не был основан на том, что дядя купил Weblogic. Его выбрали разработчики. А поскольку проекты были успешные — то выбор был правилен.
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.
Основное правило при выборе инструментов — выбирать то, чем владеешь. Если JEE всем устраивает, то вполне себе рабочее решение. В моем случае всегда было наоборот — клиент требовал Weblogic или Websphere потому, что у них типа партнерские соглашения с поставщиками. Причем детали реализации их не интересовали, главное чтоб присутствовал сервер. В итоге для реализации требуемого функционала пришлось поразрабатывать велосипедов, где JEE больше мешал, чем помогал.
Очень спас ситуацию проект OpenEJB, который позволил поднять локальный тестовый воркбенч. Контейнер программно конфигурируется, позволяет подменять дескрипторы, шустро запускается в embedded режиме с готовым classpath проекта, есть функционал для unit-тестирования. Рекомендую.
Очень спас ситуацию проект OpenEJB, который позволил поднять локальный тестовый воркбенч. Контейнер программно конфигурируется, позволяет подменять дескрипторы, шустро запускается в embedded режиме с готовым classpath проекта, есть функционал для unit-тестирования. Рекомендую.
>к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.
>И это работает! А 95% людей, услышав слово webservice, полезли бы в JEE.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
>Ваши аргументы сводятся к вашему личному опыту сравнения с решениями, написанными по-ходу неквалифицированными программистами. И Вы делаете вывод, что виновато отсутствие JEE. Отчасти, конечно, Вы правы.
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
J2ME не хватает в голосовании.
Java EE 8 уже кем-то поддерживается? неплохо. что за сервер?
Интересно, мы доживем до момента, когда люди перестанут голосовать за вариант «Java <5» и его можно будет выкинуть из подобных опросов…
Я думаю, что эти пять человек просто промахнулись
Соседние варианты не настолько популярные, чтобы мимо них промахнулись 5 человек.
Может, конечно, просто шутники.
Ждем реального пользователя Java 1.4 в комментариях :)
Может, конечно, просто шутники.
Ждем реального пользователя Java 1.4 в комментариях :)
Я сиду на поддержке одного проекта и там JAVA 1.4-1.5(тестовый сервак на 1.4, oracle application server, на боевом 1,5 но все написано под 1.4). Деньги платят за поддержку, переписывать никто не собирается. Работает все это крайне медленно и мало кто уже знает как.
Java 1.1, JDK 1.4
Но я больше саму виртуалку (J2ME based) ковыряю.
Но я больше саму виртуалку (J2ME based) ковыряю.
А если использую тестовый фреймворк на Groovy, в голосовалке считать что я использую Groovy?
Да
Тогда всем, кто использует, например, Gradle (локально или на Jenkins) или другие DSL на Groovy, тоже следует отвечать «Да».
Давайте проведем границу по .gradle vs .groovy
Вы автор, вам и решать.
Однако Gradle без Groovy не работает => использование Gradle автоматически означает использование Groovy.
Однако Gradle без Groovy не работает => использование Gradle автоматически означает использование Groovy.
Ну таким макаром мы все используем Си, потому что все основные ОС написаны на Си.
Можно использовать Gradle в формате dsl блоков и практически не знать синтаксиса Groovy, и уж совсем ничего не знать про стандартную библиотеку, приемы и т. д.
Давайте считать код основного проекта и код, который зависит от кода основного проекта в runtime, т. е. тесты — да, (билд) скрипты — нет
Можно использовать Gradle в формате dsl блоков и практически не знать синтаксиса Groovy, и уж совсем ничего не знать про стандартную библиотеку, приемы и т. д.
Давайте считать код основного проекта и код, который зависит от кода основного проекта в runtime, т. е. тесты — да, (билд) скрипты — нет
неужто Spock?
> Используется ли Scala в вашей компании?
> 65% (371) Нет, и не собираемся пробовать
Это печально.
> 65% (371) Нет, и не собираемся пробовать
Это печально.
Согласен, меня тоже расстроило, видимо введение «лямбд» в джаву подуспокоило людей и они перестали искать альтернативы.
И это при том, что Scala-коммюнити в СНГ одно из самых активных.
И это при том, что Scala-коммюнити в СНГ одно из самых активных.
Все верно. Код на Java понятен и мартышке. Код на Scala становится понятным только после серьезного опыта и то надо иметь архитектора который молодым обфускатрам по рукам стучать будет. Со сборкой в разы геммора больше. И ради чего? Все ради чего я в свое время в скалу погрузился есть и в современной яве.
Какой гемморой со сборкой?
sbt — одна из самых простых систем управления сборкой в мире JVM, проще только lein.
sbt — одна из самых простых систем управления сборкой в мире JVM, проще только lein.
sbt то простой? у меня после него сложилось чувство что даже mvn проще. но я не про него, хоть эта зараза попила крови поначалу изрядно. Я про все библиотеки которые собираются под конкретную версию скалы.
у sbt одна из самых простых *идей управления сборкой*
А вот реализация… вырвиглазный DSL, отсутствие качественной документации, для любых нетривиальных вещей надо идти смотреть исходники. А исходники написаны на идеоматической (считай, нечитаемой) скале с минимумом комментариев. А так да, сбт я люблю…
А вот реализация… вырвиглазный DSL, отсутствие качественной документации, для любых нетривиальных вещей надо идти смотреть исходники. А исходники написаны на идеоматической (считай, нечитаемой) скале с минимумом комментариев. А так да, сбт я люблю…
Изучать новую систему сборки ради «почти такого же» языка желающих мало, особенно в промышленной сфере. Есть Maven, появляется Gradle. Scala даже первый плохо поддерживает (ломается anootation processing, например, если собирать scala-plugin'ом все).
gradle вроде как давно уже появился и в отличии от maven активно развивается.
Гм. Вот знаете, у нас в соседнем проекте оказывается собирали все maven второй версии. Я уже забыл, когда у меня он был, лет семь наверное прошло с тех пор. При этом оно а) работает б) с тем же репозиторием в) разницы в pom.xml нет никакой. Инструменту 10 лет, он используется, и все довольны.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.
Ну, надо сказать, что большинство таких коммитов состоят ровно из трех строк: обновлении номера версии в декларации враппера, grade-wrapper.properties, и таймстемпа. Просто для того, чтобы если кто-то пришел свеженький в разработку, скачал последний gradle и ваш проект, он бы не стал тут же тянуть бинарник старой версии, потому что она указана во враппере.
Хотя вот я долго не занимался одним проектом, который был на Gradle 2.0, недавно решил обновиться на 2.12, но не получилось, потому что они удалили какую-то функциональность, которой я пользовался. Вот этого я не понимаю.
Хотя вот я долго не занимался одним проектом, который был на Gradle 2.0, недавно решил обновиться на 2.12, но не получилось, потому что они удалили какую-то функциональность, которой я пользовался. Вот этого я не понимаю.
Я не говорю что maven плохой, а gradle хороший. Каждый более хорош в чём то своём. Maven, как уже было сказано, стабильный и тд. и тп., gradle более гибкий, постоянно развивается. В пользу gradle могу сказать что проект с ant перевести на gradle намного проще чем на maven.
Ну, с ant проще перевести на что угодно. Реальные проблемы в сборке обычно начинаются тогда, когда у нас в проекте кучка зависимостей, как внешних, так и внутренних, которые обновляются время от времени, и надо следить за их версиями, их совместимостью и т.п.
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).
Gradle отлично поддерживает Scala, плагин весьма удобен, плюс существуют разные плагины типо gradle-scalatest для облегчения задач
Gradle даже себя нормально поддержать не может: каждые несколько версий какое-нибудь API ломают, и какие-нибудь плагины начинают отваливаться. Я пользуюсь им на работе — медлительный бегемот. Maven может собрать и задеплоить EAR быстрее, чем Gradle проинициализируется.
Я не использовал Gradle именно для Scala, так что мне интересно, как там обстят дела с:
1) Кросс-сборкой с Java: могу я использовать классы из Java в Scala в рамках одного проекта? А наоборот? Насколько сложно это конфигурится?
2) Если первый пункт работает, применяются ли в ходе него annotation processor'ы? Lombok там, или hibernate-modelgen?
3) Умеет эта штука понимать, что для появления Account_, указанного в импорте, в файлах, нужно собрать соответствующую Entity и скормить ее ModelGen'у?
Я не использовал Gradle именно для Scala, так что мне интересно, как там обстят дела с:
1) Кросс-сборкой с Java: могу я использовать классы из Java в Scala в рамках одного проекта? А наоборот? Насколько сложно это конфигурится?
2) Если первый пункт работает, применяются ли в ходе него annotation processor'ы? Lombok там, или hibernate-modelgen?
3) Умеет эта штука понимать, что для появления Account_, указанного в импорте, в файлах, нужно собрать соответствующую Entity и скормить ее ModelGen'у?
Когда-то Россия славилась хорошим уровнем технического образования. Похоже, эти времена прошли, сейчас инженеры выбирают не что лучше, а что проще и более знакомо.
Хуже. Сначала всё замечательно. Потом оказывается что бибилиотека «бла» для скалы больше не поддерживается, и приходится искать что-нибудь на замену, и а замена не совместима с другой библиотекой и пр. В результате получается лучше плюнуть и переписать всё обратно на жабу, чем пытаться прикручивать костыли (которые всё равно на джаве) :(
Это закономерно. Делал проект на ней, довел до конца, но повторять желания нет. Возможности и синтаксис — это хорошо, но есть огромные проблемы с поддержкой в IDE (поддерживает ее более-менее нормально из гигантов только проприетарная IDEA), проблемы с кросс-сборкой с Java (annotation processing ломается, постоянно «теряются» классы при чистой сборке), периодические «глупые» баги (Jsoup не работает в ней от слова «совсем»).
С точки зрения «шашечек» Scala хороша, но с точки зрения «ехать» там работ непочатый край. Она субъективно опережает остальные JVM-языки (помню как Groovy мне NullObject возвращал из инициализатора Map — можно сразу в продакшон), но все еще сильно отстает от Java.
С точки зрения «шашечек» Scala хороша, но с точки зрения «ехать» там работ непочатый край. Она субъективно опережает остальные JVM-языки (помню как Groovy мне NullObject возвращал из инициализатора Map — можно сразу в продакшон), но все еще сильно отстает от Java.
Использую gradle, считать ли что используем groovy?
Нет
А как посмотреть результаты голосования?
Мне интересно, все те люди которые в опросе «Используется ли Kotlin в вашей компании?» ответили «Нет, и не собираемся пробовать» не знают что такое Котлин, или у них какие-то объективные причины? Потому что из всех JVM языков, Котлин единственный который может конкурировать с Java.
Полагаю, народ уже насмотрелся на этих «убийц Java». Каждый год новый супер-язык, который решает все проблемы: Ceylon, Gosu, теперь вот Kotlin. Маленький, но гордый язык, поддерживаемый только одной полупроприетарной IDE за 150 баксов в год. Одного энтузиазма и собственной IDE недостаточно, чтобы победить монстра, которого «3 billion devices run».
Jtalk Конечно открытой IDE и плагина для эклипса недостаточно чтобы победить Java, именно поэтому в котлине решена «billion-dollar mistake», идеальный интероп с джавой. Рантайм очень маленький(6К методово, 500кб) и скорость кода на Котлине зачастую превосходит джава код, и при этом глаза не обязаны фильтровать тонны мусора. Время компилиции такое-же как у Java, идеальная поддержка в той же открытой IDE(Intellij Idea Community Edition, Android Studio).
Scala — тормозит в IDE и при сборке проекта, не интерабельна с джавой (в обе стороны) и имеет слишком богатую библиотеку.
Groovy — заслужил звания языка с пазлерами, и в первую очередь для многих это динамический язык со всеми вытекающими.
Gosu, Phantom — очевидно эти языки изначально были мертворожденными, за ними никто не стоит их никто не продвигает.
Ceylon — хорошая попытка, действительно интересный язык… Но он напоминает Scala со своими наваторскими идеями и задвигает интероп с Java на второй план.
Итого получается что Kotlin это тот язык который имеет смысл тянуть в существующий проект, использовать его бок обок с написанным Java кодом, при этом это современный язык, с высокими гарантиями безопасности(smart-casts,NPE-free code) и умным компилятором.
Так какие объективные причины не взлететь Kotlin?
Scala — тормозит в IDE и при сборке проекта, не интерабельна с джавой (в обе стороны) и имеет слишком богатую библиотеку.
Groovy — заслужил звания языка с пазлерами, и в первую очередь для многих это динамический язык со всеми вытекающими.
Gosu, Phantom — очевидно эти языки изначально были мертворожденными, за ними никто не стоит их никто не продвигает.
Ceylon — хорошая попытка, действительно интересный язык… Но он напоминает Scala со своими наваторскими идеями и задвигает интероп с Java на второй план.
Итого получается что Kotlin это тот язык который имеет смысл тянуть в существующий проект, использовать его бок обок с написанным Java кодом, при этом это современный язык, с высокими гарантиями безопасности(smart-casts,NPE-free code) и умным компилятором.
Так какие объективные причины не взлететь Kotlin?
скорость кода на Котлине зачастую превосходит джава кодА вот про это поподробнее, пожалуйста.
Вряд ли кто-то делал вменяемые измерения, но разработчики часто упоминают инлайн-функции, как фактор ускорения.
Там где в Java вы бы использовали Optional, вы не используете ничего, когда у вас есть маленькая вспомогательная функция — вы её инлайните. Думаю больше о производительности будет рассказано тут: http://javapoint.ru/talks/jemerov/
А как inline будет сочетаться с override? Что увидит Java при попытке отнаследоваться от объекта с inline функцией вместо этой функции? Если функция там все-таки будет — это ахтунг: загружаем наследника, меняем в IoC-контейнере реализацию на наследника, и получаем так любимое C++-программистами UB: в тех классах, где был inline, получаем старое поведение. Если функции не будет, то ничего не сломается, но и пользоваться этой возможностью не будет никто: в мире промышленной разработки ситуация, когда часть твоих методов пропадает после компиляции, это не очень здорово.
Также интересно, как все эти штуки будут работать с проксированием: аспекты, CGLIB и вот это все. Spring и Java EE построены на этих технологиях, а inline либо не будет с ними работать совсем, либо их сломает.
JIT уже делает inlining, только делает это с полным представлением о происходящем внутри JVM и может быстро реагировать на «нежданчики»: загрузку новых классов, изменение байткода через javassist и прочие вот такие вот полезные вещи, которыми напичканы множество промышленных проектов.
Также интересно, как все эти штуки будут работать с проксированием: аспекты, CGLIB и вот это все. Spring и Java EE построены на этих технологиях, а inline либо не будет с ними работать совсем, либо их сломает.
JIT уже делает inlining, только делает это с полным представлением о происходящем внутри JVM и может быстро реагировать на «нежданчики»: загрузку новых классов, изменение байткода через javassist и прочие вот такие вот полезные вещи, которыми напичканы множество промышленных проектов.
Достаточно было прочитать первое предложение из доки, чтобы не писать столько бессмысленных вопросов: https://kotlinlang.org/docs/reference/inline-functions.html
> JIT уже делает inlining
Только когда глубина стека меньше 10, а в современных веб приложениях это примерно никогда.
Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
> JIT уже делает inlining
Только когда глубина стека меньше 10, а в современных веб приложениях это примерно никогда.
Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
Так, прочитал, понял что все эти функции — объекты. Какое предложение нужно прочитать, чтобы понять, как это будет выглядеть из Java в «идеальном interop»?
> Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
Android — это своя атмосфера с протухшей виртуальной машиной. Тем не менее, утверждение звучит сомнительно. Есть какая-то статистика массового перехода приложений в _production_ на Kotlin с других языков?
> Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
Android — это своя атмосфера с протухшей виртуальной машиной. Тем не менее, утверждение звучит сомнительно. Есть какая-то статистика массового перехода приложений в _production_ на Kotlin с других языков?
Я недавно попробовал писать на Kotlin, язык не без шероховатостей, тулинг и поддержка IDE пока заметно отстает (от той же джавовской в той же Idea, как ни парадоксально), полнота документации оставляет желать лучшего. Хотя, думается, в 1996 году Java представляла из себя гораздо более печальное зрелище.
А можно больше конкретики?
В кратце по языку — мне не нравится запись типов справа от переменных, companion objects это шиза (по всей видимости чтобы подружиться с js бекендом), которая мешает нормально структурировать код, много относительно случайных (по синтаксису) фишечек, которые выглядят как попытка заткнуть конкретные дырки, и несогласованно с общим дизайном: field, My::class, lateinit,
По тулингу и документации: просто попробуйте и поймете
Что значит «попробуйте и поймете»? Я пишу на Котлин каждый день и не вижу проблем ни с туллингом ни с документацией.
Я за день использования зафайлил два бага (в идее), еще один не зафайлил, многие вещи работают через раз почему-то, хотя с Java такой "нестабильности" инспекций никогда не было.
По документации нет поиска, нет индекса, нет "use" как в Javadoc. Навигация по доке kotlin.collections и попытка там что-то найти — то еще удовольствие.
Скудность документации вещь субъективная, но имхо референс должен быть раза в полтора больше (т. е. подробнее)
> Я за день использования зафайлил два бага (в идее), еще один не зафайлил, многие вещи работают через раз почему-то, хотя с Java такой «нестабильности» инспекций никогда не было.
Баги в идеи у меня сыплются и без Kotlin, так же как они сыплются у меня в WebStorm.
> По документации нет поиска, нет индекса, нет «use» как в Javadoc. Навигация по доке kotlin.collections и попытка там что-то найти — то еще удовольствие.
site:kotlinlang.org bla-bla? pdf?
В целом действительно, плагин отваливался в RC, потом починили. Теперь с каждым днем становится только стабильнее. Проблем с навигацией, инспекциями и подстветкой никогда не имел. Если сейчас взять груви или скалу, то Котлин плагин выглядит куда более зрелым. Прямо сейчас у парней сломалась подстветка груви в спок тестах, причем как в стабильной версии так и в eap.
Баги в идеи у меня сыплются и без Kotlin, так же как они сыплются у меня в WebStorm.
> По документации нет поиска, нет индекса, нет «use» как в Javadoc. Навигация по доке kotlin.collections и попытка там что-то найти — то еще удовольствие.
site:kotlinlang.org bla-bla? pdf?
В целом действительно, плагин отваливался в RC, потом починили. Теперь с каждым днем становится только стабильнее. Проблем с навигацией, инспекциями и подстветкой никогда не имел. Если сейчас взять груви или скалу, то Котлин плагин выглядит куда более зрелым. Прямо сейчас у парней сломалась подстветка груви в спок тестах, причем как в стабильной версии так и в eap.
Я сравниваю с Java
> хотя с Java такой «нестабильности» инспекций никогда не было
была, после выхода java 8 инспекции могли подсвечивать правильный java 8 код, хотя поддержка джавы 8 была объявлена :) это так, почему-то вспомнил
Если сравнивать с Java, то да, десятилетием разрабаттываемая поддержка джава действительно выглядит серьезнее и в ней меньше багов (хотя случаются)
Но мой поинт был именно в том, что среди других альтернативных JVM языков, Kotlin имеет действительно хороший тулинг с рождения.
была, после выхода java 8 инспекции могли подсвечивать правильный java 8 код, хотя поддержка джавы 8 была объявлена :) это так, почему-то вспомнил
Если сравнивать с Java, то да, десятилетием разрабаттываемая поддержка джава действительно выглядит серьезнее и в ней меньше багов (хотя случаются)
Но мой поинт был именно в том, что среди других альтернативных JVM языков, Kotlin имеет действительно хороший тулинг с рождения.
Статические методы отлично заменяются higher-order functions и extension functions, как еще может мешать отсутсвие статических методов?
> в котлине решена «billion-dollar mistake»
Давайте будем честными: не решена она, это просто маркетинг. Я смотрел презентацию JB по нему и видел этот пункт. Это меня заинтересовало, и я решил посмотреть, как оно все-таки «надежно решено». А решение по сути сводится к тому, что вместо монады Option из Scala сделан синтаксический сахар. Java-код ведь не дает никаких гарантий относительно возврата NULL, поэтому все вызовы внешнего кода, которого в Java, кстати, очень много, придется оборачивать проверками. Сделали conditional dereference — круто, но это просто синтаксический сахар над Optional.map (Java) или Option.map (Scala). В этом нет никакого новаторства, это решение «billion-dollar mistake» можно найти в любом JVM языке. Хотите посмотреть, как такая проблема решается на самом деле? Добро пожаловать в Haskell!
> не интерабельна с джавой
Можно примеры? Scala с Java нормально кооперируются, даже EJB-контейнеры спокойно жуют Scala-классы. Проблемы там только со сборкой: плагины кривые (выше я описывал), но вряд ли kotlin-maven-plugin умеет вызывать процессоры и детектить JPA Modelgen. Еще есть баг с Jsoup, но я не думаю, что Kotlin безошибочно работает со всеми километрами байткода из Maven Central.
> и при этом глаза не обязаны фильтровать тонны мусора
Попробуйте Lombok. Серьезно. Мир Java уже совсем не таков, каким был 10 лет назад.
> идеальная поддержка в той же открытой IDE(Intellij Idea Community Edition, Android Studio)
IDE от создателей языка, да. У NetBeans и Eclipse есть собственные крупные сообщества. Говорить всем «Я изобрел таблетку от всех болезней, но чтобы ее получить вы должны заплатить JetBrains 150 баксов» — это не самый лучший способ сместить старушку Java с пьедестала. Community довольно хиленькая: для мелких проектов пойдет, но когда появляется десяток XML-конфигураций со ссылками на классы, а к ним еще сотня JSF-страниц, «ручная» работа в Community превращается в пытку. JetBrains думает, что выпустив Kotlin сможет создать vendor-lock на свою платформу и доить клиентов, видимо, но вряд ли это сработает.
Давайте будем честными: не решена она, это просто маркетинг. Я смотрел презентацию JB по нему и видел этот пункт. Это меня заинтересовало, и я решил посмотреть, как оно все-таки «надежно решено». А решение по сути сводится к тому, что вместо монады Option из Scala сделан синтаксический сахар. Java-код ведь не дает никаких гарантий относительно возврата NULL, поэтому все вызовы внешнего кода, которого в Java, кстати, очень много, придется оборачивать проверками. Сделали conditional dereference — круто, но это просто синтаксический сахар над Optional.map (Java) или Option.map (Scala). В этом нет никакого новаторства, это решение «billion-dollar mistake» можно найти в любом JVM языке. Хотите посмотреть, как такая проблема решается на самом деле? Добро пожаловать в Haskell!
> не интерабельна с джавой
Можно примеры? Scala с Java нормально кооперируются, даже EJB-контейнеры спокойно жуют Scala-классы. Проблемы там только со сборкой: плагины кривые (выше я описывал), но вряд ли kotlin-maven-plugin умеет вызывать процессоры и детектить JPA Modelgen. Еще есть баг с Jsoup, но я не думаю, что Kotlin безошибочно работает со всеми километрами байткода из Maven Central.
> и при этом глаза не обязаны фильтровать тонны мусора
Попробуйте Lombok. Серьезно. Мир Java уже совсем не таков, каким был 10 лет назад.
> идеальная поддержка в той же открытой IDE(Intellij Idea Community Edition, Android Studio)
IDE от создателей языка, да. У NetBeans и Eclipse есть собственные крупные сообщества. Говорить всем «Я изобрел таблетку от всех болезней, но чтобы ее получить вы должны заплатить JetBrains 150 баксов» — это не самый лучший способ сместить старушку Java с пьедестала. Community довольно хиленькая: для мелких проектов пойдет, но когда появляется десяток XML-конфигураций со ссылками на классы, а к ним еще сотня JSF-страниц, «ручная» работа в Community превращается в пытку. JetBrains думает, что выпустив Kotlin сможет создать vendor-lock на свою платформу и доить клиентов, видимо, но вряд ли это сработает.
А решение по сути сводится к тому, что вместо монады Option из Scala сделан синтаксический сахар.
Да, и это очень правильно. Потому что от verbosity того же Optional в Java 8, которую понапихали в новые классы, сводит скулы. Что характерно, кроме самих авторов JDK эту Optional никто не использует. Проще на null проверить, чем приседать с Optional.
Попробуйте Lombok. Серьезно. Мир Java уже совсем не таков, каким был 10 лет назад.
Который заточен под Eclipse, ага. Вместо лок-ина на Идею получаем лок-ин на Эклипс.
Я изобрел таблетку от всех болезней, но чтобы ее получить вы должны заплатить JetBrains 150 баксов
Idea CE и Android Studio бесплатны.
> Что характерно, кроме самих авторов JDK эту Optional никто не использует.
Это неправда, мы используем во всех проектах, которые перевели на Java 8. Это позволяет писать более чистые и самодокументирующиеся API. Заворачивать каждый вызов каждой функции в if (result == null) никаких пальцев не напасешься.
> Который заточен под Eclipse, ага.
Это неправда, в NetBeans нативная поддержка, в IDEA плагином.
> Idea CE и Android Studio бесплатны.
Предложение, следующее за тем, которое вы прокомментировали, как раз посвящено CE, почему вы его проигнорировали?
Это неправда, мы используем во всех проектах, которые перевели на Java 8. Это позволяет писать более чистые и самодокументирующиеся API. Заворачивать каждый вызов каждой функции в if (result == null) никаких пальцев не напасешься.
> Который заточен под Eclipse, ага.
Это неправда, в NetBeans нативная поддержка, в IDEA плагином.
> Idea CE и Android Studio бесплатны.
Предложение, следующее за тем, которое вы прокомментировали, как раз посвящено CE, почему вы его проигнорировали?
Optional безопаснее, спору нет, но чтобы писать
Optional[T] result = ...;
if (result.is present())
use(result.get());
Надо еще сильно больше пальцев. map() же имхо затрудняет понимание кода (я люблю Хаскель, но претензии на мат. абстракции в Java выглядят неуместно), создает лямбду что еще снижает шансы на scalar replacement всей этой колбасы, и не избавляет от Optional, с которым в конце концов придется что-то делать.
У любой относительно нишевой надстройки над Java, в идеальной поддержке которой не заинтересованы вендоры IDE, по определению поддержка будет лучше в той среде, в которой сидят создатели надстройки. А плагины к другим работать будут по остаточному принципу. Для Котлина тоже есть Эклипс-плагин, тем не менее я не спорю, что Котлин это лок-ин на Идею.
Насчет CE — зависит от задач. Если это не Энтерпрайза/веб, ультимейт не нужна.
Я, в принципе, согласен, что Optional довольно громоздок. Вопрос тут только в балансе: стоит ли вводить в проект новый язык с неясными перспективами и потенциальным вендорлоком ради этого сахара?
Ну и в общем-то неудачно немного у JB совпало: ввели подписочную модель принудительно, чем разозлили часть сообщества, а потом выкатили Kotlin. После первого народ быстро понял, что JetBrains — это не улыбающиеся дяденьки, которые переводят старушек через дорогу, а простой бизнес, конечная цель которого — зарабатывание денег. Повод дважды подумать насчет баланса и «неясных перспектив».
Ну и в общем-то неудачно немного у JB совпало: ввели подписочную модель принудительно, чем разозлили часть сообщества, а потом выкатили Kotlin. После первого народ быстро понял, что JetBrains — это не улыбающиеся дяденьки, которые переводят старушек через дорогу, а простой бизнес, конечная цель которого — зарабатывание денег. Повод дважды подумать насчет баланса и «неясных перспектив».
> Сделали conditional dereference — круто, но это просто синтаксический сахар над Optional.map (Java) или Option.map (Scala).
Вы всё напутали, это всё compile-time проверки, с соответствующим (то есть нулевым) влиянием на перформанс. Это первый язык на JVM который так _решил_ проблему Null. Именно решил, а не создал поверх кривой слой абстракции с runtime-penalty и назвал его Optional.
> Java-код ведь не дает никаких гарантий относительно возврата NULL.
Всё так, именно поэтому Котлин автоматически расставляет nonNull проверки на границе с Java кодом. А также обращает внимание на аннотации @Nullable/@Notnull
> Scala с Java нормально кооперируются, даже EJB-контейнеры спокойно жуют Scala-классы.
Со scala-lang.org:
Accessing Java classes from Scala code is no problem at all. Using a Scala class from Java can get tricky, in particular if your Scala class uses advanced features like generics, polymorphic methods, or abstract types.
По факту когда ты просто пишешь код на скале, а потом просто пытаешься вызвать его из Java получается куча странных имен и долларов в коде, но так и надо конечно, никаких проблем.
> Попробуйте Lombok
Летали, знаем, закапайте стюардессу.
> JetBrains думает, что выпустив Kotlin сможет создать vendor-lock на свою платформу и доить клиентов, видимо, но вряд ли это сработает.
Нужно больше конспиративных теорий! Еще раз, есть плагин для Eclipse, нравится Eclipse? Пользуйтесь им, в чем проблема. Также сообщество сделала подсветку в Sublime/Atom, возможно уже есть vim плагин.
> но когда появляется десяток XML-конфигураций со ссылками на классы, а к ним еще сотня JSF-страниц
На дворе вроде 2016, Spring-Boot без XML, REST и Angular.
Вы всё напутали, это всё compile-time проверки, с соответствующим (то есть нулевым) влиянием на перформанс. Это первый язык на JVM который так _решил_ проблему Null. Именно решил, а не создал поверх кривой слой абстракции с runtime-penalty и назвал его Optional.
> Java-код ведь не дает никаких гарантий относительно возврата NULL.
Всё так, именно поэтому Котлин автоматически расставляет nonNull проверки на границе с Java кодом. А также обращает внимание на аннотации @Nullable/@Notnull
> Scala с Java нормально кооперируются, даже EJB-контейнеры спокойно жуют Scala-классы.
Со scala-lang.org:
Accessing Java classes from Scala code is no problem at all. Using a Scala class from Java can get tricky, in particular if your Scala class uses advanced features like generics, polymorphic methods, or abstract types.
По факту когда ты просто пишешь код на скале, а потом просто пытаешься вызвать его из Java получается куча странных имен и долларов в коде, но так и надо конечно, никаких проблем.
> Попробуйте Lombok
Летали, знаем, закапайте стюардессу.
> JetBrains думает, что выпустив Kotlin сможет создать vendor-lock на свою платформу и доить клиентов, видимо, но вряд ли это сработает.
Нужно больше конспиративных теорий! Еще раз, есть плагин для Eclipse, нравится Eclipse? Пользуйтесь им, в чем проблема. Также сообщество сделала подсветку в Sublime/Atom, возможно уже есть vim плагин.
> но когда появляется десяток XML-конфигураций со ссылками на классы, а к ним еще сотня JSF-страниц
На дворе вроде 2016, Spring-Boot без XML, REST и Angular.
> Вы всё напутали, это всё compile-time проверки, с соответствующим (то есть нулевым) влиянием на перформанс. Это первый язык на JVM который так _решил_ проблему Null. Именно решил, а не создал поверх кривой слой абстракции с runtime-penalty и назвал его Optional.
Допустим, я вам верю, хотя это не так. Как именно будут происходить compile-time проверки для результатов вызова Java-методов из внешних библиотек? Kotlin вводит для них понятие nullable-типа, т.е. делает инверсию: non-nullable типы становятся «по умолчанию», а nullable требуют специального обращения. И все nullable проходят все необходимые проверки, причем в runtime, потому что иначе все в рантайме просто развалится: в Java нельзя полагаться на результаты анализа внешних библиотек, в runtime может быть совершенно другой JAR с совершенно другой реализацией указанных интерфейсов. ManagedExecutorService и вот это все. В результате string? a = someFunc(); Type? b = a?.someMethod();, и все это в runtime будет полностью аналогично Option(someFunc()).map(_.someMethod). Такой же «кривой слой абстракции с runtime-penalty», как Option, только в профиль. Если очень прям так хотелось этого, можно было патч для javac написать, или annotation processor какой-нибудь, чтобы проверял наличие Optional в nullable-типах, а не аж целый язык изобретать.
> Нужно больше конспиративных теорий!
Это не конспиративная теория, это бизнес. Точно так же Microsoft добавляет поддержку Linux повсюду не потому что уверовал в идеалы Free Software, и собирается выбросить виндовс и закружиться со Столлманом в радостном танце. Коммерческие компании не занимаются благотворительностью, они занимаются маркетингом, и Kotlin сделан чтобы заработать больше денег, а не чтобы сделать Java-программистов счастливыми и улыбающимися. Это не «плохо», это «реальность».
> На дворе вроде 2016, Spring-Boot без XML, REST и Angular.
Spring Boot-то тут при чем? Это подсистема для автоматического конфигурирования сервисов при старте на основе сканирования classpath. Вы, наверное, имели в виду Spring JavaConfig? У JavaConfig есть проблемы определенные: из-за того, что контексты с разными источниками (Java, XML) не могут быть «объединены», они выстраиваются в иерархию, и с ними начинается та же пляска, что и с класслоадерами — конфиг-источник не может быть перегружен конфигом-наследником. Если вы импортируете XML-конфигурацию в своем проекте из стороннего компонента, а потом захотите подменить одну из реализаций в ее контексте, сделать это можно будет только в XML. C'est la vie, XML никуда не собирается так уж прям пропадать.
REST и Angular — дольше в разработе, требуют отдельных разработчиков на фронт и бэк, требуют согласования API для REST-сервиса. Пока вы будете собирать консилиум ведущих умов и думать, как лучше отразить в API пару десятков свойств из пяти таблиц, да еще и, крайне желательно, без «рассогласования», я уже сделаю нужную страницу на JSF.
Допустим, я вам верю, хотя это не так. Как именно будут происходить compile-time проверки для результатов вызова Java-методов из внешних библиотек? Kotlin вводит для них понятие nullable-типа, т.е. делает инверсию: non-nullable типы становятся «по умолчанию», а nullable требуют специального обращения. И все nullable проходят все необходимые проверки, причем в runtime, потому что иначе все в рантайме просто развалится: в Java нельзя полагаться на результаты анализа внешних библиотек, в runtime может быть совершенно другой JAR с совершенно другой реализацией указанных интерфейсов. ManagedExecutorService и вот это все. В результате string? a = someFunc(); Type? b = a?.someMethod();, и все это в runtime будет полностью аналогично Option(someFunc()).map(_.someMethod). Такой же «кривой слой абстракции с runtime-penalty», как Option, только в профиль. Если очень прям так хотелось этого, можно было патч для javac написать, или annotation processor какой-нибудь, чтобы проверял наличие Optional в nullable-типах, а не аж целый язык изобретать.
> Нужно больше конспиративных теорий!
Это не конспиративная теория, это бизнес. Точно так же Microsoft добавляет поддержку Linux повсюду не потому что уверовал в идеалы Free Software, и собирается выбросить виндовс и закружиться со Столлманом в радостном танце. Коммерческие компании не занимаются благотворительностью, они занимаются маркетингом, и Kotlin сделан чтобы заработать больше денег, а не чтобы сделать Java-программистов счастливыми и улыбающимися. Это не «плохо», это «реальность».
> На дворе вроде 2016, Spring-Boot без XML, REST и Angular.
Spring Boot-то тут при чем? Это подсистема для автоматического конфигурирования сервисов при старте на основе сканирования classpath. Вы, наверное, имели в виду Spring JavaConfig? У JavaConfig есть проблемы определенные: из-за того, что контексты с разными источниками (Java, XML) не могут быть «объединены», они выстраиваются в иерархию, и с ними начинается та же пляска, что и с класслоадерами — конфиг-источник не может быть перегружен конфигом-наследником. Если вы импортируете XML-конфигурацию в своем проекте из стороннего компонента, а потом захотите подменить одну из реализаций в ее контексте, сделать это можно будет только в XML. C'est la vie, XML никуда не собирается так уж прям пропадать.
REST и Angular — дольше в разработе, требуют отдельных разработчиков на фронт и бэк, требуют согласования API для REST-сервиса. Пока вы будете собирать консилиум ведущих умов и думать, как лучше отразить в API пару десятков свойств из пяти таблиц, да еще и, крайне желательно, без «рассогласования», я уже сделаю нужную страницу на JSF.
> Допустим, я вам верю, хотя это не так. Как именно будут происходить compile-time проверки для результатов вызова Java-методов из внешних библиотек? Kotlin вводит для них понятие nullable-типа, т.е. делает инверсию: non-nullable типы становятся «по умолчанию», а nullable требуют специального обращения. И все nullable проходят все необходимые проверки, причем в runtime, потому что иначе все в рантайме просто развалится: в Java нельзя полагаться на результаты анализа внешних библиотек, в runtime может быть совершенно другой JAR с совершенно другой реализацией указанных интерфейсов. ManagedExecutorService и вот это все. В результате string? a = someFunc(); Type? b = a?.someMethod();, и все это в runtime будет полностью аналогично Option(someFunc()).map(_.someMethod). Такой же «кривой слой абстракции с runtime-penalty», как Option, только в профиль. Если очень прям так хотелось этого, можно было патч для javac написать, или annotation processor какой-нибудь, чтобы проверял наличие Optional в nullable-типах, а не аж целый язык изобретать.
Хватит троллить, честное слово.
1. Если мы говорим про чистый Котлин без вызова Java — то там в худшем случае есть nonNull проверки в начале метода.
2. Если мы говорим про интероп Kotlin и Java, то на границе с Java создается nonNull check, что есть просто вызов функции.
Никаких объектов и if(o.isPresent()) {o.get()}.
Так что никак это не аналогично. Пожалуйста, разберитесь в субъекте, прежде чем обсуждать его.
> Это не конспиративная теория, это бизнес. Точно так же Microsoft добавляет поддержку Linux повсюду не потому что уверовал в идеалы Free Software, и собирается выбросить виндовс и закружиться со Столлманом в радостном танце. Коммерческие компании не занимаются благотворительностью, они занимаются маркетингом, и Kotlin сделан чтобы заработать больше денег, а не чтобы сделать Java-программистов счастливыми и улыбающимися. Это не «плохо», это «реальность».
А также реальность что JetBrains пишет внутри на Kotlin и делал язык в первую очередь для себя, маркетинга у них мало, в основном такое вот сарафанное радио. В отличии от M$ которые пропихивают за откаты продукцию в гос органы и в учебные заведения. Или вот, трек Kotlin на jetconf.by, как ты думаешь, сколько JetBrains заплатила за него? Ответ — 0.0$.
> Spring Boot-то тут при чем?
@EnableAutoConfiguration избавляет от большого колличества конфигураций, многое можно прямо в application.yml подхачить, а если нужен свой бин — то да, JavaConfig. Ваш легаси с XML, ну да, придется отставить XML видимо. Мои же два последних проекта были вообще без единого XML (если говорить про настройку фрэймворков).
> я уже сделаю нужную страницу на JSF
А потом это нужно поддерживать и дорабатывать, делать API для мобильного приложения и вот это все. Зато за пять минут наколенке! Кстати из последнего Technology Radar от ThoughtWorks JSF выпилили совсем, т.е. они признали технологию говном мамонта, такие дела.
Хватит троллить, честное слово.
1. Если мы говорим про чистый Котлин без вызова Java — то там в худшем случае есть nonNull проверки в начале метода.
2. Если мы говорим про интероп Kotlin и Java, то на границе с Java создается nonNull check, что есть просто вызов функции.
Никаких объектов и if(o.isPresent()) {o.get()}.
Так что никак это не аналогично. Пожалуйста, разберитесь в субъекте, прежде чем обсуждать его.
> Это не конспиративная теория, это бизнес. Точно так же Microsoft добавляет поддержку Linux повсюду не потому что уверовал в идеалы Free Software, и собирается выбросить виндовс и закружиться со Столлманом в радостном танце. Коммерческие компании не занимаются благотворительностью, они занимаются маркетингом, и Kotlin сделан чтобы заработать больше денег, а не чтобы сделать Java-программистов счастливыми и улыбающимися. Это не «плохо», это «реальность».
А также реальность что JetBrains пишет внутри на Kotlin и делал язык в первую очередь для себя, маркетинга у них мало, в основном такое вот сарафанное радио. В отличии от M$ которые пропихивают за откаты продукцию в гос органы и в учебные заведения. Или вот, трек Kotlin на jetconf.by, как ты думаешь, сколько JetBrains заплатила за него? Ответ — 0.0$.
> Spring Boot-то тут при чем?
@EnableAutoConfiguration избавляет от большого колличества конфигураций, многое можно прямо в application.yml подхачить, а если нужен свой бин — то да, JavaConfig. Ваш легаси с XML, ну да, придется отставить XML видимо. Мои же два последних проекта были вообще без единого XML (если говорить про настройку фрэймворков).
> я уже сделаю нужную страницу на JSF
А потом это нужно поддерживать и дорабатывать, делать API для мобильного приложения и вот это все. Зато за пять минут наколенке! Кстати из последнего Technology Radar от ThoughtWorks JSF выпилили совсем, т.е. они признали технологию говном мамонта, такие дела.
Какой nonNull check, о чем вы вообще?
val values = java.util.HashMap<String, String>()
val found: String = values.get(«world»)
Что произойдет во второй строчке? Не соберется оно, потому что String? != String. А если я уберу явное указание типа, то он не даст мне вызывать методы на этой штуке точкой, только «специальным оператором ?.». Это все по сути и является монадой Option. Такое ощущение, что вы этот язык вообще не видели, и только по рекламным буклетам знаете. «Разберитесь в субъекте», угу.
> многое можно прямо в application.yml подхачить
YAML проигрывает XML: его можно проверить только в runtime из-за отсутствия XSD, например.
> из последнего Technology Radar от ThoughtWorks
А что это такое?
val values = java.util.HashMap<String, String>()
val found: String = values.get(«world»)
Что произойдет во второй строчке? Не соберется оно, потому что String? != String. А если я уберу явное указание типа, то он не даст мне вызывать методы на этой штуке точкой, только «специальным оператором ?.». Это все по сути и является монадой Option. Такое ощущение, что вы этот язык вообще не видели, и только по рекламным буклетам знаете. «Разберитесь в субъекте», угу.
> многое можно прямо в application.yml подхачить
YAML проигрывает XML: его можно проверить только в runtime из-за отсутствия XSD, например.
> из последнего Technology Radar от ThoughtWorks
А что это такое?
> А если я уберу явное указание типа, то он не даст мне вызывать методы на этой штуке точкой, только «специальным оператором ?.». Это все по сути и является монадой Option.
Это по сути является тем, что вы не можете вызывать на инстансе типа T? никаких методов, пока не сделается null-check. В рантайме естественно нету никаких T? а есть только T, и боже упаси нету Optional[T]. Монадой Option тут не пахнет.
> его можно проверить только в runtime
С поддержкой IDEA это не большая проблема. Yaml это посути замена properties, но не XML
> А что это такое?
Пожалуй гугл лучше справится с этой задачей
Это по сути является тем, что вы не можете вызывать на инстансе типа T? никаких методов, пока не сделается null-check. В рантайме естественно нету никаких T? а есть только T, и боже упаси нету Optional[T]. Монадой Option тут не пахнет.
> его можно проверить только в runtime
С поддержкой IDEA это не большая проблема. Yaml это посути замена properties, но не XML
> А что это такое?
Пожалуй гугл лучше справится с этой задачей
Sign up to leave a comment.
Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE