Да, интересный пример. Собственно Integer это специальный класс, а не базовый тип "int", чего в не "managed" языках совсем нет, поэтому те, кто не работал с этим и недоумевают.

С другой стороны, по опыту участия в собеседованиях, обращал внимание, что не все программисты java/c# понимают в чем разница ref-типа (объекты в managed куче) и value-типы - это те, которые базовые типы и простые структуры не хранящиеся в куче и передающиеся по значению.

Вроде про различие value- и ref-типов написано в каждой книжке по языкам в первой-второй главе.
А вот про то, что boxed значения можно создать заранее и возвращать готовыми - особенность реализации, до которой сходу и не додумаешься.

Так это-то понятно, и что "fsck"=="fsck" в общем случае false (хотя возможны и исключения) я понимаю. Но что Integer может оказаться не "базовым типом, передаваемым по значению", а чем-то более сложным - для меня как-то неожиданно.

Integer vs int, ага?
Надеюсь, к 8-ой яве изведут базовые типы вообще, ненужны они.

Ага. Особенно если сравнить расход памяти на массив intов и Integerov.
ЕМНИП, на 64битной машине разница будет в четыре раза.

компилятор может автоматически анбоксить, в принципе.

В выражениях может. А при создании не может.
Потому как ему неизвестно, нужен тут примитив, или таки кто-то хочет как объект использовать.

Это решаемая задача. Как и скорость выполнения.

Каким образом? Поставить больше памяти?

Вы себе не представляете, на что способны современные JIT'ы.

Забить на спецификацию языка?
Или он действительно не будет создавать служебную информацию класса, пока кто-то к ней не обратится?

Именно. Делаем эксепшн на slow path, если туда таки сунуться — ну, генерим заголовки. Если не сунуться — всё быстро.

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

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

Да, с .equal() конкретный продолб, тут тоже спорить не буду.

Ага.
А потом ещё добавят ДЕФАЙН и отменят автоматическое освобождение памяти.
И получится Це Плюс Плюс.

Вот я и не ожидал, что Integer - не базовый тип. Казалось бы - зачем делать "объект" типа "целое число", чего такого может быть в этом объекте, чего не умеет базовый тип "int"?..

например запихиваться в контейнеры, которые умеют работать только с объектами.

Куча разной служебной информации.
Как бонус :) возможность положить в коллекцию или присвоить null.

Это удобный wrapper class, там много разных полезных методов.

Например, можно написать так:

String a = "400";
int b = Integer.parseInt(a);

И не мучаться с парсингом другого типа данных.

Статические методы можно без экземпляра вызвать. Т.е. для этого не нужно создавать Integer.

Я и не создавал.

Я к тому, что для сервисных методов не обязательно иметь именно класс Integer.
Можно поместить их в любой IntUtil, который сам по себе не будет представлять целое число.

Главное - это превращение в объект. Все объекты в подобных языках имеют одного предка с некоторым набором стандатных методов. Как верно заметили - таким образом можно организовывать полиморфные контейнеры не прибегая к шаблонам/дженерикам. Для подобных преобразований ref-type <-> value-type есть специальная терминология boxing/unboxing.