GOG, насколько я помню, дает возвращать только при технических трудностях в работе игры на подходящем железе. К тому же, у них страшно дерьмовый саппорт: они реально могут месяцами рефанд тянуть, просто неделями не отвечая на сообщения. Лично пробовал: возврат 5 баксов занял больше двух месяцев, при том, что в конце я устал и согласился на возврат «внутренней валюты» вместо карточного рефанда; можно было бы еще месяцок-другой легко потянуть на этой теме.
Нет, я Java-разработчик. И именно поэтому я знаю, что, помимо того JDK, который вы называете «в Java», есть и другие JDK, свободные и весело-вендорские, со своими реализациями, ошибками и заморочками. И именно поэтому я считаю, что наличие вкуса и умение читать документацию важнее заучивания наизусть кишок оракловой реализации.
А давайте, может, раз уж мы все тут такие эксперты по внутренностям JDK собрались, вспомним про реализацию EnumMap? Может, если мы используем EnumMap, тыкаться каждый раз get'ом в цикле будет нормальной идеей? Мы ведь ЗНАЕМ ее внутренности и как они работают, почему бы и не завязаться на это, да?
А вот почему быстрее — вы сможете узнать, когда, например, хотя бы один раз заглянете в исходный код этих мапов, т.е. изучив структуру хранения
А можно я изучу исходный код JIT и, возможно, узнаю, что он сможет развернуть одно выражение в другое без потери производительности? Что, получается, как в «Камень-Ножницы-Бумага», знание JIT бьет чтение исходников HashMap? Тогда, получается, вам нужно переставать спрашивать внутренности коллекций и просить цитировать исходники компилятора? Или, может, все-таки задуматься над прекращением попыток сопоставить кругозор кандидатов с собственным, игнорируя все за пределами их пересечения?
А «строки из википедии» я тоже не заучиваю. Время — слишком ценный ресурс, чтобы тратить его на удовлетворение самолюбия местечковых Software Development-царьков.
приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных
Каким образом знание структуры хранения в конкретной реализации HashMap для конкретной JDK поможет не писать дурной код? Или что, если заменить HashMap на TreeMap, вышеописанный подход станет верным? Банальное отсутствие опыта и вкуса, проверяется за 10 минут просьбой поревьюить кусочек плохого кода.
а можно подумать правильно ли это
Так если вам нужны люди, умеющие думать, зачем у них спрашивать заученные строчки из википедии? Может, попросить у них подумать «на камеру» вместо этого?
Забавно, ни разу не встречал работодателя, который соглашался бы с тем, что его компания может быть не настолько хорошей, насколько он хочет показать, и поэтому работнику нужно на испытательный срок большую зарплату поставить, которая покрыла бы его риски из-за смены работы. Наоборот — пожалуйста, сэкономить за счет кандидата первые пару месяцев — пожалуйста, а бревно в глазу искать — нет, что вы, какие бревна, мы же IT компания, а не лесопилка.
Вы написали статью о том, как игнорируете права кандидатов, ради оптимизации своих затрат, на ресурсе, абсолютное большинство посетителей которого являются, являлись или будут являться теми самыми кандидатами. Либо это виртуальный [Роскомнадзор], либо одно из двух.
> Основное правило при выборе инструментов — выбирать то, чем владеешь
Если это так, то, с оглядкой на российское образование в сфере ИТ, идеальный проект — это очередной клон екселя на Delphi, выученном еще в школе, для бумажной бухгалтерии. Выбирать нужно то, что лучше подходит под задачу.
Вы путаете «идеальную интеграцию» и «хоть какую-то». Spring вообще не панацея, по своей сути это еще один Java EE сервер, только с собственными нескучными API (хоть они и пытаются в последних версиях поддерживать стандартные, например, CDI Inject). Spring Boot превращает ваш софт в Bloatware, которое возит за собой тонны ненужных вещей, заботливо им сконфигуренных, и все такое прочее. То, что Spring легче конфигурить, чем, например, Wildfly — это, вообще говоря, неправда, вопрос привычки, не более.
Я по вашим ответам уже вижу, что вы «стиляга от разработки» — TDD, code coverage, continuous integration и вот это все. Я не отрицаю ваше право заниматься всем этим. Действительно, если потребитель каждый день ждет новых смайликов с котиками на вашем сайте, все это работает. Но поймите и вы, что есть совершенно другой мир. Есть мир, где деплой не проходит без одобрения службы безопасности, и где перед тем, как вы начнете писать модульные тесты на модульные тесты микросервисов к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире. Есть мир, где модные технологии правят, а есть мир, где правят отлаженные процессы и репутация вендоров. Какой бы медлительной не была WebSphere, она и поставляемое с ней добро, вроде message broker'ов, работают на сотнях тысяч инсталляций по всему миру, и если ко мне придет дядя с миллиардом долларов, и спросит, кому лучше доверить тот самый миллиард, уродливому Oracle, или модной MongoDB, я выберу первое, пусть я и терпеть его не могу. Потому что мода — это проходящее, а путешествие в лес в багажнике редко бывает чаще раза в жизни, и это неспроста.
> Опустим презентационную часть, еще раз, что конкретно есть такого в JEE, что нельзя или слишком затратно сделать без него? Все технологии доступны по отдельности.
Интеграция и стандартизация же. Да, есть отдельно Weld, отдельно Jersey, отдельно к нему можно привинтить Arjuna. Нужны CMT — иди прикручивай AspectJ. Нужна система событий? Удачи с прикручиванием этого добра и пробросом зависимостей. Нужны распределенные транзакции? Идем читать маны по Hazelcast. Разработчик забил на поддержку Hazelcast? Начинаем переписывать километры интерфейсов, которые были под него заточены. И не надо мне рассказывать, что идеальные программисты из вашего окружения сразу разрабатывают идеальные интерфейсы, позволяющие легко интегрировать технологии, которые в момент написания этих интерфейсов еще не были придуманы.
Да, бывают баги. Да, некоторые конттейнеры ведут себя по-разному. Да, Weld в Glassfish ломается на выражениях, которые жует Weld из JBoss. Но без Java EE это было бы не «более надежно», этого бы вообще не было. Ваш путь — уничтожить Enterprise-платформу и поверх нее создать новую, коммунистическую Программу, которая будет сама все делать и обо всем знать — утопичен по своей сути. Есть у вас есть время и средства разрабатывать Enterprise-стек для каждого вашего нового проекта, это здорово, но большинству нужны рабочие приложения, а не идеальные схемы распределенной микросервисной архитектуры, промазанной костылями для решения проблем, которые в JEE решаются одной аннотацией.
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
А что это такое?
Так, прочитал, понял что все эти функции — объекты. Какое предложение нужно прочитать, чтобы понять, как это будет выглядеть из Java в «идеальном interop»?
> Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
Android — это своя атмосфера с протухшей виртуальной машиной. Тем не менее, утверждение звучит сомнительно. Есть какая-то статистика массового перехода приложений в _production_ на Kotlin с других языков?
Я, в принципе, согласен, что Optional довольно громоздок. Вопрос тут только в балансе: стоит ли вводить в проект новый язык с неясными перспективами и потенциальным вендорлоком ради этого сахара?
Ну и в общем-то неудачно немного у JB совпало: ввели подписочную модель принудительно, чем разозлили часть сообщества, а потом выкатили Kotlin. После первого народ быстро понял, что JetBrains — это не улыбающиеся дяденьки, которые переводят старушек через дорогу, а простой бизнес, конечная цель которого — зарабатывание денег. Повод дважды подумать насчет баланса и «неясных перспектив».
> Вы всё напутали, это всё 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.
А как inline будет сочетаться с override? Что увидит Java при попытке отнаследоваться от объекта с inline функцией вместо этой функции? Если функция там все-таки будет — это ахтунг: загружаем наследника, меняем в IoC-контейнере реализацию на наследника, и получаем так любимое C++-программистами UB: в тех классах, где был inline, получаем старое поведение. Если функции не будет, то ничего не сломается, но и пользоваться этой возможностью не будет никто: в мире промышленной разработки ситуация, когда часть твоих методов пропадает после компиляции, это не очень здорово.
Также интересно, как все эти штуки будут работать с проксированием: аспекты, CGLIB и вот это все. Spring и Java EE построены на этих технологиях, а inline либо не будет с ними работать совсем, либо их сломает.
JIT уже делает inlining, только делает это с полным представлением о происходящем внутри JVM и может быстро реагировать на «нежданчики»: загрузку новых классов, изменение байткода через javassist и прочие вот такие вот полезные вещи, которыми напичканы множество промышленных проектов.
> Что характерно, кроме самих авторов JDK эту Optional никто не использует.
Это неправда, мы используем во всех проектах, которые перевели на Java 8. Это позволяет писать более чистые и самодокументирующиеся API. Заворачивать каждый вызов каждой функции в if (result == null) никаких пальцев не напасешься.
> Который заточен под Eclipse, ага.
Это неправда, в NetBeans нативная поддержка, в IDEA плагином.
> Idea CE и Android Studio бесплатны.
Предложение, следующее за тем, которое вы прокомментировали, как раз посвящено CE, почему вы его проигнорировали?
> в котлине решена «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 на свою платформу и доить клиентов, видимо, но вряд ли это сработает.
Gradle даже себя нормально поддержать не может: каждые несколько версий какое-нибудь API ломают, и какие-нибудь плагины начинают отваливаться. Я пользуюсь им на работе — медлительный бегемот. Maven может собрать и задеплоить EAR быстрее, чем Gradle проинициализируется.
Я не использовал Gradle именно для Scala, так что мне интересно, как там обстят дела с:
1) Кросс-сборкой с Java: могу я использовать классы из Java в Scala в рамках одного проекта? А наоборот? Насколько сложно это конфигурится?
2) Если первый пункт работает, применяются ли в ходе него annotation processor'ы? Lombok там, или hibernate-modelgen?
3) Умеет эта штука понимать, что для появления Account_, указанного в импорте, в файлах, нужно собрать соответствующую Entity и скормить ее ModelGen'у?
Полагаю, народ уже насмотрелся на этих «убийц Java». Каждый год новый супер-язык, который решает все проблемы: Ceylon, Gosu, теперь вот Kotlin. Маленький, но гордый язык, поддерживаемый только одной полупроприетарной IDE за 150 баксов в год. Одного энтузиазма и собственной IDE недостаточно, чтобы победить монстра, которого «3 billion devices run».
Это закономерно. Делал проект на ней, довел до конца, но повторять желания нет. Возможности и синтаксис — это хорошо, но есть огромные проблемы с поддержкой в IDE (поддерживает ее более-менее нормально из гигантов только проприетарная IDEA), проблемы с кросс-сборкой с Java (annotation processing ломается, постоянно «теряются» классы при чистой сборке), периодические «глупые» баги (Jsoup не работает в ней от слова «совсем»).
С точки зрения «шашечек» Scala хороша, но с точки зрения «ехать» там работ непочатый край. Она субъективно опережает остальные JVM-языки (помню как Groovy мне NullObject возвращал из инициализатора Map — можно сразу в продакшон), но все еще сильно отстает от Java.
Изучать новую систему сборки ради «почти такого же» языка желающих мало, особенно в промышленной сфере. Есть Maven, появляется Gradle. Scala даже первый плохо поддерживает (ломается anootation processing, например, если собирать scala-plugin'ом все).
А давайте, может, раз уж мы все тут такие эксперты по внутренностям JDK собрались, вспомним про реализацию EnumMap? Может, если мы используем EnumMap, тыкаться каждый раз get'ом в цикле будет нормальной идеей? Мы ведь ЗНАЕМ ее внутренности и как они работают, почему бы и не завязаться на это, да?
А можно я изучу исходный код JIT и, возможно, узнаю, что он сможет развернуть одно выражение в другое без потери производительности? Что, получается, как в «Камень-Ножницы-Бумага», знание JIT бьет чтение исходников HashMap? Тогда, получается, вам нужно переставать спрашивать внутренности коллекций и просить цитировать исходники компилятора? Или, может, все-таки задуматься над прекращением попыток сопоставить кругозор кандидатов с собственным, игнорируя все за пределами их пересечения?
А «строки из википедии» я тоже не заучиваю. Время — слишком ценный ресурс, чтобы тратить его на удовлетворение самолюбия местечковых Software Development-царьков.
Каким образом знание структуры хранения в конкретной реализации HashMap для конкретной JDK поможет не писать дурной код? Или что, если заменить HashMap на TreeMap, вышеописанный подход станет верным? Банальное отсутствие опыта и вкуса, проверяется за 10 минут просьбой поревьюить кусочек плохого кода.
Так если вам нужны люди, умеющие думать, зачем у них спрашивать заученные строчки из википедии? Может, попросить у них подумать «на камеру» вместо этого?
Вы написали статью о том, как игнорируете права кандидатов, ради оптимизации своих затрат, на ресурсе, абсолютное большинство посетителей которого являются, являлись или будут являться теми самыми кандидатами. Либо это виртуальный [Роскомнадзор], либо одно из двух.
Если это так, то, с оглядкой на российское образование в сфере ИТ, идеальный проект — это очередной клон екселя на Delphi, выученном еще в школе, для бумажной бухгалтерии. Выбирать нужно то, что лучше подходит под задачу.
Я по вашим ответам уже вижу, что вы «стиляга от разработки» — TDD, code coverage, continuous integration и вот это все. Я не отрицаю ваше право заниматься всем этим. Действительно, если потребитель каждый день ждет новых смайликов с котиками на вашем сайте, все это работает. Но поймите и вы, что есть совершенно другой мир. Есть мир, где деплой не проходит без одобрения службы безопасности, и где перед тем, как вы начнете писать модульные тесты на модульные тесты микросервисов к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире. Есть мир, где модные технологии правят, а есть мир, где правят отлаженные процессы и репутация вендоров. Какой бы медлительной не была WebSphere, она и поставляемое с ней добро, вроде message broker'ов, работают на сотнях тысяч инсталляций по всему миру, и если ко мне придет дядя с миллиардом долларов, и спросит, кому лучше доверить тот самый миллиард, уродливому Oracle, или модной MongoDB, я выберу первое, пусть я и терпеть его не могу. Потому что мода — это проходящее, а путешествие в лес в багажнике редко бывает чаще раза в жизни, и это неспроста.
Интеграция и стандартизация же. Да, есть отдельно Weld, отдельно Jersey, отдельно к нему можно привинтить Arjuna. Нужны CMT — иди прикручивай AspectJ. Нужна система событий? Удачи с прикручиванием этого добра и пробросом зависимостей. Нужны распределенные транзакции? Идем читать маны по Hazelcast. Разработчик забил на поддержку Hazelcast? Начинаем переписывать километры интерфейсов, которые были под него заточены. И не надо мне рассказывать, что идеальные программисты из вашего окружения сразу разрабатывают идеальные интерфейсы, позволяющие легко интегрировать технологии, которые в момент написания этих интерфейсов еще не были придуманы.
Да, бывают баги. Да, некоторые конттейнеры ведут себя по-разному. Да, Weld в Glassfish ломается на выражениях, которые жует Weld из JBoss. Но без Java EE это было бы не «более надежно», этого бы вообще не было. Ваш путь — уничтожить Enterprise-платформу и поверх нее создать новую, коммунистическую Программу, которая будет сама все делать и обо всем знать — утопичен по своей сути. Есть у вас есть время и средства разрабатывать Enterprise-стек для каждого вашего нового проекта, это здорово, но большинству нужны рабочие приложения, а не идеальные схемы распределенной микросервисной архитектуры, промазанной костылями для решения проблем, которые в JEE решаются одной аннотацией.
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
А что это такое?
> Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
Android — это своя атмосфера с протухшей виртуальной машиной. Тем не менее, утверждение звучит сомнительно. Есть какая-то статистика массового перехода приложений в _production_ на Kotlin с других языков?
Ну и в общем-то неудачно немного у JB совпало: ввели подписочную модель принудительно, чем разозлили часть сообщества, а потом выкатили Kotlin. После первого народ быстро понял, что JetBrains — это не улыбающиеся дяденьки, которые переводят старушек через дорогу, а простой бизнес, конечная цель которого — зарабатывание денег. Повод дважды подумать насчет баланса и «неясных перспектив».
Допустим, я вам верю, хотя это не так. Как именно будут происходить 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.
Также интересно, как все эти штуки будут работать с проксированием: аспекты, CGLIB и вот это все. Spring и Java EE построены на этих технологиях, а inline либо не будет с ними работать совсем, либо их сломает.
JIT уже делает inlining, только делает это с полным представлением о происходящем внутри JVM и может быстро реагировать на «нежданчики»: загрузку новых классов, изменение байткода через javassist и прочие вот такие вот полезные вещи, которыми напичканы множество промышленных проектов.
Это неправда, мы используем во всех проектах, которые перевели на Java 8. Это позволяет писать более чистые и самодокументирующиеся API. Заворачивать каждый вызов каждой функции в if (result == null) никаких пальцев не напасешься.
> Который заточен под Eclipse, ага.
Это неправда, в NetBeans нативная поддержка, в IDEA плагином.
> Idea CE и Android Studio бесплатны.
Предложение, следующее за тем, которое вы прокомментировали, как раз посвящено CE, почему вы его проигнорировали?
Давайте будем честными: не решена она, это просто маркетинг. Я смотрел презентацию 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 на свою платформу и доить клиентов, видимо, но вряд ли это сработает.
Я не использовал Gradle именно для Scala, так что мне интересно, как там обстят дела с:
1) Кросс-сборкой с Java: могу я использовать классы из Java в Scala в рамках одного проекта? А наоборот? Насколько сложно это конфигурится?
2) Если первый пункт работает, применяются ли в ходе него annotation processor'ы? Lombok там, или hibernate-modelgen?
3) Умеет эта штука понимать, что для появления Account_, указанного в импорте, в файлах, нужно собрать соответствующую Entity и скормить ее ModelGen'у?
С точки зрения «шашечек» Scala хороша, но с точки зрения «ехать» там работ непочатый край. Она субъективно опережает остальные JVM-языки (помню как Groovy мне NullObject возвращал из инициализатора Map — можно сразу в продакшон), но все еще сильно отстает от Java.