String — это не primitive type

вау, юникод в идентификаторах, омфг!

Нет, в Java объявление String x = «a» равносильно string& x = «a» в С++ по сути. То есть при присвоении переменной будут скопированы только ссылки на них, но не содержимое.

если там не будет бросаться исключение на b += 1;, то это капец

Обычное дело

Поясните пожалуйста человеку, не знакомому с жабой, с какого перепугу там false?

Если коротко, то в в Java нельзя использовать оператор == для сравнения значений комплексных объектов. Только o1.equals(o2). По == сравниваются не значения, а сами объекты и для чисел в общем случае это объекты разные, хоть и несущие одно значение. А вот младшие 128 Integer (до байта) кешируются и указывают на один объект.

И ещё кто-то говорит, что С и С++ - сложные, непонятные, неинтуитивные языки со страшной «работой с памятью» :)

== сравнивает ссылки, а не сами объекты, а это в принципе undefined behaviour (ну может и defined, но я уже не помню как).
правильно надо было писать a.equals(b).

short number between -128 and 127

Нетрудно было догадаться, что связано с шорт интом ^^

Дополнительная особенность целочисленных «классов-оберток» созданных автоупаковкой констант в диапазоне -128 +127 , в то что они кэшируются JVM. Потому такие обертки с одинаковыми значениями будут являтся ссылками на один объект.

Только не забывайте, что "-128" .. «+127» это конфигурируемые величины и их легко можно изменить при необходимости.

Вообще я в своё время просто разобрался, как работает авто(ан)боксинг и всё. Там всё просто. Integer x = 2 === Integer x = Integer.valueOf(2), а дальше лезем в JDK и смотрим, как реализована эта функция. И вся магия исчезает.

абсолютно предсказуемое поведение.

я, не глядя в вывод, сразу догадался, что в каждой строчке будет либо true, либо false

вау, юникод в идентификаторах, омфг!

Ага, а потом загадочные приколы:

int c = 1, с = 2;
c = c + с;
// c = 3