Да, вы можете засунуть несколько аннотаций в одну и использовать только ее. И что самое интересное - да, вы можете передавать аттрибуты в аннотации которые вы объединили (передавать атрибуты в мета-аннотации). Как это сделать? Очень просто!  Создать аннотацию Аннотировать ее всеми аннотациями, которые необходимо скомпоновать Пометить аннотацией @AliasFor аттрибуты, которые необходимо передать в группируемые аннотации ВЫ ПРЕКРАСНЫ! Таким образом, это пиршество для глаз (это, кстати, всего один метод контроллера): Превращается вот в такую скромную, но удобную композицию: Для примера используются аннотации Swagger'а для документации REST API Spring Boot приложения. В процессе создания документации  для Swagger'а я ужаснулся от того насколько нечитаемыми стали контроллеры (пример смотри выше). В следствие беглого анализа проблемы стало очевидно, что описание большинства эндпоинтов мало чем отличается друг от друга. Но. Отличается! Возникла идея создать одну аннотацию (to rule them all), в которую можно было бы просто передавать нужные нам аттрибуты, и тем самым, менять структуру аннотации. Звучит как-то стремно, знаю, выше есть пример того, что я хотел получить в итоге. А вот с реализацией внезапно и абсолютно неожиданно возникли проблемы. Даже ответ на простой вопрос - "как обьединять аннотации?" оказалось не просто найти. Интернет, похоже, умеет обьединять только "стандартные" @Overrideи @Deprecated... Вот тут все просто - Собираем все нужные нам аннотации и аннотируем ими свою кастомную. Теперь на все места, где надо прописывать эти аннотации, нам достаточно поставить ее одну. Пример: Теперь вместо постоянной вставки трех строк @ApiResponce достаточно поставить одну аннотацию @AuthRequired! Такое решение может показаться вполне приемлемым. Но оно все еще не идеально... Мы все еще не можем управлять аннотациями в случае, если нам необходимо что-то поменять (например описание ошибки). Сразу еще один пример: Благодаря аннотации @AliasFor мы можем использовать аттрибут "myCustomAnnotationSummary" нашей кастомной аннотации , как аттрибут "summary" аннотации @Operation! То есть, при использовании нашей аннотации @AuthRequired(myCustomAnnotationSummary = "Some text for representation") мы как бы применяем аннотацию @Operation(summary = "Some text for representation") в дополнение ко всем остальным скомпанованным аннотациям. На самом деле возможности @AliasFor чуть более глубокие: Таким образом мы можем передавать аттрибут в сколько угодно n*мета-аннотацию! В случае использования значения default - будет использовано значение непосредственно той аннотации, котрая будет использована в коде. Аттрибут переданный качестве аргумента конструктора промежуточной аннотации в таком случае будет проигнорирован! К сожалению у такого подхода есть ограничение - невозможно передать аргумент в сущность внутри мета-аннотации: В указанном выше примере передать @Schema(implementation = ErrorRs.class) непосредственно в аннотацию @ApiResponse не получится, несмотря на то, что мы указали аннотацию @Content. Для осуществления такого взаимодействия необходимо передать в@ApiResponse полную сущность, если можно так выразиться. Такие конструкции, к сожалению, трудно читать и еще труднее поддерживать. Но, при осторожном использовании, компановка аннотаций - это невероятно удобный инструмент реализованый в Spring. А с применением аннотации @AliasFor возможности для компонования кода становятся воистину потрясающими.  Дорогой читатель! Искренне благодарю тебя за уделенное мне время. Всего тебе самого хорошего! X)) P.S.: Основной задачей этого очерка было продемонстрировать возможное решение проблемы и представить примеры применения аннотации @AliasFor которых, на мой взгляд, в сети маловато... На мой неопытный взгляд такой способ группировки аннотаций экономит целую кучу времени. Ну и самое главное - код становится значительно более читаем.  UPD: Все вышеперечисленные методы доступны только в Spring!   Начинающий Java разработчик