Eugene NewИм бы еще самим научится эти IDE грамотно писать.
Критикуя предлагай альтернативу

Eugene Newlleming,
А что там читать, код написан криво уже не раз сказали в ветке об этом.
По жизни недогоняющему Siemargl читать надо, причем до полного просветления - он решил, что компилятор все исправил и так можно писать.


Ну не совсем это он имел ввиду, а то что это известный плохой паттерн использование конкатенации строк в цикле. Который можно увидеть и на Хабре и stackoverflow и в статьях частенько.
Eugene NewЧтобы говорить на любой пример плохого поведения программы, что код плохой и программист дурак, даже не нужно обладать разумом. Это может и попугай.

Сформулировать критерии заранее, что можно и что нельзя, гораздо сложнее. Единого мнения по правилам применения String я тут не вижу. (недогоняющих просьба не беспокоится).

Говорить попугай может, правда не всегда угадывает правильно, а если бы угадывал всегда то программистов давно заменили бы попугаями.

Правило поведения очень простое каждый выбирает для себя сам, я когда столкнулся выбрал использовать явно всегда StringBuilder и пне полагаться на компилятор. Тут трейдофф если код простой со stringbuilder ухудшается читаемость.

Поведение компилятора очень разумное. Integer.toString это явная просьба создать новый объект, соотвественно что просили то получили в чем проблема? Единые правила известны если вам нужны объекты делайте их если не нужны то избегайте. Возможно синтаксис Java иногда явно не указывает будет создан объект или компилятор сам поправит, но иногда даже явность не всегда поможет, так там еще много накручено прям в Jvm кэши на Integer, String. Если неизвестно создаются или нет объекты то откройте исходники благо они доступны в Java (тут кстати IDE и пригодится ctrl click и уже прям там где надо, и неплохо регулярно этим пользоваться)

Общие претензии видимо к тому что компилятор не разворачивает самостоятельно цикл и не выносит stringbuilder наружу из цикла. И правильно делает ибо не знает точно что все внутри цикла без побочных эффектов и соотвественно делает то что его попросили.

Конешно можно было впилить в компилятор сразу правильно разворачить цикл и выносить stringbuilder наружу и это красиво выглядет на этом тривиальном примере.

Но тут ктото пишет метод который помимо основной логики, еще и делает ну например устанавливает соединение к БД.
В результате получим здоровски быстро сделанную строку и непонятный NullPointerException и непонятном месте из за того что компилятор соптимизировал конкатенацию и вырезал важную часть кода по инициализации соединения с БД.

Есть целые трактаты советы как делать и как не делать и почему с примерами. Целая куча статей на ibm developer network например от брайна гоетца с объяснениями как поведет себя кусок кода в конкретном случае, можно полистать oracle secure coding standards.

Ссылок накидать легко, но есть сильное подозрение что не заинтересует.

Eugene NewНе впервые тут от этого гражданина вижу понимание строго наоборот.
ну для тех кто был этим вопросов озабочен ранее вполне очевидно что именно он имел ввиду.
Eugene NewЭто не обязательно. Но все же пусть посмотрят, как сделаны старые взрослые IDE. И знания основ и здравый смысл бы им не помешал. Например, не лепить 30 отдельных файлов настроек в формате XML в запутанное дерево каталогов. Т. к. XML сам по себе уже иерархическая БД и все можно писать в один файл. Это позорище видно каждому сразу после установки этой суперсреды.
какое отношение файлы настроек имеют к качеству и удобству IDE, да никакого. Файлы настроек для IDE и используются только IDE. Как и где желают хранить настройки ide пусть решают разработчики ide, мне без разницы. Не верится что разбиение на разные файл настроек случайное решение. Вполне разумным решением хранить разные части настроек в разных файлах ибо легче тестировать независимые части чем все в куче. К тому же в xml dom очень небыстро сериализовать а если настроек много то уже неприятные задержки будут.

есть такая штука как мавен т.к. шта проект ездит без проблем из eclipse, в idea и Netbeans и никаких проблем хоть в Notepad работай только Maven directory layout запомни и все.

Eugene NewТут дело не в компиляторе, а в языке и его библиотеке. Гуано-код Integer.toString (и его аналоги) это часть стандартной библиотеки. И оператор + для строк часть языка. Можно насчет этого подискутировать. Что хорошего вы видите в этих двух вещах, что оправдывало бы их существование?

Integer.toString есть документация для чего это, int в строку преобразовывать. Что такое int и почему они в Java тоже можно нагуглить.
Вот если у System.out не был бы перегружен метод println а был бы только println(String line) то что тогда остался бы только варинт везде писать
System.out.println(""+number);
Не все библиотеки продуманы для все вариантов.

