Вступление

Размышления о Java

• Чувствительность к регистру поганит жизнь. Хотя, возможно, частично это и дело привычки. Но убежден - это зело неправильно.
• Вообще, подход, где все класс, что в .Net, что в Java, конечно, универсален. Но, как говорится, краткость - сестра таланта, а объектность априори предполагает структуру и дополнительные описания.
• Обычно много комментов в исходниках. Это конечно замечательно, но на мой взгляд нужен разумный баланс, и когда java-doc комментов становится в разы больше чем кода, то чтение этого кода да же со всеми folding становится утомительным. К тоже я не из тех, кто верит, что полноценную справку можно разместить непосредственно в исходнике.
• Одним из простых экспериментов, которые можно провести, является выделение и копирование достаточно большой строки. Итак строка в java это объектная обертка к массиву двубайтных unicode-символов. Сам объект String скрывает массив от внешнего доступа и не позволяет менять отдельные символы или длину как это привычно в Delphi. Я выделял строку примерно таким кодом:
  char[] v = new char[Len]
  return (new String(v))
  Для его исполнения требуется примерно 2 * Len * SizeOfChar байт памяти из-за промежуточного массива v. Внешне Java не возвращает занятую память - это особенность менеджера памяти - реально он может использовать совсем не всю память из выделенной. При присваивании строковых переменных реально присваивается просто ссылка на объект String, впрочем как и для массивов char[]. Для создания копии строки нужно явно вызвать new String с передачей оригинала. Для изменения строк, наполнения строк, можно использовать StringBuilder, char[] и тп. Простую конкатенацию оператором + тоже никто не отменял, но она разумеется тормозная.
  На мой взгляд объектность строк это впринципе нормальное решение, но Pascal-строки со счетчиком выглядят проще и, очевидно, иногда эффективнее, поскольку по реализации ближе к char[].
  Теперь выделим большое количество мелких строк. Для этого создадим достаточно крупный массив из объектов String и инициализируем его относительно небольшими строками. Нас будет интересовать скорость выделения строк и overheat хранения данных. Я выделил 100000 строк длиной 50 символов (заполнение #0). Таким образом объем данных составил 100000 * 50 * 2, что приблизительно равно 10Мб. Оценочное изменение памяти по профайлеру NetBeans состовляет порядка 14Мб. Выделяется быстро, особенно если не в первый раз. По сравнению c Delphi-строками немного медленнее, но значительно быстрее, чем нативные WideString. Теперь посчитаем теоретический overheat. Исходим, из того, что указатель занимет 4 байта. Итак хранение объектов - 4 байт на ссылку, в каждом объекте String присутствует ссылка на массив и 3 целых поля - итого 16 байт. Массив char[] в котором хранятся данные содержит еще как минимум 4 байта длины кроме данных. Итого: 4 + 16 + 4 = 24 байта. Очевидно это не совсем все. Возможно имеет место выравнивание данных или еще какие-то не учтенные поля.
• Объект char можно преобразовывать к нужному регистру Character.toUpperCase, Character.toLowerCase, а объект String имеет методы сравнения без учета регистра. Все в исходниках, из которых, в частности, следует, что в грузинском алфавите не равенство в верхнем регистре еще не означает неравенства в нижнем 8). Я бы на месте разработчиков java не заморачивался :). Преобразования к регистру символов выглядит громоздко, впрочем надо посмотреть как быстро и корректно работает...
  На результат String.compareToIgnoreCase() заметно влияет наличие отладчика. Если сравнивать на предыдущем наборе из 100000 строк, то результат чуть хуже Windows.CompareStringW (не считая времени на выделение строк). А вот Windows.CompareStringA показал заметно худшую производительность. По всему получается, что нативная реализация Windows то же ориентирована на Wide-строки. Но тут следует заметить, что String.compareToIgnoreCase() согласно документации, не учитывает локаль (хотя для Wide-строк, возможно это менее важно чем для однобайтных - не знаю). Впринципе, результат выглядит достойным.

Размышления о NetBeans

Первое, что напрягло глаз - аскетичный ToolBar IDE. Все кнопки - прото статичные картинки (тем не было), что даже по сравнению с Delphi 5 выглядит слишком просто и не эргономично. Затем сюрприом стало то, что в стандартной поставке присутствует только справка по самому IDE и нет ничего по языку java и по пакетам, которые приходят вместе с IDE. Конечно класно, что есть исходники с комментами, но смотреть комменты с java-doc форматированием это совсем не то, что читать страницу справки с перекрестными ссылками. Да, имея отдельный набор файлов документации для используемой версии java можно его зарегистрировать в IDE, но разве такая проблема увеличить размер дистрибутива на 10% и установить справку по умолчанию? Да регистрация справки не является полноценной интеграцией: нужно помнить, что F1 - это только справка по IDE, а Shift/Alt + F1 - это справка по java, причем справка java - это набор html-файлов или zip-архив с ними, те поиска по содержимому фактически нет (в отличие от справки IDE). Мне предствляется, что уже имея html-справку и создавая дистрибутив IDE конкретно для Windows можно было пойти на такой шаг как использование CHM/MSHelp, ну или хотя бы самостоятельно проиндексировать файлы.

В моем эксперименте с длинными строками интересно было, как будет работать просмотр переменных в отладке. В данном случае NetBeans не заслуживает похвалы. Он пытается не просто показать значение длиной строки не взирая на размер, но еще произвести html-форматирование содержимого, съедая при этом и память и процессорное время. Строка из 10м символов привела при просмотре к серьезным зависаниям отладчика.

Мелочь, а поиск (Ctrl+F) вызвал определенные неудобства. Как-то привык (и кстати не только из-за Delphi - VS, например, так делает), когда слово из-под курсора редактора само встает в поиск. Впринципе, здесь есть альтернатива (наверно более правильная) Find usages (Alt+F7) да еще подсветка в редакторе.