Вадя [игнорируется] 

Поскольку как трактовать то что лежит Union решает сам пользователь то непосредственно на уровне языка java из-за автоматической сборки мусора полноценного аналога union никогда не появиться. Вообще никогда. Ведь сборщику критично важно знать что же в коком-то филде конкретно лежит ссылка ли на другой объект(который дальше нужно просканировать) или просто long по поводу которого можно не париться.

На уровне же API как-то поизвращаться можно в ограниченных масшатбах. Самый простой способ создаешь массив байт и трактуешь его как хочешь, вместо массива байт можно использовать ByteBuffer, либо MemorySegments из Java17, в любом из трёх вариантов ты ограничен тем, что из байтиков ты ссылку на объект получить не можешь ибо нет арифметики указателей, да и указателей по сути тоже.

Тот кто знает как ускорить HashMap в 3-4 раза может смело прямо сейчас открывать с ноги двери в офис оракла и класть им на стол своё резюме. Кстати интересно почему не в 10 или не в 2? Не обладая контекстом вам этого никто не скажет. Откуда мы знаем с какой целью вы в мапу что-то кладёте, а потом дастаёте, может если хорошенько разобраться её здесь можно заменить вообще ни на что, тобишь отрефакторить код, коллекцию вообще нафиг удалить и заменить на полиморфный вызов или в крайнем случае двойную диспетчеризацию, либо как писали выше на switch.

Ну тогда вам нечем особенно заменить HashMap, поиск одного отдельно взятого элемента в ней быстрее чем в префиксном дереве и чем в TreeMap, а вы как раз только с поиском одного элемента и сталкиваетесь.

Но вот если сменить тип у константы которую вы сопоставляете каждому методу, а именно со String на int, то можно вместо HashMap<String, MyInterface> metaMap прийти к MyInterface[] metaArray, то есть каждая константа это индекс в массиве, тогда все серьезно ускориться.

Что он обозначает? Почему на его месте не может быть int?

В жабоскрипте тоже можно иметь именованный константы.

А тебе в любом случае нужно поддерживать согласованость констант на бэке и на фронте, являются константы строками или числами никакой принципиальной роли не имеет, две разные кодовые базы неизбежно ведут к двойной работе. Тоже вариант, если речь идёт про обработку HTTP запроса, то один поиск в мапе это ничто, это пыль, можно не париться.

Если у тебя станет радикально много HTTP запросов, то всё сляжет не из-за того ты один раз на протяжении обработки одного HTTP запроса в мапе что-то поищешь.

Ежели взять абстрактного коня в вакууме в отрыве от бэкенда, то при проектировании системы констант, для ускорения поиска по константе их делают всегда числовми и ищут по смещению массиве. Если обратишь внимание к примеру на сериализацию в Hazelcast или Coherence, то там для пользовательских типов предусмотренны именно числовые константы.