Марст.е. в метод передаются в качестве параметров какие то объекты и внутри изменяются. Мне не нравится что при чтении кода "method" не понятно что эти объекты внутри метода изменяются.

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

К сожалению, это не слабая проблема в java. Отсутствие гарантий неизменяемости объектов со стороны языка вроде позволяют сделать некоторые упрощения для языка, а также и избежать излишнего копирования объектов. Но на самом деле, например, в крупных технических проектах с месивом кода, когда работает куча людей, частенько разной квалификации, как потроха серверов приложений, не редко вынуждены заниматься дублированием объектов с целью каких-то "гарантий", что естественно сказывается на работе с памятью и на перфомансе. И серебряной пули в этих вопросах нет. В функциональных языках с принципами имутабельности объектов тоже есть и технические проблемы, и ряд неудобств. Как с ними пытаются бороться на платформе JVM, можно посмотреть на примере кложуры.

Petro123imho раздутая проблема.
Нехватало ещё const объектов вводить.
И причём Java, если такое же в других ЯП (imho)
В Java обычную БЛ и код не надо разносить на 100 независимых кусков (imho)
В том и дело, что проблема как раз и не раздутая, никто не парится, в освновном, (и я тоже), особенно в рамках бизнес-логики. А вот на около-системном уровне не всё так однозначно. Я не работаю на этом уровне, поэтому конкретными примерами сразу завалить не могу. Пару лет назад я читал блог какого-то разработчика из JBoss, он неплохо показывал к каким последствиям приводят многие "незапаривания" в жабе, и почему очень трудно реализовать эффективный жаба-сервер. Всего не помню, но тогда немного полазил в потрохах томката, действительно есть места, где делаются копии данных перед вызовами методов.
Можно почитать про JGit. Его разработчики неплохо раскрывали проблемные места в жабе, вплоть до того, что внутри реализации слоя I/O (как минимум вокруг mmap, если я не вру) тоже не избежать лишних копирований буферов. Их вердикт - оригинал гита по перфомансу им не догнать, но в целом вполне производительное решение.
Можно почитать на какие ухищрения пошли в Disruptor-е, в том числе и чтобы избежать лишние создания объектов.

И совершенно верно, что если ещё и плюсовый const для объектов ввести в язык, то можно закапываться. Лично мне и так жаба как язык не нравится, ни для системного уровня не ахти, ни для написания прикладной логики.
В Эрганге, например, живут без всяких const. Не всегда конечно система может оптимизировать и делать правки по месту вместо копирования, у эрланговцев есть вынужденные хаки. И в кложуре без transients (правок по месту) не обошлись, не сохранили "абсолютную чистоту". Увы, идеального ничего нет.

Petro123тут и проблема imho в Java, что нет чёткого деления по вертикали на системный и несистемный (прикладной).
Отчасти от Веб, который на компонентный ООП сильно не рассчитан.
Ну, вроде, как раз некая ликвидация деления на системное и неочень и было одной из идеологических причин создания java-платформы. Создатели пытались ликвидировать потребность в связке C/C++ -> питон, луа, свой скриптинг, или какой-нибудь 4GL в ERP-системах и т.д. Причём идеология и архитектура в java-платформе вполне красива и грамотна относительно своих заложенных целей - раз уж взята политика ООП - то язык/платформа во всём объектны до глубины костей. Другое дело, что по прошествию немало лет ООП показало и свои плюсы, и не малые проблемы. Лично я сторонник простоты, например, меня очень привлекает гугловский Go как промышленный язык/платформа (речь не идет о возможности его применения на сегодняшний день). Без кривого ООП решаются те же проблемы, легко и красиво, даже без "функциональщины" (хотя их интерфейсы - те же хаскеловские классы типов или протоколы кложуры, только вид с боку).
Но с другой стороны, это сейчас можно быть таким "шибко умным", насмотревшись на многолетний опыт со стороны (и создатели Go тоже насмотрелись на много чего, при своём опыте в не один десяток лет).

Одним словом, java не идеальна.


Petro123Т.е. "проще - лучше", что в данном контексте - ДайИмяФункцииЧеловеческое.
Вроде все на этом сошлись.
Да, так оно и есть. Просто обидно, что это решение на уровне скриптовых языков с динамической типизацией, без железных гарантий, при этом жаба так и не имеет их лёгкости, несмотря на все чудеса жабских IDE, с их автокомплитами и прочими семантическими анализами.