Почему байтовое и короткое деление приводит к int в Java?

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

Например, спецификация i386 гласит:

ADD выполняет целочисленное сложение двух операндов (DEST и SRC). Результат сложения присваивается первому операнду (DEST) и соответственно устанавливаются флаги. Когда непосредственный байт добавляется к операнду в виде слова или двойного слова, непосредственное значение расширяется по знаку до размера операнда в виде слова или двойного слова.

Это означает, что внутри любое значение байта расширяется до целого числа (или аналогичного). Ведь это разумно, т.к. процессор 32/64 бит и тогда любые арифметические операции выполняются в этих размерах. Если бы можно было производить арифметические действия в байтах, это, как правило, не считалось бы полезным.

Спецификации JVM говорят, что (для дополнения) у вас есть: iadd, ladd, fadd, dadd. Это просто отражает тот факт, что базовые машины обычно ведут себя именно так. Любой другой выбор мог быть возможен, вероятно, ценой снижения производительности.

byteA, разделенный на byteB, не может быть ничем иным, как байтом, не так ли?

Это может быть не byte :

byteA = -128;
byteB = -1;
int div = byteA/byteB; // == 128, not a byte

Я считаю, что оправдание в том, что простые правила вызывают наименьшее удивление. Результатом всегда является более широкий тип из двух (минимум int), он не зависит от операции.

Лучшим подходом может быть всегда расширение +, *, -, если явно (или, возможно, неявно) не сужено. т. е. не делайте переполнения или недополнения, если вы не используете приведение. Например, / всегда может быть операцией double или long, если только она не приведена.

Но C и, следовательно, Java этого не делают.

Короче говоря, у него есть одно простое правило, чтобы справиться с этим, хорошо это или плохо.

См. мои разглагольствования здесь http://vanillajava.blogspot.co.uk/2015/02/inconsistent-operation-widen-rules-in.html

Я предполагаю, что-то, что было заимствовано из C, возможно, через C++.

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

Хотя в Java это не слишком пагубно. (В C и C++ это может застать вас врасплох: умножение двух больших unsigned short может переполнить int, поведение которого не определено.)

Обратите внимание, что если один из аргументов больше int, то тип выражения является самым большим из типов аргументов.

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

Это означает, что это может быть только число в диапазоне байтов (от -128 до 127).

Однако при вводе выражения, например. byteA/byteB, что отличается от ввода литерала, например. число 127.

Такова природа Java: integer является типом данных по умолчанию, используемым для целых чисел.

По умолчанию, когда вы выполняете назначение выражения, Java преобразует его в тип данных по умолчанию (целое число), несмотря на то, что результатом выражения может быть допустимое значение для байта.

Итак, что происходит, когда вы определяете байт и назначаете выражение в качестве значения этого байта, Java нужно будет преобразовать его в целое число:

int byteAByteB = byteA / byteB;

Однако вы можете обойти это, приведя назначенное выражение и, таким образом, заставив Java рассматривать его как байт.

byte byteAByteB = (byte) (byteA / byteB);

Таким образом, вы говорите Java рассматривать это как байт. (Также можно сделать с короткими и т.д.)