Есть подозрение что если бы забыли в станд. библиотеку добавить Integer.toString и оставили только println(String value) то
Вопрос "Как вывести на консоль integer value" был бы вторым после "Как выйти из vim"

Первый вариант симпатичнее явно говорит что произойдет.
String number = Integer.toString(22);
String number = "" + 22;

2+"2" что должно быть, а что будет ?
Integer.toString(2) + "2" а здесь ?

Eugene NewДолжна быть четкое и краткое описание того, что считается гуано кодом при работе со String. Без воды.


Которое уже неоднократно указали без воды не используй строки как промежуточное хранилище, а используй stringbuilder.

Eugene NewИ вообще после сборщика мусора, который мусор не собирает вообще, а просто роняет программу в произвольный момент, я от него жду чего угодно.
Не в произвольный а когда заканчивается память, а она не заканчивается если не расходуется. А если расходуется и по определенному паттерну то отсекаем часть и проставляем памяти больше чем в точке отсечения это же не рокет саенс.
Это не единственный и не основной gc, а как вариант предложение, ибо в java все неспешно. Можно попробовать оценить, не подходит не использовать. Где такой используется уже указали где нужен хороший отклик и можно сервер реастартовать регулярно.

Eugene NewПрямое. И вообще это индикатор крайне низкого уровня. Как только я это увидел - понял, дилетанты. Все дальнейшее подтверждает мое первое впечатление. Если даже такую элементарную вещь сделали максимально через задницу, остальное тем более.

скажет так пишут они в "невидимые" под линукс .idea, .settings, .classpath и соотсвественно обычно их тут же добавляют в gitignore, и проект отстается чистым мавеном. А про мавен mayton уже написал подробнее.

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

Eugene New Не верится что разбиение на разные файл настроек случайное решение.
Да уж, я тоже в случайность не верю.

Вряд ли чтобы испортить Вам настроение, а больше с точки зрения надержности, скорости, легкости расширения. Многие сразу в проект mvnw аля gradle добавляеют и он тоже папочку создает и ничего.

Eugene New. llemingК тому же в xml dom очень небыстро сериализовать
Это следующий пункт - использование xml само по себе. То, что они делают xml а используют их как набор плоских файлов, показывает, что они вообще не понимают что делают и зачем. Хотели бы использовать xml-как единую иерархическую базу для того, чтобы хранить все в одном месте - это еще можно было бы понять. Создали бы кучу плоских файлов, которые легко читать поодиночке - ну хреново, но хотя бы понятно. А брать xml и делать кучу файлов, которыми замусоривать все - это максимально через задницу. И ведь речь то идет о ПРОСТЫХ вещах, но нет, из них сделали сами искусственно целую ПРОБЛЕМУ.


Одно это уже говорит о том, какой у них ужасный бардак во внутренней архитектуре программы. Ну не понимают люди, что они вообще делают и зачем. Что только подтверждается дикими системными ресурсами, которые она жрет и ее низким быстродействием.

Тут давали ролик на рассказ одного из авторов Идеи о попытках оптимизации. 2017 год. Сразу обращает внимание, что автор, хотя 10 лет работает над этим проектом, "открытия" начал совершать в 2017 году. Обнаружив, что главная проблема в строках, он даже не сделал никакой попытки оптимизировать архитектуру проекта с точки зрения использования строк. Только пытался тип строк подменить - что ему сделать так и не удалось.

Видимо там нечего оптимизировать поэтому и не делал попыток.

Integer.toString есть документация для чего это, int в строку преобразовывать
Eugene newЕсть StringBuilder.append (int) . Заметьте, сишная itoa не создает строку, а пишет в готовый буфер.

Готовый буфер откуда появляется? Если в цикле создавать новый буфер и загонять туда число чем от приведенного примера отличается ? А в java сделайте stringbuilder, у него все равно буффер внутри и заметьте он не создает строку а пишет в буффер
builder.append(34)

Уже обсуждалось же. Нельзя предсказать момент окончания памяти, нельзя его обработать.

Да обсуждалось, можно предсказать это простая логика, если чтото не тратить то это не закончится.
Как вариант для особо типа приложений jvm рестартовать до того как закончится память.

Eugene NewРассказал о том что от двухбайтных char[] отказываются в пользу более экономного
внутреннего представления.

Что автоматически приведет к дикому замедлению обработки строк. Впрочем, разве это его волнует, когда колеса под рукой?)

Firefox такое провернули несколько релизов назад. Огласили результат что наоборот стало сильно быстрее и меньше тратить памяти.