Зачем в реальные проекты тащить 100500 ново-модных классов и концепций, которые мало чем помогают - лично я не понимаю.

1) Иммутабельные объекты, это конечно круто - но это же полнейший п....ц производительности на банальных операциях. Что java.String, что java.Date. Простейшие требующиеся по бизнесу операции в РАЗЫ и НА ПОРЯДКИ ( 3-5, до десятков) раз медленнее.

Конвертация между различными code page, поищите в гугле, кому не хватает производительности, народ аж через Unsafe извращается ((((

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

3) Стримы... Ну видел я стримы в реальном проекте. Сказать, что бы код был более читабельный, нет, не сильно читабельный. Компактный... ну да, вместо 10 строк цикла, 2-3 строки на стримах.... Только, если Java код с циклом по ArrayList оптимизирует (JIT избавляется от array bound чекинг), то на стримах, легким движением руки, весь проход по коллекции оказался через "универсальный" iterator + array bound чекинг во весь рос - потяря производительно опять таки в разы (приложение: высоко нагруженный сервис). Понятно, что это была ошибка программиста и на стримах (в конкретных случаях) тоже код можно переписать так, что бы использовался специализированный интератор - только требования к знаниям стримов и опыту программиста уже становятся на порядок выше.

4) Гугле ProtoBuf - а кто нибудь из разработчиков вообще сам его запускал? Под каким нибудь профайлером? Создавать при де-сериализации ровно столкько же фабрик, сколько и элементов в коллекциии.... Бл.... Я когда на это наткнулся, мне вспомнились слова одного из начальников "человек который такое написал, должен был бы пойти в лес и закопаться".

5) ByteBuffers - документация заявляет, что создан для того, что бы при IO уменьшить кол-во копирований память-память. Реальные библиотеки (Apache HTTP Components) - все с точностью до наоборот. Т.к. обрашение к элементу в ByteBuffer на порядки дороже, чем к byte[] (уже упоминаемый мною array bound check + возможно native call), то одно сплошное "туда-сюда-обратно, тебе и мне приятно" (уже упоминаемое множ конвертация кодовых страниц String'а).

6) Лямбды - конечно круто и местами, удобно. Только про обработку эксепшенов в 99% забыли начисто.

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

IMHO На самом деле, давно уже назрело полно изменений, которые требуют значительного пересмотра концепций языка. И включение в стандарт JRE/JIT. Но пока вместо этого - костыль на костыле и подпорка на подпорке. Поскольку язык живет уже давно, уже стали появлятся костыли которые подпирают подпорки и подпорки которые костылят старые костыли (((

Optional - одна из таких подпорок и костылей. Если без него не обойтись, то да, нужно/приходится использовать (я пока с этим не сталкивался) . Но тащить костыли в проекты и использовать их везде, где только можно, лично мне не понять.

Все по улицам ходят с палочками для селфи... и мы будем... и пофиг, что у нас даже смартфона нет, зато палочка для селфи - есть! Круто!