Конечно я предложу свой вариант, а ещё объясню, что прочитав такое название понять «что делает тест и зачем он это делает» гораздо быстрее чем тратить время на переходы в основной код. Это помогает не тратить время в будущем, угадывая мысль автора каждый раз.
Вы как будто с самим собой поспорили и с самим собой согласились =)
Регламенты и документация это как правильно про решение «делаем» и меньше всего про ответы на вопросы «зачем» и «почему» именно так делаем. Вы как будто не встречались с людьми когда говорите про одно и тоже, но у каждого свой взгляд. Как результат вы друг друга не понимаете и снова и снова возвращаетесь к одному и тому же вопросу:
(PR: code review)
— «Нужно исправить и написать нормальное название метода»
— «Оно и так нормальное»
— «testFileSerializer это ненормальное название»
— «А какое нормальное? Вроде бы ок, меня устраивает. Мы же сериализатор файла протестировали там»
… (немая сцена и занавес)…
Как объяснить свой взгляд другому человеку? Добавить чуть больше воды, объяснений, привести пример с вымышленным сотрудником… Так статья и получилась.
Например я получил опыт такой работы и он тоже интересный. Как минимум я могу дать ответы на вопросы, а не теоритизировать «почему так надо» или «почему так не надо». Что плохого-то? =) Ни-че-го.
Потому что могут быть решения, что на Java используется «такой-то» технический стек, а при замене ЯП никто не готов и стек полностью заменить. Для этого нужно время, апробирование на внутренних тестовых сервисах. Нельзя так просто вылить в прод новый сервис когда у остальной команды нет тех. экспертизы для его поддержки.
И да, Spring Framework, Hibernate и прочие из мира Java EE писались именно под особенности языка Java SE. Так как у Kotlin другая философия то приходится применять плагины, не меняя в остальном работу с Kotlin.
Фреймворки-то не изменить уже, работаем с тем что есть.
Время пройдёт, возможно будут заменены и фреймворки, уже написанные под Kotlin.
Ваша правда, что появление Обощённого/Шаблонизированного кода в Java SE хоть и было отложено от версии 1.0 в 1995, но решение в Java SE 5.0 было почти без боли. Раздосадованными конечно остались те кто был не доволен, что оно работает только на этапе компиляции, а не во время исполнения.
Та или иная форма нигилизма присуща человеку. Мы строим окружение вокруг себя годами выбирая/отфильтровывая/обустраивая всё таким образом, чтобы именно нам было комфортно. Тот кто любит политику собирает людей, которым эта тема тоже близка. Тот кто любит изучать новые ЯП собирает вокруг себя людей, которые горят этой же страстью. Часто таким «сообществам» очень сложно принять другую точку зрения.
Утверждение, что IT-тусовка часто состоит из интровертов трудно оспорить так же как и не стоит отрицать, что в ней достаточно много экстровертов, которым важно не сидеть дома. Жителям мегаполисов, с большой инфраструктурой логистики, не близки проблемы людей из маленьких городов, а вторым кажутся странными проблемы первых. Один из примеров: «Какой нормальный человек будет на работу добираться 1 час и более?»
Не становитесь ханжой и не отрицайте возможность проблем другого человека если у Вас их нет.
Ни сколько не привычно. Если сотрудник хотел работать из дома то он изначально бы искал себе именно такую работу. В таком случае мало что в его работе изменилось.
— Хотя уж казалось бы, там-то что можно сломать?
Это Jigsaw, класс Unsafe и Reflection, чтобы не получали доступ к тому, что не было запроектировано.
Проект Jigsaw ломает доступ к использованию непубличного API. Поэтому сравнение с Java SE 5 некоректно. Когда получилось проект влить в релиз — тогда и сделали. Так совпало, что всё это попало в Java SE 9, а могли и в 8 уже всё это увидеть при определённой развитии истории.
Стабильность это LTS: Java SE 8, 11, 17. Все другие выпуски проходные и мне непонятно зачем крутить счётчик 2 раза в год. Зря отказались от версионирования как в Ubuntu.
Не описан вариант, когда сообщение попадаёт в dead_letter_queue из-за ошибки в формате самого сообщении. В таком случае оно будет утеряно после нескольких попыток возврата в Consumer?
Потому что они не нужны в поставке Java SE и были добавлены по ошибке, что показала история. Спецификации JAX-WS и JAXB всегда относились к Java EE и актуальность реализаций стала сильно отставать.
nerumb вы не уточнили затрченное время на исполнение запросов в последних примерах.
Spring MVC ~ 700мс,
Spring MVC + CompletableFuture ~ 360мс,
Spring WebFlux ~? мс,
Spring WebFlux + Coroutines ~? мс
Исходя из логики повествования она будет так же примерно равна 360мс так как вы делаете акцент на пропускной способности:
наш сервис только лишь рассылает запросы в другие сервисы. Выделять под это целый поток и блокировать его, пока не придут ответы от всех, выглядит, мягко говоря, излишним.
Habr! Предлагаю к каждому посту о Spring Framework прикреплять список статей, которые уже были написаны ранее. Каждый год появляется много дублирующей информации, которую авторы не ищут в истории, а пишут сызнова. Парадокс.
Это вопрос к автору книги. В JSE всё новое дополняет имеющееся. Вы же не будете против, чтобы чуть большая аудитория узнала пакет java.util.concurrent лучше чем знает сейчас?
Oracle действительно ведёт себя глупо. Глупо потому что ради цели заставить Google подписать лицензию, они стали пробовать разные тактики: «приводить куски кода, которые 1 к 1 были/есть в Sun/Oracle JDK». После того как это не получилось пошли по пути «вы украли весь наш API», который опасен прецендентым правом и может в будущем выйти боком всему рынку IT.
Не глупо здесь только одно, желание заработать на труде, вложенном в развитие API, развитие платформы Java силами Sun и уже самого Oracle.
Регламенты и документация это как правильно про решение «делаем» и меньше всего про ответы на вопросы «зачем» и «почему» именно так делаем. Вы как будто не встречались с людьми когда говорите про одно и тоже, но у каждого свой взгляд. Как результат вы друг друга не понимаете и снова и снова возвращаетесь к одному и тому же вопросу:
(PR: code review)
— «Нужно исправить и написать нормальное название метода»
— «Оно и так нормальное»
— «testFileSerializer это ненормальное название»
— «А какое нормальное? Вроде бы ок, меня устраивает. Мы же сериализатор файла протестировали там»
… (немая сцена и занавес)…
Как объяснить свой взгляд другому человеку? Добавить чуть больше воды, объяснений, привести пример с вымышленным сотрудником… Так статья и получилась.
и вы вставляете такой текст с названиями методов 'filterByDateCreated', 'filterByCategory'. Это плохие имена методов.
Глагол 'filter' не отвечает на вопросы «кто» и «что тестируется». Прибавка «ByDateCreated» не даёт мне нужной информации.
И да, Spring Framework, Hibernate и прочие из мира Java EE писались именно под особенности языка Java SE. Так как у Kotlin другая философия то приходится применять плагины, не меняя в остальном работу с Kotlin.
Фреймворки-то не изменить уже, работаем с тем что есть.
Время пройдёт, возможно будут заменены и фреймворки, уже написанные под Kotlin.
Утверждение, что IT-тусовка часто состоит из интровертов трудно оспорить так же как и не стоит отрицать, что в ней достаточно много экстровертов, которым важно не сидеть дома. Жителям мегаполисов, с большой инфраструктурой логистики, не близки проблемы людей из маленьких городов, а вторым кажутся странными проблемы первых. Один из примеров: «Какой нормальный человек будет на работу добираться 1 час и более?»
Не становитесь ханжой и не отрицайте возможность проблем другого человека если у Вас их нет.
Это Jigsaw, класс Unsafe и Reflection, чтобы не получали доступ к тому, что не было запроектировано.
Проект Jigsaw ломает доступ к использованию непубличного API. Поэтому сравнение с Java SE 5 некоректно. Когда получилось проект влить в релиз — тогда и сделали. Так совпало, что всё это попало в Java SE 9, а могли и в 8 уже всё это увидеть при определённой развитии истории.
Стабильность это LTS: Java SE 8, 11, 17. Все другие выпуски проходные и мне непонятно зачем крутить счётчик 2 раза в год. Зря отказались от версионирования как в Ubuntu.
Исходя из логики повествования она будет так же примерно равна 360мс так как вы делаете акцент на пропускной способности:
Не глупо здесь только одно, желание заработать на труде, вложенном в развитие API, развитие платформы Java силами Sun и уже самого Oracle.