Ну вот мы и вернулись к изначальному тезису.
1. У дяди есть миллиард
2. Он уперт и ограничен. Не понимает процессов автоматизации. Любит покупать красивые и дорогие штучки из линии Websphere и подобных.
В этом случае имеет смысл использовать 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.
Опустим презентационную часть, еще раз, что конкретно есть такого в 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, что нельзя сделать отдельно от него? Единственно верный ответ — JTA, ради которого все и задумывалось. Однако мало того, что в 90% случаев он попросту не нужен, даже если работа идет с разными ресурсами, то в оставшихся 10% он вреден и создает ложное ощущение надежности. А JTA креши случаются, и если обычная программа как правило знает как выбраться из такой ситуации (это предусмотрено самой логикой), то в случае JTA все глухо лежит до тех пор, пока не поднимут с постели админа, который судорожно будет рыться в интернетах на вопрос как откатить рухнувшую транзакцию в конкретном контейнере. А в мире есть всего полтора человека, которые делали это.
Кроме того, вызов сраного вебсервиса, реста или даже простого remote EJB нарушает всю JTA, т.к. вызов не координируется с remote-контейнером.
Все остальное делается лучше и проще без JEE. Отдельные части как JPA, Servlets доступны ввиде библиотек и фреймворков, к тому же есть over9000 схожих альтернатив. А микросервисная архитектура становится мейнстримом. И вроде как over9000 высоконагруженных проектов в интернетах живет и здравствует без JEE.
Она не столько сложная, сколько неюзабельная, изначально неверная и по-большому ненужная. Монолитное приложение, деплоящееся в отдельный контейнер напрочь убивает возможность и желание что-то делать. Всякие хаки типа Arquillian и Embedded OpenEJB вмеремешку со своими костылям, конечно, помогают, но не панацея от напасти.
Тем не менее, клиент один раз потративший килодоллары на JEE платформу, хочет ее амортизировать и заставляет писать под нее. В этом случае действует четкое правило при работе с клиентом. Соглашаться на проект, если выполняются оба эти пункта:
1. Клиент с баблом
2. Он дебил
Если не выполнен первый пункт, смысла связываться нет — прогорите на поддержке. Если не выполнен второй — следует вразумить клиента, что есть более стабильные способы достижения результата, и что его задача — сконцентрироваться на самой проблеме, а не на способе ее решения.
Давайте разделим фичи на три типа:
1. тяжелые, значительно затрагивающие работу VM
2. средние, добавляющие в язык определенный функционал, но контролируемых на уровне компилятора
3. легкие — всякий синтаксический сахар
К первому типу будет относиться value types, если когда-нибудь вообще выйдут. За все время существования Java не было сделано столь серьезных изменений. Даже появление generics и лямбд фактически не затрагивало VM. Любую подобную фичу реализовать с гарантией обратной совместимости будет огромной проблемой. Придется решать сразу огромный круг задач из всевозможных областей, менять спецификации, JMM, валидатор кода, поддерживать на всех архитектурах, etc…
Второй тип — это все, что до сих пор делалось в Java. Тем не менее всегда проблемно что-то встроить, не поломав совместимости. С одной стороны у нас есть крутая фича, с другой — API Java и куча легаси-кода, который нужно мигрировать. Основной затык в лямбдах был именно встроить их в коллекции. Разработчики реально задолбались, в итоге выкинули все нахрен и сделали отдельно Stream. Даже такая простая вещь как unsigned тип поломает все и сразу: сериализацию, все библиотеки, работающие с рефлекшном, абсолютно все фреймворки, etc…
Сахар? Ну а как бы зачем? Семантически запись не меняется, лишь делается чуть короче, что не имеет большого смысла, т.к. сегодня IDE берет на себя всю нагрузку по печатанию кода. Посмотрите, какая полемика развернулась по поводу var. Так что импорты, литералы и прочее — это то, что меньше всего волнует.
Поэтому если вам нужна гибкость и плюхи, и вас не беспокоит, то, что через год-два ваш код не будет компилироваться или работать — всегда есть альтернативные JVM языки.
Мне оному так кажется, или я все неправильно понял?
В данной схеме отсутствует важный элемент — certificate authority, который бы подтверждал, что ключ действительно от пользователя B, а не сгенеренный где-то посередине. Таким образом возможна банальная компроментация man-in-middle: отправляем пользователям A и B свои сгенерированные публичные ключи. Имея их настоящие ключи, проксируем весь треффик и наслаждаемся.
И самое натуральное место для подобной компроментации — это сам «Watsapp Server». Неужели под видом «end-to-end» вселяют пользователям ложную уверенность. А спецслужбы одобряют.
Если мои рассчеты меня не подводят (асимптотическая формула Стирлинга), уже в 14-мерном апельсине кожуры всегда больше, чем мякоти. Для 60-мерного апельсина разница составляет уже в 20 раз. А для 200-мерного ее больше в 28527 раз. Есть становится буквально нечего!
> это прозвучит странно, но мне эти стектрейсы нравятся.
Я не против стейтрейсов. Стектрейсы — это лучшее, что отличает Java от других. Я против многократных оборачиваний эксепшнов и «перевыкидываний» (re-throw). Лучше получить единственный NullPointerException at XXX и далее стейтрейс, чем цепочку из «Caused by»…
> 9 из 10 людей не умеют правильно вскрывать пакетики-трубочки с сахаром
Спасибо! Век живи — век учись! :)
В данном случае преимущества unchecked в том, что справедливо правило: не умеешь — не берись. Тогда как checked обязует заловить себя, не объяснив новичку что с собой делать. А правильное решение, между прочим, очень нетривиально. И потом отловить на продакшне проблему становится практически невозможно.
> self-hosted компилятор, строковая интерполяция, вложенные функции, туплы, паттерн-матчинг…
Большинство из модных фич упрощают написание кода, но далеко не всегда упрощают разработку (включая тестирование, отладку, поддержку кода). Все новые и необычные фичи очень лениво и эпизодически используются девелоперами. Это делает их наличие в языке рудиментарным. Особенно когда есть более привычный стандартный подход к решению.
> Есть области применения, где вопрос Scala vs Java не стоит, т.к. Java просто не подходит.
То есть Вы хотите сказать, что существуют некоторые задачи общего назначения, которые можно решить на Scala и нельзя на Java? Навскидку (только не плагин для sbt)?
> взять Scala вместо/вместе с Java и получить бенефитов в виде возросшей продуктивности, мне в голову не приходит.
Почему-то все мыслят продуктивность исключительно в контесте написания кода: мой код короче, я пишу быстрее, поэтому я продуктивнее. Если взять качество кода, читабельность, простоту, сопровождение, тулинг, и совместную разработку, то все профиты резко уйдут в минус.
> Spark, Play или Akka.
Священная троица TypeSafe. Play и Akka изначально были написаны на Java и к Scala вообще не имели никакого отношения. Интерес к Play резко упал после того как к нему прилепили скалу и выпустили несовместимую ветку 2.x. Огромное количество тех, кто использует Play, до сих пор сидят на ветке 1.x и отказываются переходить, ибо разработка на 1.x в разы продуктивней, хоть и на Java. Spark ессно имеет API на Java. А вот чисто скаловский фреймворк — это Lift. Ну и много на нем пишут?
> Затрудняюсь назвать какие-либо Groovy
Gradle, например.
Java скорей ориентируется на C#, нежели на скалу. Скала может и имеет некоторые специфичные решения и области применения, но вцелом она все еще полагается на экосистему Java. Самостоятельнось скалы под вопросом.
Если вы программируете геймерскую логику — хорошо. Но какая дальнейшая перспектива у этого языка? Какую серьезную конкуренцию он может составить тому же пайтону вне своей песочницы? А вот в его песочницу уже лезут JS и C# (Unity3d).
Мне очень нравится Kotlin и я желаю ему всего самого наилучшего. Но простой вопрос: что можно (будет) делать на Kotlin? Создатели утверждают: «то же самое, что и на Java (и также как на Java), только чуток лучше». Кроме того, по их словам, у Котлина не будет своего стека технологий, и что он всецело будет полагаться на джавовский (который в свою очередь далеко не идеален: либо кровавый энтерпрайз, либо спрингоподобные костыли). А раз так, то у людей возникает два вопроса: «стоит ли рисковать и подсаживать проект на Котлин?», и «а почему тогда не на Scala», которая уже имеет сформировавшийся стек?
Общая мысль такая, что язык сам по себе не несет большого смысла. Его можно рассматривать только вкупе: язык + целевые задачи + экосистема.
Если это не реклама книжек, то все очень поверхностно, а посему полемично. Самое основное — нет ни слова о целевой задаче и платформе для каждого языка.
Swift, благодаря политике Apple, никогда не вылезет из экосистемы iOS.
Scala — продвигается в основном теми, кому стала тесна Java, а посему всегда будет вторична к ней.
Lua — вы серьезно?
Go — в последнее время сильно пиарится Корпорацией Добра. Пытается отъесть кусок у системных сервисов, где царствуют Python и C/C++. Язык очень посредственный, но простой и работает.
Rust — да, интересный язык. И что дальше?
Что действительно перспективно:
Java останется еще очень долгое время столпом программирования: кровавый энтерпрайз, экосистема и все такое.
C/C++ как платформенные языки, тоже никуда не денутся.
ECMAScript/Dart/Typescript — никто не знает чем закончится конкуренция и что будет следующим стандартом де-факто для вебплатформы. Но ясно одно — это одна из самых востребованных областей в ближайшем будущем.
Колесо Сансары — хороший термин в плане, что периодически один технологический пузырь сменяет другой, но суть при этом не меняется. Колесу бизнеса нужно вертеться, а для этого нужно свежее мясо и мозги. Вот зреет очередной новомодный пузырь под названием БигДата. И на паровоз спешит куча инвесторов, провайдеров, аферистов, работяг, просто левых людей, желающих срубить бабла на подъеме. Тот же самый сценарий постоянно повторяется: пузырь доткомов сменил вебдваноль, затем бум социальных сетей, мобильных приложений. Теперь вот Бигдата. Разрекламируют идею, сформируют пищевую пирамиду, срубят бабла с бизнеса. Затем начнет все потихоньку загибаться: заказчики не сообразят как их бигданные сконвертировать в бигденьги, подоспеют юристы с исками о защите персональных данных и тайне частной жизни, запретными законами отреагируют правительства… и очередная пирамида рухнет.
Один из аргументов: вы видели десятиэкранные стектрейсы каких-нибудь больших приложений, где эксепшн по десять раз оборачивается и повторяется в Caused by"? При всем при том, что информативные строчки только последняя парочка, какой-нибудь NullPointerException at XXX. Все остальное по большому счету мусор.
Программируя функцию, Вы должны один раз определить, должна ли Ваша функция отлавливать низлежащие эксепшны, либо делегировать это вышестоящему коду. В случае unchecked exceptions второе делается без лишних деклараций.
С точки зрения логики кода в 99% случаев обработчик не классифицирует эксепшны. Ему вобщем-то пофиг, будет это ConfigParsingException caused by IOException или же сам IOException. Более того, в случаях, где это действительно необходимо, насильное заврапливание эксепшнов делает более трудоемким разбор причины: приходится проходится по всему getCause() и смотреть нет ли причины среди них.
И, да. Первый пункт. 9 из 10 людей, называющих себя программистави Java не понимают и умеют правильно готовить checked exceptions.
В идеальном сферически-конно-вакуумном мире это все смотрится отлично. В более-менее реальных задачах и проектах идеальная теория начинает буксовать. Начнем с того, что сам ООП патерн не есть венец творенья сего мира, а скорей некий отросток сбоку. Никто еще не доказал, что ООП лучше процедурного стиля, более того, имеются мнения, что все как раз наоборот.
Во-вторых, подход «тестировать каждый пук», в реальной задаче приводит к сильной атомизации кода. Простой и понятный метод дробится на кучу вспомогательных сущностей, которым бывает даже трудно дать вразумительное название и определить четко их назначение.
Кроме того, контекстно-зависимые задачи сложно бывает даже разбить на независимые куски, поскольку они постоянно обращаются к общему контексту и их выполнение зависит от его текущего состояния. Кто реализовывал задачу разбора синтаксиса, меня поймет.
Ну и, наконец, смысл? Есть дебаггер для отлова ошибочных ситуаций. Есть комплексный тест, который покрывает различные ситуации. Зачем дробить, тестировать по отдельности каждое действие, а затем их комбинацию, а затем и все вместе, если можно сразу протестировать все вместе? Общий тест точно также свалится. Ошибку можно откопать долбаггером.
Вроде бы не так давно прошел массовый апдейт WebView в Android, который теперь стал на движке Chromium. От старого он отличается особым умом и производительностью. Есть ли смысл ориентироваться на старый WebView?
Насчет translate и translate3d не уверен. Раньше везде для анимации рекомендовалось использовать translate3d вместо translate. Но теперь многие последние браузеры включают акселерацию для многих элементов автоматически. Поэтому при описании трюков полезно всегда указывать область применения: платформы и версии браузеров.
1. У дяди есть миллиард
2. Он уперт и ограничен. Не понимает процессов автоматизации. Любит покупать красивые и дорогие штучки из линии Websphere и подобных.
В этом случае имеет смысл использовать 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.
Ваши аргументы сводятся к вашему личному опыту сравнения с решениями, написанными по-ходу неквалифицированными программистами. И Вы делаете вывод, что виновато отсутствие 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
Кроме того, вызов сраного вебсервиса, реста или даже простого remote EJB нарушает всю JTA, т.к. вызов не координируется с remote-контейнером.
Все остальное делается лучше и проще без JEE. Отдельные части как JPA, Servlets доступны ввиде библиотек и фреймворков, к тому же есть over9000 схожих альтернатив. А микросервисная архитектура становится мейнстримом. И вроде как over9000 высоконагруженных проектов в интернетах живет и здравствует без JEE.
Тем не менее, клиент один раз потративший килодоллары на JEE платформу, хочет ее амортизировать и заставляет писать под нее. В этом случае действует четкое правило при работе с клиентом. Соглашаться на проект, если выполняются оба эти пункта:
1. Клиент с баблом
2. Он дебил
Если не выполнен первый пункт, смысла связываться нет — прогорите на поддержке. Если не выполнен второй — следует вразумить клиента, что есть более стабильные способы достижения результата, и что его задача — сконцентрироваться на самой проблеме, а не на способе ее решения.
1. тяжелые, значительно затрагивающие работу VM
2. средние, добавляющие в язык определенный функционал, но контролируемых на уровне компилятора
3. легкие — всякий синтаксический сахар
К первому типу будет относиться value types, если когда-нибудь вообще выйдут. За все время существования Java не было сделано столь серьезных изменений. Даже появление generics и лямбд фактически не затрагивало VM. Любую подобную фичу реализовать с гарантией обратной совместимости будет огромной проблемой. Придется решать сразу огромный круг задач из всевозможных областей, менять спецификации, JMM, валидатор кода, поддерживать на всех архитектурах, etc…
Второй тип — это все, что до сих пор делалось в Java. Тем не менее всегда проблемно что-то встроить, не поломав совместимости. С одной стороны у нас есть крутая фича, с другой — API Java и куча легаси-кода, который нужно мигрировать. Основной затык в лямбдах был именно встроить их в коллекции. Разработчики реально задолбались, в итоге выкинули все нахрен и сделали отдельно Stream. Даже такая простая вещь как unsigned тип поломает все и сразу: сериализацию, все библиотеки, работающие с рефлекшном, абсолютно все фреймворки, etc…
Сахар? Ну а как бы зачем? Семантически запись не меняется, лишь делается чуть короче, что не имеет большого смысла, т.к. сегодня IDE берет на себя всю нагрузку по печатанию кода. Посмотрите, какая полемика развернулась по поводу var. Так что импорты, литералы и прочее — это то, что меньше всего волнует.
Поэтому если вам нужна гибкость и плюхи, и вас не беспокоит, то, что через год-два ваш код не будет компилироваться или работать — всегда есть альтернативные JVM языки.
В данной схеме отсутствует важный элемент — certificate authority, который бы подтверждал, что ключ действительно от пользователя B, а не сгенеренный где-то посередине. Таким образом возможна банальная компроментация man-in-middle: отправляем пользователям A и B свои сгенерированные публичные ключи. Имея их настоящие ключи, проксируем весь треффик и наслаждаемся.
И самое натуральное место для подобной компроментации — это сам «Watsapp Server». Неужели под видом «end-to-end» вселяют пользователям ложную уверенность. А спецслужбы одобряют.
Я не против стейтрейсов. Стектрейсы — это лучшее, что отличает Java от других. Я против многократных оборачиваний эксепшнов и «перевыкидываний» (re-throw). Лучше получить единственный NullPointerException at XXX и далее стейтрейс, чем цепочку из «Caused by»…
> 9 из 10 людей не умеют правильно вскрывать пакетики-трубочки с сахаром
Спасибо! Век живи — век учись! :)
В данном случае преимущества unchecked в том, что справедливо правило: не умеешь — не берись. Тогда как checked обязует заловить себя, не объяснив новичку что с собой делать. А правильное решение, между прочим, очень нетривиально. И потом отловить на продакшне проблему становится практически невозможно.
Большинство из модных фич упрощают написание кода, но далеко не всегда упрощают разработку (включая тестирование, отладку, поддержку кода). Все новые и необычные фичи очень лениво и эпизодически используются девелоперами. Это делает их наличие в языке рудиментарным. Особенно когда есть более привычный стандартный подход к решению.
> Есть области применения, где вопрос Scala vs Java не стоит, т.к. Java просто не подходит.
То есть Вы хотите сказать, что существуют некоторые задачи общего назначения, которые можно решить на Scala и нельзя на Java? Навскидку (только не плагин для sbt)?
> взять Scala вместо/вместе с Java и получить бенефитов в виде возросшей продуктивности, мне в голову не приходит.
Почему-то все мыслят продуктивность исключительно в контесте написания кода: мой код короче, я пишу быстрее, поэтому я продуктивнее. Если взять качество кода, читабельность, простоту, сопровождение, тулинг, и совместную разработку, то все профиты резко уйдут в минус.
> Spark, Play или Akka.
Священная троица TypeSafe. Play и Akka изначально были написаны на Java и к Scala вообще не имели никакого отношения. Интерес к Play резко упал после того как к нему прилепили скалу и выпустили несовместимую ветку 2.x. Огромное количество тех, кто использует Play, до сих пор сидят на ветке 1.x и отказываются переходить, ибо разработка на 1.x в разы продуктивней, хоть и на Java. Spark ессно имеет API на Java. А вот чисто скаловский фреймворк — это Lift. Ну и много на нем пишут?
> Затрудняюсь назвать какие-либо Groovy
Gradle, например.
Общая мысль такая, что язык сам по себе не несет большого смысла. Его можно рассматривать только вкупе: язык + целевые задачи + экосистема.
Swift, благодаря политике Apple, никогда не вылезет из экосистемы iOS.
Scala — продвигается в основном теми, кому стала тесна Java, а посему всегда будет вторична к ней.
Lua — вы серьезно?
Go — в последнее время сильно пиарится Корпорацией Добра. Пытается отъесть кусок у системных сервисов, где царствуют Python и C/C++. Язык очень посредственный, но простой и работает.
Rust — да, интересный язык. И что дальше?
Что действительно перспективно:
Java останется еще очень долгое время столпом программирования: кровавый энтерпрайз, экосистема и все такое.
C/C++ как платформенные языки, тоже никуда не денутся.
ECMAScript/Dart/Typescript — никто не знает чем закончится конкуренция и что будет следующим стандартом де-факто для вебплатформы. Но ясно одно — это одна из самых востребованных областей в ближайшем будущем.
Программируя функцию, Вы должны один раз определить, должна ли Ваша функция отлавливать низлежащие эксепшны, либо делегировать это вышестоящему коду. В случае unchecked exceptions второе делается без лишних деклараций.
С точки зрения логики кода в 99% случаев обработчик не классифицирует эксепшны. Ему вобщем-то пофиг, будет это ConfigParsingException caused by IOException или же сам IOException. Более того, в случаях, где это действительно необходимо, насильное заврапливание эксепшнов делает более трудоемким разбор причины: приходится проходится по всему getCause() и смотреть нет ли причины среди них.
И, да. Первый пункт. 9 из 10 людей, называющих себя программистави Java не понимают и умеют правильно готовить checked exceptions.
Во-вторых, подход «тестировать каждый пук», в реальной задаче приводит к сильной атомизации кода. Простой и понятный метод дробится на кучу вспомогательных сущностей, которым бывает даже трудно дать вразумительное название и определить четко их назначение.
Кроме того, контекстно-зависимые задачи сложно бывает даже разбить на независимые куски, поскольку они постоянно обращаются к общему контексту и их выполнение зависит от его текущего состояния. Кто реализовывал задачу разбора синтаксиса, меня поймет.
Ну и, наконец, смысл? Есть дебаггер для отлова ошибочных ситуаций. Есть комплексный тест, который покрывает различные ситуации. Зачем дробить, тестировать по отдельности каждое действие, а затем их комбинацию, а затем и все вместе, если можно сразу протестировать все вместе? Общий тест точно также свалится. Ошибку можно откопать долбаггером.
Насчет translate и translate3d не уверен. Раньше везде для анимации рекомендовалось использовать translate3d вместо translate. Но теперь многие последние браузеры включают акселерацию для многих элементов автоматически. Поэтому при описании трюков полезно всегда указывать область применения: платформы и версии браузеров.