-=Koba=-, он просто думает наперед - наверняка потом он напишет POST для добавления элементов в коллекцию. И тогда уже нужен Atomic.

-=Koba=-, это не запрещает туда добавлять новые элементы. Это запрещает назначать новую коллекцию в тот же указатель customers.

Что не так? Что final не запрещает изменять коллекцию?

Так POST подразумевает добавление то мы не можем добавить новый элемент я это имеел видуНу на той минуте не можем. Когда я такие туториалы делаю, то тоже начинаю только с GET, а затем добавляю и POST и рефакторю код который перестал работать. И точно так же я бы мог сразу создать Atomic потому что знаю что через 10 мин возможно буду генерить новые ID когда буду реализовывать POST.
Да - в том коде не было пока необходимости делать Atomic, да что там - даже счетчик заводить не надо было, мы могли цифры захардкодить без всяких стримов. Просто Человек думает наперед. О чем-то сразу подумал (Atomic), о чем-то вспомнит уже непосредственно во время реализации POSTa (например тот факт что он работает не с concurrent коллекцией).
-=Koba=-PUT же идемпотентен, что подразумевает изменения коллекции в данном случе там объекты и мы можем поменять им значениеPUT здесь не причем, PUT кол-во элементов менять не будет (хотя это само по себе не воспрещается и бывают случаи когда это имеет смысл). И уж точно новые ID мы в нем генерить не будем.
-=Koba=-Так POST подразумевает добавление то мы не можем добавить новый элемент я это имеел видуПочему не можем? Если мы будем писать POST, то он и будет добавлять в коллекцию. На той минуте POST'а еще не было просто.

Ну так выражай мысль полностью, а не обрывками.
В поле не List.of() уходит, а результат collect(toList()) - он в свою очередь mutable.

Сорян, че-т я не заметил цитату с докой.

Интересно почему в доке так написано - код явно создает мутабельную коллекцию:

Либо просто копи-паста из другого метода (эта фраза там 7 раз встречается), либо ради forward compatibility (что сомнительно - исключительно на доки мы редко полагаемся).

chpasha, спасибо! Судя по всему мы все-таки можем продолжать расчитывать на то что результат всегда будет mutable list.

Дак в чистом ООП/функциональном программировании эти объекты immutable, а значит им не нужен deep copy.

mayton, java.time вроде полностью immutable.

Т.е. по-твоему POST - это не мутирующий доступ к шареному ресурсу (генератору ID)?

Т.е. ты даже не посмотрел на код в видео и стал умничать? В том примере просто коллекция объектов в контроллере - это просто демонстрация фреймворка.
andreykaTну и да пост в моем мире это НЕ мутирующая операция.Ну значит ты живешь в сказочном мире, где феи инкрементят sequence'ы, а гномы обновляют индексы - и все это без мутирующих операций.

Ты можешь уменьшить кол-во мутирующих операций, но они все равно будут. Индексы все равно будут лочиться как минимум для того чтоб изолировать транзакции (чтоб две транзакции не могли вставить одинаковые записи в уникальный индекс). Но допустим нет ID вообще и нет constraint'ов - но все равно ID транзакции нужно еще инкрементить для MVCC, считать заполняемость страниц в табличном файле и т.д. и т.п.

Но я не понимаю зачем мы продолжаем этот разговор - в примере на ютубе все равно не было базы. Там был обычный статический счетчик-sequence и статическая коллекция данных. Они эмулировали базу чтоб не усложнять пример (хотя бы на начальных стадиях).