Да, приводит. Но не просто приводит, а явно заставляет реализовать метод для строкового представления логируемой информации, что уже является частью бизнес-логики приложения, а, следовательно, должно быть протестировано.
рекомендую использовать FastThread GUI для анализа
Ну, хз. Для каких-то своих проектов ещё можно подумать, но в каком-нибудь энтерпрайзе отправка внутрянки во внешние облака может сильно не понравиться безам. К проду-то не у каждого будет доступ, а тут просто взять и отправить во вне треддамп. Да и $10800 в год не сказать, чтобы дешёвое удовольствие.
Понятно. Теоретик. Судя по статьям в профиле, Вы питонист.
Что внутри ArrayDeque нагуглить с наскока не удалось
А зачем гуглить, если исходники классов стандартной библиотеки идут в комплекте с jdk? Но даже если jdk нет, то простой запрос четвёртой ссылкой выдаёт исходник на гитхабе. В котором мы видим, что внутри ArrayDeque, ВНЕЗАПНО, всё тот же массив.
А так я редко вижу его вне алгоритмических задач.
Потому что если спросить среднестатистического разработчика про фреймворк java-коллекций, то крайне редко вспоминают про очереди, прескорбно очень сие, но факт. Поэтому и не видно, потому что тупо не знают.
собрать из (почти) одних сорцов десктопное приложение в виде fat jar, Android-приложение, iOS приложение с помощью Graal Native Image и веб-приложение с помощью какого-нибудь транслятора Java->JS/WebAssembly, да ещё сервер рядом с ними положить в докер-образ вместе с нативными либами, то использование Maven превращается в АД.
Только звучит страшно, а на практике вполне решаемо, если, конечно, не упереться рогом в требование всю эту вакханалию в рамках одного артефакта собирать. Да, будет много модулей, вероятно, собираться будет долго. Но озвученная задача вполне решаема в рамках стандартных мавеновских фаз.
Кстати, да, часть исходников при этом генерится с помощью какого-нибудь ANTLR, а другая часть - Protobuf.
Кстати, для генерации исходников у мавена таки из коробки имеется отдельная фаза.
Когда один проект нужно собирать по-разному, то делается отдельный артефакт a-la my-project-dist, в котором assembly-плагином описываешь, что нужно получить в каждом дистрибутиве.
Integer totalAmount = successfulPayment.getTotalAmount(); // здесь 25000 // в базу запишем реальные 250 рублей, а не 25000 копеек double sum = (double) totalAmount / 100; // Учитываются к
Если деньги считаются в копейках минимальном номинале, то типом должен быть long.
Деньги и вещественные типы данных никогда не должны пересекаться. Вообще.
Тут ещё дело такое: то, что вы фасады не создаёте, не означает, что их нет. Просто они генерируются тем же спрингом: бизнес-логика - сервис, написанный руками и проаннотированный всякими @Transactional и иже с ним, инфраструктурный фасад - реальный класс бина во время исполнения кода, после наворачивания всей магии АОП.
Если сервисы бизнес-логики не пересекаются и не переиспользуются друг внутри друга, то аннотировать их @Transactional допустимо. Но надо точно понимать, что происходит во время исполнения кода.
Грубо говоря, правило такое: в стеке вызовов @Transactional-метод должен гарантированно встречаться лишь единожды. При несоблюдении сего простого правила, как минимум, появляется код, который лишь отапливает помещение серверной, проверяя перед вызовом методов, а открыта ли транзакция.
А понимание этого приходит сразу после того, как отключишь АОП и попробуешь руками, например, на TransactionTemplate написать всё то, что будет сгенерировано в прокси-классах.
Альтернативное решение — использовать аннотацию @Transactional на методе.
За такое надо бить по рукам железной линейкой. Можно даже ребром. Никогда, никогда репозиторный метод не должен заниматься транзакциями.
Равно как и сервисный слой бизнес-логики. Транзакции должны рулиться в инфраструктурных фасадах, иначе будет неподдерживаемая лапша кода.
Самое печальное - транзакции на репозиториях сделаны из коробки в spring-data, но, вместо логичного @Transactional(propagation = MANDATORY), там простой @Transactional.
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом.
Да, приводит. Но не просто приводит, а явно заставляет реализовать метод для строкового представления логируемой информации, что уже является частью бизнес-логики приложения, а, следовательно, должно быть протестировано.
Ну, хз. Для каких-то своих проектов ещё можно подумать, но в каком-нибудь энтерпрайзе отправка внутрянки во внешние облака может сильно не понравиться безам. К проду-то не у каждого будет доступ, а тут просто взять и отправить во вне треддамп. Да и $10800 в год не сказать, чтобы дешёвое удовольствие.
Методика проста: фреймворк должен быть лишён фатального недостатка.
Или так
Понятно. Теоретик. Судя по статьям в профиле, Вы питонист.
А зачем гуглить, если исходники классов стандартной библиотеки идут в комплекте с jdk? Но даже если jdk нет, то простой запрос четвёртой ссылкой выдаёт исходник на гитхабе. В котором мы видим, что внутри ArrayDeque, ВНЕЗАПНО, всё тот же массив.
Потому что если спросить среднестатистического разработчика про фреймворк java-коллекций, то крайне редко вспоминают про очереди, прескорбно очень сие, но факт. Поэтому и не видно, потому что тупо не знают.
Преждевременная оптимизация - корень всех бед. Доказательства будут?
Можно, но зачем? Если имеется готовый
java.util.ArrayDeque?Потому что стэк - это LIFO-очередь, чем, собственно, Deque и является.
Потому что в java.util.Stack присутствует ненужная в данном случае синхронизация, что сказывается на производительности.
Я просмотрел или ссылки на итоговый код нигде не представлено?
Просто в России действительно проще найти место, в котором
будут поля, леса, луга. Просто тупо потому, что территория страны позволяет.
Только звучит страшно, а на практике вполне решаемо, если, конечно, не упереться рогом в требование всю эту вакханалию в рамках одного артефакта собирать. Да, будет много модулей, вероятно, собираться будет долго. Но озвученная задача вполне решаема в рамках стандартных мавеновских фаз.
Кстати, для генерации исходников у мавена таки из коробки имеется отдельная фаза.
Когда один проект нужно собирать по-разному, то делается отдельный артефакт a-la my-project-dist, в котором assembly-плагином описываешь, что нужно получить в каждом дистрибутиве.
Блокирующая очередь как-то не очень сочетается с реактивным стеком.
Итить
Если деньги считаются в
копейкахминимальном номинале, то типом должен бытьlong.Деньги и вещественные типы данных никогда не должны пересекаться. Вообще.
Потому что #каквсбере.
Очевидно, что нужно их добавить, нет?
Тут ещё дело такое: то, что вы фасады не создаёте, не означает, что их нет. Просто они генерируются тем же спрингом: бизнес-логика - сервис, написанный руками и проаннотированный всякими
@Transactionalи иже с ним, инфраструктурный фасад - реальный класс бина во время исполнения кода, после наворачивания всей магии АОП.Если сервисы бизнес-логики не пересекаются и не переиспользуются друг внутри друга, то аннотировать их
@Transactionalдопустимо. Но надо точно понимать, что происходит во время исполнения кода.Грубо говоря, правило такое: в стеке вызовов
@Transactional-метод должен гарантированно встречаться лишь единожды. При несоблюдении сего простого правила, как минимум, появляется код, который лишь отапливает помещение серверной, проверяя перед вызовом методов, а открыта ли транзакция.А понимание этого приходит сразу после того, как отключишь АОП и попробуешь руками, например, на
TransactionTemplateнаписать всё то, что будет сгенерировано в прокси-классах.За такое надо бить по рукам железной линейкой. Можно даже ребром. Никогда, никогда репозиторный метод не должен заниматься транзакциями.
Равно как и сервисный слой бизнес-логики. Транзакции должны рулиться в инфраструктурных фасадах, иначе будет неподдерживаемая лапша кода.
Самое печальное - транзакции на репозиториях сделаны из коробки в spring-data, но, вместо логичного
@Transactional(propagation = MANDATORY), там простой@Transactional.Смешались в кучу
Кони, люди...
https://ru.wikipedia.org/wiki/REST
Надо было такой
Судя по количеству приседаний, необходимых для того, чтобы всё это великолепие взлетело, не вижу профита по сравнению с нативными запросами.