Почему Ваш тип данных оператора переключения не может быть долгим, Java?

Потому что они не реализовали необходимые инструкции в байт-коде, и вы действительно не хотите писать так много случаев, нет независимо от того, насколько "готов к производству" ваш код ...

[РЕДАКТИРОВАТЬ: извлечено из комментариев к этому ответу, с некоторыми фоновыми дополнениями]

Если быть точным, 2³² - это много случаев, и любая программа с методом, достаточно длинным, чтобы вместить больше этого, будет просто ужасной! На любом языке. (Самая длинная функция, которую я знаю в любом коде на любом языке, чуть больше 6k SLOC - да, это большой переключатель - и он действительно неуправляем.) Если вы действительно застряли с ] long , где у вас должно быть только int или меньше, тогда у вас есть две реальные альтернативы.

1. Используйте какой-нибудь вариант на тему хеш-функций, чтобы сжать long в int . Самый простой способ, который можно использовать только тогда, когда у вас неправильный тип, - это просто приведение! Более полезным было бы сделать это:

    (int) ((x & 0xFFFFFFFF) ^ ((x >>> 32) & 0xFFFFFFFF)) 
    

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

2. Гораздо лучшим решением, если вы работаете с очень большим количеством кейсов, является изменение вашего дизайна на использование Map или чего-то подобного, чтобы вы узнали, как отправить определенное значение.Это позволяет вам разделить дела на несколько файлов, что намного проще контролировать, когда количество дел становится большим, хотя становится сложнее организовать регистрацию хоста задействованных классов реализации (аннотации могут помочь, позволяя вам создать регистрационный код автоматически).

   FWIW, я сделал это много лет назад (мы перешли на недавно выпущенный J2SE 1.2 в ходе реализации проекта) при создании собственного механизма байт-кода для моделирования массивно параллельного оборудования (нет, повторное использование JVM было бы неприемлемым из-за к радикально отличающимся моделям значений и исполнения), и это значительно упростило код по сравнению с большим переключателем , который использовала версия кода на языке C.

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

Потому что индекс таблицы поиска должен быть 32 бита.

Long в 32-битных архитектурах представлен двумя словами . Теперь представьте, что могло бы случиться, если бы из-за недостаточной синхронизации выполнение оператора switch наблюдало бы long с его старшими 32 битами от одной записи, а 32 младшими - с другой! Он мог бы попытаться попасть в .... неизвестно куда! В основном где-то наугад. Даже если обе записи представляют допустимые случаи для оператора switch, их забавная комбинация, вероятно, не приведет ни к первому, ни ко второму - или, что еще хуже, это может привести к другому допустимому, но не связанному с ним случаю!

По крайней мере, с int (или меньшими типами), независимо от того, насколько сильно вы ошиблись, оператор switch по крайней мере прочитает значение, которое кто-то на самом деле написал , вместо значения "из тонкого" воздух".

Я, конечно, не знаю истинной причины (прошло уже более 15 лет, я так давно не обращал внимания!), Но если вы понимаете, насколько небезопасной и непредсказуемой может быть такая конструкция, вы » Я согласен с тем, что это определенно очень веская причина , чтобы никогда не включать longs (и, как и предполагалось, long -pun - будут 32-битные машины, эта причина останется в силе) .