mayton....
Я вот недавно почитал про Котлин. Если не панацея - то вполне себе решение
подобных вопросов. Safe Calls. Elvis Operator.

https://kotlinlang.org/docs/reference/null-safety.html
iMHO Вполне изяшно.
Могли бы и в Java добавить (((

mayton...Для себя пока делаю вывод что Optional не влияет на производительность....

Мусор в Heap на современных процессорах начинает влиять, когда у нас сервер + несколько клиентов + требуемые совокупный eden за 1-2 Gb перебирается (((

Тогда уже тущите свет. Пауза в GC становится заметной и eden уже не увеличить.

Возможно G1 коллектор спасение. Но когда я с таким стакивался, G1 еще только появлялся.

IMHO & AFAIK

В одно потоковом варианте - мусор живет в eden и никого особо не беспокоит
В много пользовательском выполнение - если eden не хватает, мусор пробирается в Heap. И тут уже начинаются жалобы "Java плохой язык, все тормозит, давайте перепишем приложения на Go".

В 80 % случаев, настройкой памяти тормоза убираются (банально eden выкручиваем на максимум). Но если приложение написано так, что плодит дофига мусора (((( то никакого eden может и не хватить.

IMHO & AFAIK

См. старое устройство Heap в Java. AFAIK
(в 1.8 поменялось)

young generation:
Eden Space
Survivor Space

old generation:
Tenured Generation

и:
Permanent Generation (non-heap) / Metaspace (java 1.8)
Code Cache (non-heap)
сейчас еще должна быть non-heap под приложение

В G1 garbage collector от этого ушли.
Но я с G1 НЕ работал, ничего сказать не могу.

Герой дняLeonid Kudryavtsev,
спасибо, у нас 8я версия, значит, нас не касается

касается не от версии, а от используюемого GC
у меня тоже была 8, но GC использовался старый, т.к. разбираться и эксперементировать с новым не было желания / распоряжения )))

maytonА теперь вопрос. Какие идеологические причины нам могут помешать? Ну или технические.
Технические - лень
Идеологические - тогда мы будем как Kotlin. Мы же - Java! Самойстийная Java, на всякую фигню из Kotlin не поведется. )))

+Технически - расширить типы постфиксами with null и not null. Это может потребовать менять описания формата class'ов и class loader. Т.е. нужно продумывать решение на обратную совместимость. (например всегда генерировать сразу три class файла, один оригинальный и два синонима/алиаса для with null и not null)

Добавить Kotlin'овские операции, проблем не вижу совершенно. Другое дело, без расширение типов, упремся в субж данного топика ))) Т.к. вводить в спецификацию JRE (как результат операторов) генерики Optional<X> и NotNull<X> - это попахивает жутким костылем граничащим с бредом. (но лямбды тоже достаточно костыльно реализовали, но ведь пользуемся)

На самом деле, т.к. исходники Open JDK и javac доступны - никто не мешает скачать и вхерачить. Вхерачить новый элвис оператор IMHO работы на пару дней )))

Ну да. Надо было old gen . Так же как вместо eden, по логике, young gen.
Расплодили терминов, блин )))