С прошлого аналогичного опроса прошло больше года, и пришла пора его повторить и расширить.
Ретроспектива:
Какие версии Java вы используете? — 18 февраля 2015
Какие версии Java вы используете? — 14 февраля 2014
Пожалуйста, если вы вообще не используете Java, или не используете в production, как это предполагают большинство опросов ниже, нажимайте «воздержаться», чтобы не портить статистику.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (104)
Scf
13.04.2016 11:37Так много людей сидят на JavaEE? Я, честно говоря, думал, что это технология вымирает из-за своей сложности и монструозности. Как в свое время вымерла CORBA.
moldabekov
13.04.2016 11:52Да, и будут сидеть. Эта технология будет популярной, пока есть enterprise, а именно пока есть закостенелый enterprise. Увы, но это так.
grossws
13.04.2016 11:55Некоторые куски EEшного стека облагородились и стали куда приятнее. Мы, например, используем JAX-RS и чуток CDI (как legacy), хотя запускается это уже не на jboss as 7, а в embedded jetty (связка weld + resteasy).
В голосовании в отношении EE указывал "не используем".
maks1mm
13.04.2016 12:01Я думаю почти весь корпоративный сектор сидит на java EE, а их там очень много.
grossws
13.04.2016 12:06А у корпоратов часто выбора-то и нет. Если сказано, что покупная софтина за десятки миллионов работает в аппсервере под EE 5, то там будет сертифицированный аппсервер с техподдержкой, никто и не пикнет. И 1.4.2 будет, если понадобится.
С другой стороны, куча мелких соплей и верёвочек (в хорошем смысле) может работать на Java SE или, например, в tomcat'е/jetty. Сервлеты, конечно, часть EE, но столь привычная, что вроде под EE сервлеты давно никто не воспринимает.
sshikov
13.04.2016 21:17+1Часто? Я вот видел подход десятка крупнейших банков. Он бывал любой — от «используйте то, что считаете нужным, включая опенсорс» до «ваш выбор Weblogic такой-то версии». Покупной софтины требующей сервера вообще ни видел никогда — обычно сервер просто входит в ее комплект (это IBM BPM к примеру — вебсфера внутри). Покупали вообще мало — значительно больше делают сами. Выбор Java EE всегда был осознанным и своим (хотя и не всегда все с этим были согласны). А все известные попытки написать свой велосипед с транзакциями и JMS на коленке — провалились.
grossws
14.04.2016 03:36Не очень удачно выразился про сторонний софт, который требует определенного аппсервера. Вариант с комплектным аппсервером на мой взгляд в этот вариант входит. Равно как и ситуация с древними jvm, которые поставили в комплекте.
sshikov
14.04.2016 21:15Это кстати да. Отличный пример — база данных Оракла с JVM дремучей версии внутри. Не знаю, как сейчас, а раньше было. На пару версий отставали.
lpre
13.04.2016 12:28+4Крайние версии JavaEE 6 и 7 не являются такими сложными и монструозными, как прежние, а JEE Web Profile вообще прост и удобен (пример JEE 6 Web Profile: http://tomee.apache.org )
Спасибо Spring за здоровую конкуренцию :-)
Throwable
14.04.2016 20:12Она не столько сложная, сколько неюзабельная, изначально неверная и по-большому ненужная. Монолитное приложение, деплоящееся в отдельный контейнер напрочь убивает возможность и желание что-то делать. Всякие хаки типа Arquillian и Embedded OpenEJB вмеремешку со своими костылям, конечно, помогают, но не панацея от напасти.
Тем не менее, клиент один раз потративший килодоллары на JEE платформу, хочет ее амортизировать и заставляет писать под нее. В этом случае действует четкое правило при работе с клиентом. Соглашаться на проект, если выполняются оба эти пункта:
1. Клиент с баблом
2. Он дебил
Если не выполнен первый пункт, смысла связываться нет — прогорите на поддержке. Если не выполнен второй — следует вразумить клиента, что есть более стабильные способы достижения результата, и что его задача — сконцентрироваться на самой проблеме, а не на способе ее решения.sshikov
14.04.2016 21:30Ктож вас-то заставляет монолитное писать? Кстати, если в проекте нет контейнера — то с модульностью там обычно все еще хуже, чем когда он есть. А все без исключения виденные мной лично попытки заменить Java EE своим велосипедом как правило были намного хуже — впрочем, я это и сегодня живьем наблюдаю. Какой только фигни там не встретишь.
Throwable
15.04.2016 12:23+1Стандартный вопрос: а что такого особенного дает вам контейнер JEE, что нельзя сделать отдельно от него? Единственно верный ответ — JTA, ради которого все и задумывалось. Однако мало того, что в 90% случаев он попросту не нужен, даже если работа идет с разными ресурсами, то в оставшихся 10% он вреден и создает ложное ощущение надежности. А JTA креши случаются, и если обычная программа как правило знает как выбраться из такой ситуации (это предусмотрено самой логикой), то в случае JTA все глухо лежит до тех пор, пока не поднимут с постели админа, который судорожно будет рыться в интернетах на вопрос как откатить рухнувшую транзакцию в конкретном контейнере. А в мире есть всего полтора человека, которые делали это.
Кроме того, вызов сраного вебсервиса, реста или даже простого remote EJB нарушает всю JTA, т.к. вызов не координируется с remote-контейнером.
Все остальное делается лучше и проще без JEE. Отдельные части как JPA, Servlets доступны ввиде библиотек и фреймворков, к тому же есть over9000 схожих альтернатив. А микросервисная архитектура становится мейнстримом. И вроде как over9000 высоконагруженных проектов в интернетах живет и здравствует без JEE.sshikov
15.04.2016 21:54Стандартный ответ — вы обобщаете свой ограниченный опыт на всех, и делаете ошибку. Нет, не JTA вовсе. А скорее управляемость кода в целом, как при разработке, так и в эксплуатации. В самом широком смысле.
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.Throwable
18.04.2016 11:42+1Опустим презентационную часть, еще раз, что конкретно есть такого в 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=y96fZdOoeiAJtalk
18.04.2016 14:10> Опустим презентационную часть, еще раз, что конкретно есть такого в JEE, что нельзя или слишком затратно сделать без него? Все технологии доступны по отдельности.
Интеграция и стандартизация же. Да, есть отдельно Weld, отдельно Jersey, отдельно к нему можно привинтить Arjuna. Нужны CMT — иди прикручивай AspectJ. Нужна система событий? Удачи с прикручиванием этого добра и пробросом зависимостей. Нужны распределенные транзакции? Идем читать маны по Hazelcast. Разработчик забил на поддержку Hazelcast? Начинаем переписывать километры интерфейсов, которые были под него заточены. И не надо мне рассказывать, что идеальные программисты из вашего окружения сразу разрабатывают идеальные интерфейсы, позволяющие легко интегрировать технологии, которые в момент написания этих интерфейсов еще не были придуманы.
Да, бывают баги. Да, некоторые конттейнеры ведут себя по-разному. Да, Weld в Glassfish ломается на выражениях, которые жует Weld из JBoss. Но без Java EE это было бы не «более надежно», этого бы вообще не было. Ваш путь — уничтожить Enterprise-платформу и поверх нее создать новую, коммунистическую Программу, которая будет сама все делать и обо всем знать — утопичен по своей сути. Есть у вас есть время и средства разрабатывать Enterprise-стек для каждого вашего нового проекта, это здорово, но большинству нужны рабочие приложения, а не идеальные схемы распределенной микросервисной архитектуры, промазанной костылями для решения проблем, которые в JEE решаются одной аннотацией.Throwable
18.04.2016 16:57+1> Интеграция и стандартизация же.
Чего? 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.Jtalk
18.04.2016 17:44Вы путаете «идеальную интеграцию» и «хоть какую-то». Spring вообще не панацея, по своей сути это еще один Java EE сервер, только с собственными нескучными API (хоть они и пытаются в последних версиях поддерживать стандартные, например, CDI Inject). Spring Boot превращает ваш софт в Bloatware, которое возит за собой тонны ненужных вещей, заботливо им сконфигуренных, и все такое прочее. То, что Spring легче конфигурить, чем, например, Wildfly — это, вообще говоря, неправда, вопрос привычки, не более.
Я по вашим ответам уже вижу, что вы «стиляга от разработки» — TDD, code coverage, continuous integration и вот это все. Я не отрицаю ваше право заниматься всем этим. Действительно, если потребитель каждый день ждет новых смайликов с котиками на вашем сайте, все это работает. Но поймите и вы, что есть совершенно другой мир. Есть мир, где деплой не проходит без одобрения службы безопасности, и где перед тем, как вы начнете писать модульные тесты на модульные тесты микросервисов к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире. Есть мир, где модные технологии правят, а есть мир, где правят отлаженные процессы и репутация вендоров. Какой бы медлительной не была WebSphere, она и поставляемое с ней добро, вроде message broker'ов, работают на сотнях тысяч инсталляций по всему миру, и если ко мне придет дядя с миллиардом долларов, и спросит, кому лучше доверить тот самый миллиард, уродливому Oracle, или модной MongoDB, я выберу первое, пусть я и терпеть его не могу. Потому что мода — это проходящее, а путешествие в лес в багажнике редко бывает чаще раза в жизни, и это неспроста.Throwable
18.04.2016 18:23+2Ну вот мы и вернулись к изначальному тезису.
1. У дяди есть миллиард
2. Он уперт и ограничен. Не понимает процессов автоматизации. Любит покупать красивые и дорогие штучки из линии Websphere и подобных.
В этом случае имеет смысл использовать JEE — любая музыка за ваши деньги. Хотите дорого и плохо, без нормальных тестов и всех этих «модных» штучек — ради бога.sshikov
18.04.2016 19:44Слушайте, ну не надо утрировать. Я вам могу еще раз повторить — у меня было с десяток вполне успешных проектов сравнительно разного размера, и нигде, повторяю — нигде выбор JavaEE не был основан на том, что дядя купил Weblogic. Его выбрали разработчики. А поскольку проекты были успешные — то выбор был правилен.
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.Throwable
19.04.2016 15:53Основное правило при выборе инструментов — выбирать то, чем владеешь. Если JEE всем устраивает, то вполне себе рабочее решение. В моем случае всегда было наоборот — клиент требовал Weblogic или Websphere потому, что у них типа партнерские соглашения с поставщиками. Причем детали реализации их не интересовали, главное чтоб присутствовал сервер. В итоге для реализации требуемого функционала пришлось поразрабатывать велосипедов, где JEE больше мешал, чем помогал.
Очень спас ситуацию проект OpenEJB, который позволил поднять локальный тестовый воркбенч. Контейнер программно конфигурируется, позволяет подменять дескрипторы, шустро запускается в embedded режиме с готовым classpath проекта, есть функционал для unit-тестирования. Рекомендую.Jtalk
19.04.2016 16:12+1> Основное правило при выборе инструментов — выбирать то, чем владеешь
Если это так, то, с оглядкой на российское образование в сфере ИТ, идеальный проект — это очередной клон екселя на Delphi, выученном еще в школе, для бумажной бухгалтерии. Выбирать нужно то, что лучше подходит под задачу.
sshikov
18.04.2016 21:03+2>к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.
sshikov
18.04.2016 21:16>И это работает! А 95% людей, услышав слово webservice, полезли бы в JEE.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
sshikov
18.04.2016 19:48>Ваши аргументы сводятся к вашему личному опыту сравнения с решениями, написанными по-ходу неквалифицированными программистами. И Вы делаете вывод, что виновато отсутствие JEE. Отчасти, конечно, Вы правы.
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
leventov
13.04.2016 11:57+2Интересно, мы доживем до момента, когда люди перестанут голосовать за вариант «Java <5» и его можно будет выкинуть из подобных опросов…
Scf
13.04.2016 12:01Я думаю, что эти пять человек просто промахнулись
leventov
13.04.2016 12:04Соседние варианты не настолько популярные, чтобы мимо них промахнулись 5 человек.
Может, конечно, просто шутники.
Ждем реального пользователя Java 1.4 в комментариях :)
Shatun
13.04.2016 15:34+4Я сиду на поддержке одного проекта и там JAVA 1.4-1.5(тестовый сервак на 1.4, oracle application server, на боевом 1,5 но все написано под 1.4). Деньги платят за поддержку, переписывать никто не собирается. Работает все это крайне медленно и мало кто уже знает как.
SuicideBlonde
13.04.2016 12:09А если использую тестовый фреймворк на Groovy, в голосовалке считать что я использую Groovy?
leventov
13.04.2016 12:43Да
lpre
13.04.2016 13:42Тогда всем, кто использует, например, Gradle (локально или на Jenkins) или другие DSL на Groovy, тоже следует отвечать «Да».
leventov
13.04.2016 13:59Давайте проведем границу по .gradle vs .groovy
lpre
13.04.2016 14:21Вы автор, вам и решать.
Однако Gradle без Groovy не работает => использование Gradle автоматически означает использование Groovy.leventov
13.04.2016 14:30+1Ну таким макаром мы все используем Си, потому что все основные ОС написаны на Си.
Можно использовать Gradle в формате dsl блоков и практически не знать синтаксиса Groovy, и уж совсем ничего не знать про стандартную библиотеку, приемы и т. д.
Давайте считать код основного проекта и код, который зависит от кода основного проекта в runtime, т. е. тесты — да, (билд) скрипты — нет
Lure_of_Chaos
13.04.2016 13:07неужто Spock?
Scf
13.04.2016 13:11SpockFramework офигенен. Мне пришлось с него слезть только из-за перехода на Scala. Ну и из-за непонятного будущего самого языка — groovy-eclipse-plugin, например, уже мертв.
slava_k
13.04.2016 13:56> Используется ли Scala в вашей компании?
> 65% (371) Нет, и не собираемся пробовать
Это печально.
Vanger13
13.04.2016 14:18Согласен, меня тоже расстроило, видимо введение «лямбд» в джаву подуспокоило людей и они перестали искать альтернативы.
И это при том, что Scala-коммюнити в СНГ одно из самых активных.
gurinderu
13.04.2016 14:36+1Я расскажу свою историю.
Мне ответили примерно так «Нихера не понятно, переписывай на Java».
Вообще всегда сложно втюхать что-то новое старой гвардии.
kivsiak
13.04.2016 14:50+1Все верно. Код на Java понятен и мартышке. Код на Scala становится понятным только после серьезного опыта и то надо иметь архитектора который молодым обфускатрам по рукам стучать будет. Со сборкой в разы геммора больше. И ради чего? Все ради чего я в свое время в скалу погрузился есть и в современной яве.
potan
13.04.2016 14:57Какой гемморой со сборкой?
sbt — одна из самых простых систем управления сборкой в мире JVM, проще только lein.kivsiak
13.04.2016 15:00+2sbt то простой? у меня после него сложилось чувство что даже mvn проще. но я не про него, хоть эта зараза попила крови поначалу изрядно. Я про все библиотеки которые собираются под конкретную версию скалы.
Scf
13.04.2016 15:46+1у sbt одна из самых простых *идей управления сборкой*
А вот реализация… вырвиглазный DSL, отсутствие качественной документации, для любых нетривиальных вещей надо идти смотреть исходники. А исходники написаны на идеоматической (считай, нечитаемой) скале с минимумом комментариев. А так да, сбт я люблю…
Jtalk
13.04.2016 21:17Изучать новую систему сборки ради «почти такого же» языка желающих мало, особенно в промышленной сфере. Есть Maven, появляется Gradle. Scala даже первый плохо поддерживает (ломается anootation processing, например, если собирать scala-plugin'ом все).
maks1mm
14.04.2016 00:09+1gradle вроде как давно уже появился и в отличии от maven активно развивается.
sshikov
14.04.2016 22:19Гм. Вот знаете, у нас в соседнем проекте оказывается собирали все maven второй версии. Я уже забыл, когда у меня он был, лет семь наверное прошло с тех пор. При этом оно а) работает б) с тем же репозиторием в) разницы в pom.xml нет никакой. Инструменту 10 лет, он используется, и все довольны.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.leventov
15.04.2016 01:58Ну, надо сказать, что большинство таких коммитов состоят ровно из трех строк: обновлении номера версии в декларации враппера, grade-wrapper.properties, и таймстемпа. Просто для того, чтобы если кто-то пришел свеженький в разработку, скачал последний gradle и ваш проект, он бы не стал тут же тянуть бинарник старой версии, потому что она указана во враппере.
Хотя вот я долго не занимался одним проектом, который был на Gradle 2.0, недавно решил обновиться на 2.12, но не получилось, потому что они удалили какую-то функциональность, которой я пользовался. Вот этого я не понимаю.
maks1mm
15.04.2016 10:29Я не говорю что maven плохой, а gradle хороший. Каждый более хорош в чём то своём. Maven, как уже было сказано, стабильный и тд. и тп., gradle более гибкий, постоянно развивается. В пользу gradle могу сказать что проект с ant перевести на gradle намного проще чем на maven.
sshikov
15.04.2016 22:02Ну, с ant проще перевести на что угодно. Реальные проблемы в сборке обычно начинаются тогда, когда у нас в проекте кучка зависимостей, как внешних, так и внутренних, которые обновляются время от времени, и надо следить за их версиями, их совместимостью и т.п.
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).maks1mm
15.04.2016 22:17Я имел в виду что maven предполагает чёткую структуру, а gradle можно настроить как угодно и в моём случае когда у проекта структура была далеко не такая как у maven то её было намного легче перевести в gradle.
BrinkTheInquisitor
14.04.2016 19:46Gradle отлично поддерживает Scala, плагин весьма удобен, плюс существуют разные плагины типо gradle-scalatest для облегчения задач
Jtalk
14.04.2016 20:51+3Gradle даже себя нормально поддержать не может: каждые несколько версий какое-нибудь API ломают, и какие-нибудь плагины начинают отваливаться. Я пользуюсь им на работе — медлительный бегемот. Maven может собрать и задеплоить EAR быстрее, чем Gradle проинициализируется.
Я не использовал Gradle именно для Scala, так что мне интересно, как там обстят дела с:
1) Кросс-сборкой с Java: могу я использовать классы из Java в Scala в рамках одного проекта? А наоборот? Насколько сложно это конфигурится?
2) Если первый пункт работает, применяются ли в ходе него annotation processor'ы? Lombok там, или hibernate-modelgen?
3) Умеет эта штука понимать, что для появления Account_, указанного в импорте, в файлах, нужно собрать соответствующую Entity и скормить ее ModelGen'у?leventov
15.04.2016 02:02Да. Градл гибок, и в нем можно так вывернуться, что с Мавеном и представить невозможно. Но он медленнее и нестабильнее, и тут вряд ли можно ждать улучшений с учетом того, что разработчики предпочитают набрасывать новые фичи вместо полировки старых.
potan
13.04.2016 14:54+2Когда-то Россия славилась хорошим уровнем технического образования. Похоже, эти времена прошли, сейчас инженеры выбирают не что лучше, а что проще и более знакомо.
lpre
13.04.2016 21:21+2Есть разные критерии «лучшего». Простота и имеющийся опыт («более знакомо») — не самые маловажные из этих критериев.
«Старая гвардия» как раз и представляет ту самую школу с «хорошим уровнем технического образования», о котором вы так уважительно говорите :-)
bugabuga
13.04.2016 23:50Хуже. Сначала всё замечательно. Потом оказывается что бибилиотека «бла» для скалы больше не поддерживается, и приходится искать что-нибудь на замену, и а замена не совместима с другой библиотекой и пр. В результате получается лучше плюнуть и переписать всё обратно на жабу, чем пытаться прикручивать костыли (которые всё равно на джаве) :(
Jtalk
14.04.2016 13:35Это закономерно. Делал проект на ней, довел до конца, но повторять желания нет. Возможности и синтаксис — это хорошо, но есть огромные проблемы с поддержкой в IDE (поддерживает ее более-менее нормально из гигантов только проприетарная IDEA), проблемы с кросс-сборкой с Java (annotation processing ломается, постоянно «теряются» классы при чистой сборке), периодические «глупые» баги (Jsoup не работает в ней от слова «совсем»).
С точки зрения «шашечек» Scala хороша, но с точки зрения «ехать» там работ непочатый край. Она субъективно опережает остальные JVM-языки (помню как Groovy мне NullObject возвращал из инициализатора Map — можно сразу в продакшон), но все еще сильно отстает от Java.
kivsiak
13.04.2016 14:17Использую gradle, считать ли что используем groovy?
leventov
13.04.2016 14:31-1Нет
guai
13.04.2016 20:55+2даже если запилены свои грэдловые плугины на груви и без них основной продукт никак не соберется?
leventov
13.04.2016 21:21Каждый сам решает, что такое «использование». Если у вас полноценные Груви классы, логика, и вы знаете Груви — это одно. Если кроме фигурных скобок в блоке dependencies никаких элементов собственно синтаксиса Груви нет, и вы по большому счету язык не знаете — другое.
UbuRus
14.04.2016 15:04> Какие JVM-языки (помимо Java) вы используете в production?
Сюда явно можно относить только тот код, который бежит на проде.
> Используется ли X в вашей компании?
А вот сюда как раз «вы знаете X» и «написали один класс для билда в проекте на X»
mr-garrick
13.04.2016 15:22А как посмотреть результаты голосования?
Intimatik
14.04.2016 00:36Перейдите на не мобильную версию страницы.
Судя по вакансиям Scala не очень популярна в России, кто же тогда все эти люди что пишут на Scala?
Сам в свое время променял энтерпрайз на Scala и контейнеры о чем пока ни разу не пожалел.mr-garrick
14.04.2016 22:26Да, вроде я нормальную версию смотрю, на ноуте через Firefox. Вижу пункты опроса, вижу под каждым пунктом сколько человек проголосовало, сколь воздержалось. Но какие именно пункты они выбрали не вижу. Так и должно быть?
UbuRus
14.04.2016 15:07-3Мне интересно, все те люди которые в опросе «Используется ли Kotlin в вашей компании?» ответили «Нет, и не собираемся пробовать» не знают что такое Котлин, или у них какие-то объективные причины? Потому что из всех JVM языков, Котлин единственный который может конкурировать с Java.
Jtalk
14.04.2016 20:45Полагаю, народ уже насмотрелся на этих «убийц Java». Каждый год новый супер-язык, который решает все проблемы: Ceylon, Gosu, теперь вот Kotlin. Маленький, но гордый язык, поддерживаемый только одной полупроприетарной IDE за 150 баксов в год. Одного энтузиазма и собственной IDE недостаточно, чтобы победить монстра, которого «3 billion devices run».
UbuRus
14.04.2016 23:28-1Jtalk Конечно открытой 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?
dougrinch
15.04.2016 01:22скорость кода на Котлине зачастую превосходит джава код
А вот про это поподробнее, пожалуйста.leventov
15.04.2016 02:05Вряд ли кто-то делал вменяемые измерения, но разработчики часто упоминают инлайн-функции, как фактор ускорения.
UbuRus
15.04.2016 10:35Там где в Java вы бы использовали Optional, вы не используете ничего, когда у вас есть маленькая вспомогательная функция — вы её инлайните. Думаю больше о производительности будет рассказано тут: http://javapoint.ru/talks/jemerov/
Jtalk
15.04.2016 11:23+3А как inline будет сочетаться с override? Что увидит Java при попытке отнаследоваться от объекта с inline функцией вместо этой функции? Если функция там все-таки будет — это ахтунг: загружаем наследника, меняем в IoC-контейнере реализацию на наследника, и получаем так любимое C++-программистами UB: в тех классах, где был inline, получаем старое поведение. Если функции не будет, то ничего не сломается, но и пользоваться этой возможностью не будет никто: в мире промышленной разработки ситуация, когда часть твоих методов пропадает после компиляции, это не очень здорово.
Также интересно, как все эти штуки будут работать с проксированием: аспекты, CGLIB и вот это все. Spring и Java EE построены на этих технологиях, а inline либо не будет с ними работать совсем, либо их сломает.
JIT уже делает inlining, только делает это с полным представлением о происходящем внутри JVM и может быстро реагировать на «нежданчики»: загрузку новых классов, изменение байткода через javassist и прочие вот такие вот полезные вещи, которыми напичканы множество промышленных проектов.UbuRus
15.04.2016 11:50Достаточно было прочитать первое предложение из доки, чтобы не писать столько бессмысленных вопросов: https://kotlinlang.org/docs/reference/inline-functions.html
> JIT уже делает inlining
Только когда глубина стека меньше 10, а в современных веб приложениях это примерно никогда.
Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)Jtalk
15.04.2016 12:09Так, прочитал, понял что все эти функции — объекты. Какое предложение нужно прочитать, чтобы понять, как это будет выглядеть из Java в «идеальном interop»?
> Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
Android — это своя атмосфера с протухшей виртуальной машиной. Тем не менее, утверждение звучит сомнительно. Есть какая-то статистика массового перехода приложений в _production_ на Kotlin с других языков?UbuRus
15.04.2016 12:44> А как inline будет сочетаться с override?
так как это применяется к higher-order functions то логично что никак, продолжать?
Если говорить про interop, то это будет просто статический метод в соответсвующем пакете.
leventov
15.04.2016 02:08Я недавно попробовал писать на Kotlin, язык не без шероховатостей, тулинг и поддержка IDE пока заметно отстает (от той же джавовской в той же Idea, как ни парадоксально), полнота документации оставляет желать лучшего. Хотя, думается, в 1996 году Java представляла из себя гораздо более печальное зрелище.
UbuRus
15.04.2016 10:36А можно больше конкретики?
leventov
15.04.2016 11:39В кратце по языку — мне не нравится запись типов справа от переменных, companion objects это шиза (по всей видимости чтобы подружиться с js бекендом), которая мешает нормально структурировать код, много относительно случайных (по синтаксису) фишечек, которые выглядят как попытка заткнуть конкретные дырки, и несогласованно с общим дизайном: field, My::class, lateinit,
По тулингу и документации: просто попробуйте и поймете
UbuRus
15.04.2016 11:47Что значит «попробуйте и поймете»? Я пишу на Котлин каждый день и не вижу проблем ни с туллингом ни с документацией.
leventov
15.04.2016 12:03Я за день использования зафайлил два бага (в идее), еще один не зафайлил, многие вещи работают через раз почему-то, хотя с Java такой "нестабильности" инспекций никогда не было.
По документации нет поиска, нет индекса, нет "use" как в Javadoc. Навигация по доке kotlin.collections и попытка там что-то найти — то еще удовольствие.
Скудность документации вещь субъективная, но имхо референс должен быть раза в полтора больше (т. е. подробнее)
UbuRus
15.04.2016 12:14> Я за день использования зафайлил два бага (в идее), еще один не зафайлил, многие вещи работают через раз почему-то, хотя с Java такой «нестабильности» инспекций никогда не было.
Баги в идеи у меня сыплются и без Kotlin, так же как они сыплются у меня в WebStorm.
> По документации нет поиска, нет индекса, нет «use» как в Javadoc. Навигация по доке kotlin.collections и попытка там что-то найти — то еще удовольствие.
site:kotlinlang.org bla-bla? pdf?
В целом действительно, плагин отваливался в RC, потом починили. Теперь с каждым днем становится только стабильнее. Проблем с навигацией, инспекциями и подстветкой никогда не имел. Если сейчас взять груви или скалу, то Котлин плагин выглядит куда более зрелым. Прямо сейчас у парней сломалась подстветка груви в спок тестах, причем как в стабильной версии так и в eap.leventov
15.04.2016 12:28Я сравниваю с Java
UbuRus
15.04.2016 12:33> хотя с Java такой «нестабильности» инспекций никогда не было
была, после выхода java 8 инспекции могли подсвечивать правильный java 8 код, хотя поддержка джавы 8 была объявлена :) это так, почему-то вспомнил
Если сравнивать с Java, то да, десятилетием разрабаттываемая поддержка джава действительно выглядит серьезнее и в ней меньше багов (хотя случаются)
Но мой поинт был именно в том, что среди других альтернативных JVM языков, Kotlin имеет действительно хороший тулинг с рождения.
UbuRus
15.04.2016 12:46Статические методы отлично заменяются higher-order functions и extension functions, как еще может мешать отсутсвие статических методов?
Jtalk
15.04.2016 02:24+2> в котлине решена «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 на свою платформу и доить клиентов, видимо, но вряд ли это сработает.leventov
15.04.2016 03:15А решение по сути сводится к тому, что вместо монады Option из Scala сделан синтаксический сахар.
Да, и это очень правильно. Потому что от verbosity того же Optional в Java 8, которую понапихали в новые классы, сводит скулы. Что характерно, кроме самих авторов JDK эту Optional никто не использует. Проще на null проверить, чем приседать с Optional.
Попробуйте Lombok. Серьезно. Мир Java уже совсем не таков, каким был 10 лет назад.
Который заточен под Eclipse, ага. Вместо лок-ина на Идею получаем лок-ин на Эклипс.
Я изобрел таблетку от всех болезней, но чтобы ее получить вы должны заплатить JetBrains 150 баксов
Idea CE и Android Studio бесплатны.
Jtalk
15.04.2016 11:07+2> Что характерно, кроме самих авторов JDK эту Optional никто не использует.
Это неправда, мы используем во всех проектах, которые перевели на Java 8. Это позволяет писать более чистые и самодокументирующиеся API. Заворачивать каждый вызов каждой функции в if (result == null) никаких пальцев не напасешься.
> Который заточен под Eclipse, ага.
Это неправда, в NetBeans нативная поддержка, в IDEA плагином.
> Idea CE и Android Studio бесплатны.
Предложение, следующее за тем, которое вы прокомментировали, как раз посвящено CE, почему вы его проигнорировали?leventov
15.04.2016 11:29+1Optional безопаснее, спору нет, но чтобы писать
Optional[T] result = ...;
if (result.is present())
use(result.get());
Надо еще сильно больше пальцев. map() же имхо затрудняет понимание кода (я люблю Хаскель, но претензии на мат. абстракции в Java выглядят неуместно), создает лямбду что еще снижает шансы на scalar replacement всей этой колбасы, и не избавляет от Optional, с которым в конце концов придется что-то делать.
У любой относительно нишевой надстройки над Java, в идеальной поддержке которой не заинтересованы вендоры IDE, по определению поддержка будет лучше в той среде, в которой сидят создатели надстройки. А плагины к другим работать будут по остаточному принципу. Для Котлина тоже есть Эклипс-плагин, тем не менее я не спорю, что Котлин это лок-ин на Идею.
Насчет CE — зависит от задач. Если это не Энтерпрайза/веб, ультимейт не нужна.
Jtalk
15.04.2016 12:01Я, в принципе, согласен, что Optional довольно громоздок. Вопрос тут только в балансе: стоит ли вводить в проект новый язык с неясными перспективами и потенциальным вендорлоком ради этого сахара?
Ну и в общем-то неудачно немного у JB совпало: ввели подписочную модель принудительно, чем разозлили часть сообщества, а потом выкатили Kotlin. После первого народ быстро понял, что JetBrains — это не улыбающиеся дяденьки, которые переводят старушек через дорогу, а простой бизнес, конечная цель которого — зарабатывание денег. Повод дважды подумать насчет баланса и «неясных перспектив».UbuRus
15.04.2016 12:16+1Ну не сахар это :) Это система типов блин, String? это именно тип, который может быть String | Null.
Кстати подписочная модель дешевле чем в год по версии покупать, а еще подарили год, когда переходил на подписку. У меня стойкое ощущение что разозлились в основном те, кто пиратил :)
UbuRus
15.04.2016 10:53+1> Сделали 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.Jtalk
15.04.2016 11:56+2> Вы всё напутали, это всё 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.UbuRus
15.04.2016 12:09> Допустим, я вам верю, хотя это не так. Как именно будут происходить 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 выпилили совсем, т.е. они признали технологию говном мамонта, такие дела.Jtalk
15.04.2016 13:24Какой 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
А что это такое?
UbuRus
15.04.2016 13:32> А если я уберу явное указание типа, то он не даст мне вызывать методы на этой штуке точкой, только «специальным оператором ?.». Это все по сути и является монадой Option.
Это по сути является тем, что вы не можете вызывать на инстансе типа T? никаких методов, пока не сделается null-check. В рантайме естественно нету никаких T? а есть только T, и боже упаси нету Optional[T]. Монадой Option тут не пахнет.
> его можно проверить только в runtime
С поддержкой IDEA это не большая проблема. Yaml это посути замена properties, но не XML
> А что это такое?
Пожалуй гугл лучше справится с этой задачей
belovrv
Очень не хватает варианта: «Да, страдаем» ;)