Спасибо за статью и библиотеку, но есть предложение. Не хочется при assert завязываться на имя индекса — лучше завязаться на поля таблиц, которые используются в запросе и проверять наличие этих полей в используемом индексе. Типо, assertIsColumnExistsInIndexIntoExecutionPlan :-)

Тут есть интересный момент. Аннотации то можно взять, но JPA2 помимо аннотаций несёт ещё контракты этих аннотаций. А если нужна лишь малая часть функционала, то реализовывать всё, что требует JPA не рационально. А если не реализовать, то можно ввести пользователя этой библиотеки в заблуждение :-)

Рассматривали ли Вы реализацию шины на Spring Integration? Хотелось бы сравнить двух этих монстров

А какие сообщения об ошибках будут уходить в ответе? Хотелось бы взглянуть

А разве dbms_pipe работает между разными нодами Oracle RAC?

Соглашусь с Вами. Но многие начинающие специалисты не лезут внутрь сложных концепций и это печально.

К сожалению, это современная тенденция разработки. Берем Spring Boot, делаем что-то дома и идем на собеседование на Senior Java Developer. Если у собеседующего такой же опыт со Spring Framework, то собеседование пройдено. А если собеседующий начнет ходить вокруг всего, то печаль-беда для кандидата :)
Но если есть понимание как это все работает, то тут соглашусь с автором, что Spring Boot позволяет получить каркас приложения очень быстро.

Только хотел написать про Spring Boot, но Вы меня опередили :).

Не нравится мне этот тест. Он создает и использует StringBuffer внутри метода. В этом случае, по идее, даже и блокировок создавать JVM не нужно. Потому что ссылка на объект не «вылезет» никуда.

Извиняюсь, что-то впарился. Отключил «прогрев» JVM в бенчмарках JHM. После этого StringBuilder начал чуть-чуть выигрывать у StringBuffer'а. Как раз таки StringBuffer сдал немного из-за времени на оптимизацию блокировок.

В JVM синхронизация через synchronized оптимизирована хорошо. При захвате блокировки одним и тем же потоком, потери производительности минимальны, а то и совсем отсутствуют. А ведь в большинстве своём StringBuffer используется в одном потоке. Соответственно, потери производительности от использования StringBuffer в сравнении с StringBuilder минимальны, а то и совсем отсутствуют.
Как-то еще сравнивал JHM'ем StringBuffer vs StringBuilder. Результаты меня поразили. StringBuffer оказался быстрее на очень маленькое значение.

Немного не нравится мне Ваш пример. Как правило вводят ограничение на количество операций в какой-то промежуток времени.
Есть в Ignite что-нибудь для ограничения одновременного выполнения в минуту/час/день?

Поддерживаю Вас. Статья «ниочем».

Да

Запрессовать гильзой

Т.е. при изменении схемы данных все старые логи теряются?

Не совсем понятно зачем так все усложнять?
Я подобное делал с помощью спринга.
Помечаем Ваши команды не аннотацией Command, а

@Component("greet")
public class GreetingCommand implements CommandHandler {

    @Override
    public void handle() {
        System.out.print("Hi! How are you?");
    }
}

и инжектим все это куда-нибудь.

public class CommandProcessor {

    @Autowired
    private Map<String, CommandHandler> handlers = new HashMap<>();
}

Можно и новую аннотацию сделать. Вариантов куча.
В своих проектах использую lombok — рад, как слон.

Очень хороший вопрос. Надеюсь, что у автора в БД лежит все в UUID. Когда я делал подобное, тоже сначала все в VARCHAR сделал. После переделал на UUID.
Я заметил, что у UUID есть как минимум 2 преимущества перед VARCHAR:
1) UUID занимает меньше места. Размер базы после перехода на UUID уменьшился на ~5Gb.
2) По UUID индексу поиск происходит чуть быстрее.
Хотелось бы почитать Ваше мнение о преимуществах UUID перед VARCHAR.
Спасибо.