Какая гадость эта ваша...
... заливная рыба NetBeans!
Села тут старая макака код пописать... Дай, думаю, посмотрю NetBeans 6.0M9 -- даром, что ли, на их рассылку подписан? Из "basic", "standard" и "full" выбрал "basic" -- всего 22 Мб и море удовольствия -- хвалёный Matisse включён, а мне работы всего на полчаса -- форму наклепать и заказчику мозг промыть.
Первое замечательное наблюдение.
Если я, чёрт возьми, консерватор и у меня на машине AWT_TOOLKIT=MToolkit, то в половине случаев поля ввода не работают. Не реагирует ни тебе на клавиатуру, ни тебе на мышь. Это, конечно, свойство не NetBeans, а JDK 1.6, но впечатление омрачило.
В README/Release Notes об этом артефакте, разумеется, ни слова.
Второе "--".
NetBeans встал не в туда. Я хотел в /opt, но всё проморгал и поставил по умолчанию -- хер знает, куда. Перезапущенный инсталлятор говорит: NetBeans уже установлен, нажмите "Exit" для выхода. Т. е. маркер об установке он видит, а куда программа установлена -- мне не говорит.
Разумеется, find / -iname '*netbeans*' спас отца русской демократии.
Оказывается, по умолчанию он ставит в /usr/local, а маркер хранит в ${HOME}/.nbi
Третье "--".
etc/netbeans.conf лучше поправить -- там есть закоментированные настройки GC специально для Sun JVM. Это если у вас Sun JVM.
Четвёртое "--".
Сплеш-скрин -- красивый! Пожалуй, это лучшее, что я нашёл в NetBeans. Потому как всё остальное... Но об этом дальше.
Пятое "--".
Создатели среды погнались за лаврами IDEA и сделали два представления окна настроек: Basic Options и Advanced Options. По умолчанию (при открытии) всегда включены Basic Opts, и хрен ты это поведение изменишь. Причём когда переключаешься на Advanced, тебя всегда спрашивают: "Применить изменения?" -- даже если ты в этом basic view никаких изменений не делал.
Advanced Options -- в духе старого доброго (и такого же глючного) NetBeans 3.x. Только их на порядок меньше, чем в 3.x. И я, старый дурень, тщетно искал в Adv. Opts такие простые вещи, как Fonts and Colors или Default Web Browser. Оказалось, что множество Adv. Opts не включает в себя множество Basic Opts! Зато эти два множества пересекаются! Т. е. задать новый или переконфигурировать существующий веб-браузер можно только в Adv. Opts, а выбрать браузер по умолчанию -- только в Basic Opts!
Причём некоторые изменения настроек (не изменения поведения в рез-те изменения настроек!) становятся видны только после перезагрузки среды в целом. Т. е. добавил/удалил/переименовал узел в дереве настроек -- перезапусти!
Причём значения тех настроек, что находятся в обоих мн-вах (Basic и Adv.) отнюдь не всегда синхронизированы (т. е. здесь true, а там -- false и vice versa и т. д.)
Причём редактор настроек сохраняет совместимость с таковым от 3.x -- он до сих пор зачастую выдаёт NullPointerException. Это, граждане, уже разгильдяйство.
Шестое "--".
Маленький штрих касательно редактора кода. Установил раскладку а-ля Emacs. Выделил кусок текста, решил скопировать. Скопировать -- это Alt+W (в оригинале было Meta+W или Esc,W, причём Swing принципиально может ловить и первый, и второй вариант, но простим на первый раз). Нажимаю клавишу Alt+W. После первого нажатия вылезло "Add Watch Expression", после второго -- скопировалось. И так далее с переменным успехом.
Седьмое "--".
Визуальный редактор -- отдельная песня. Во-первых, если я хочу, скажем, JFrame с дочерними компонентами, т. е. бин со свойствами, отличными от таковых по умолчанию, но неизменным в сравнении с родителем поведением, то мне всё равно предлагают унаследоваться от JFrame. Вопрос, зачем мне наследование, если я не переопределяю ни единого метода JFrame, остался открытым. Воспользоваться сторонней фабрикой внутри Matisse я, увы, не могу.
Код генерится замечательный. Несмотря на то, что source code level равен 1.6, в автосгенерированном коде присутствуют
но никак не
Каждый не-ASCII-шный символ свойства "text" любого бина тщательно преобразуется в \uXXXX, даже несмотря на то, что системная кодовая страница -- KOI8-R, и исходный код -- тоже в KOI8-R. "Мы поливаем цветы даже в дождь."
Но вот незадача -- если в прочих (т. е. не упомянутых в классах BeanInfo) местах автосгенерированного кода у меня присутствуют строковые литералы (например, я на месте инициализировал таблицу доморощенной моделью данных) и мне, наоборот, нужно преобразовать их к ASCII-виду (например, символ "№", отсутствующий в таблице KOI8-R) -- то здесь NetBeans упрётся рогом и откажется что-л. делать. Мол, сам запускай свою native2ascii, а я здесь ни при чём. И включай ей принудительную интернационализацию GUI, не включай -- всё едино.
Да, про интернационализацию. Запустил, сделал. Создал bundle по умолчанию, ему в соответствие поставился язык "<default language>". Захотелось мне добавить ещё один bundle -- на этот раз для ru_RU. Добавил. После этого решил попереключать design language в дизайнере (формально это поддерживается)... Шиш!.. Локаль ru_RU не видна, даже перезапуск среды не помог.
В конце каждой строки кода, подвергшейся изменению при интернационализации, заботливо воставлен комментарий: "// NOI18N". Это, конечно, здорово, но:
Далее, автосгенерированный код формально можно сделать либо распахнутым по умолчанию, либо свёрнутым по умолчанию. Есть такой булевский флаг -- Generated Code Folding -- отдельный от настроек свёртывания прочего кода (Code Folding). На деле же этот флаг всего лишь включает/выключает свёртывание всего кода!
Наконец, в палитре компонентов -- ни Box.createBox(), ни Box.createGlue(), ни Box.createStrut().
Резюме
Вы, наверное, спросите, зачем всё это я пишу здесь, вместо того чтобы посетить сей ресурс и там изложить свои взгляды.
Да потому что для того, чтобы участвовать в бета-тестировании продукта, надо этим продуктом регулярно пользоваться, а промежуточными milestone'ами NetBeans (в отличие от достаточно стабильных бета-версий Eclipse) пользоваться регулярно нельзя (исключая, разумеется, случаи, когда свободного времени вагон, а пользователь является фанатом и готов жрать свой кактус).
Я не помню, чтобы при использовании Eclipse у меня возникали проблемы с глючностью/непродуманностью интерфейса. Была либо бинарная несовместимость SWT с native-библиотеками (но это исправлялось командой в течение двух-трёх недель, и никогда не встречалось в релизе), либо на больших проектахзасирался засорялся PermGen, но это лечилось увеличением его размера.
Наконец, вы не задавались вопросом, почему Eclipse Foundation, помимо feature releases (3.0, 3.1, 3.2) выпускала и bugfix releases (3.0.1, 3.0.2, 3.1.1, 3.2.1), а вот NetBeans -- никогда? Воистину, все версии NetBeans: 3.6, 4.0, 4.1, 5.0, 5.5 -- это были feature releases.
И 3.6 из них -- лучший.
Села тут старая макака код пописать... Дай, думаю, посмотрю NetBeans 6.0M9 -- даром, что ли, на их рассылку подписан? Из "basic", "standard" и "full" выбрал "basic" -- всего 22 Мб и море удовольствия -- хвалёный Matisse включён, а мне работы всего на полчаса -- форму наклепать и заказчику мозг промыть.
Первое замечательное наблюдение.
Если я, чёрт возьми, консерватор и у меня на машине AWT_TOOLKIT=MToolkit, то в половине случаев поля ввода не работают. Не реагирует ни тебе на клавиатуру, ни тебе на мышь. Это, конечно, свойство не NetBeans, а JDK 1.6, но впечатление омрачило.
В README/Release Notes об этом артефакте, разумеется, ни слова.
Второе "--".
NetBeans встал не в туда. Я хотел в /opt, но всё проморгал и поставил по умолчанию -- хер знает, куда. Перезапущенный инсталлятор говорит: NetBeans уже установлен, нажмите "Exit" для выхода. Т. е. маркер об установке он видит, а куда программа установлена -- мне не говорит.
Разумеется, find / -iname '*netbeans*' спас отца русской демократии.
Оказывается, по умолчанию он ставит в /usr/local, а маркер хранит в ${HOME}/.nbi
Третье "--".
etc/netbeans.conf лучше поправить -- там есть закоментированные настройки GC специально для Sun JVM. Это если у вас Sun JVM.
Четвёртое "--".
Сплеш-скрин -- красивый! Пожалуй, это лучшее, что я нашёл в NetBeans. Потому как всё остальное... Но об этом дальше.
Пятое "--".
Создатели среды погнались за лаврами IDEA и сделали два представления окна настроек: Basic Options и Advanced Options. По умолчанию (при открытии) всегда включены Basic Opts, и хрен ты это поведение изменишь. Причём когда переключаешься на Advanced, тебя всегда спрашивают: "Применить изменения?" -- даже если ты в этом basic view никаких изменений не делал.
Advanced Options -- в духе старого доброго (и такого же глючного) NetBeans 3.x. Только их на порядок меньше, чем в 3.x. И я, старый дурень, тщетно искал в Adv. Opts такие простые вещи, как Fonts and Colors или Default Web Browser. Оказалось, что множество Adv. Opts не включает в себя множество Basic Opts! Зато эти два множества пересекаются! Т. е. задать новый или переконфигурировать существующий веб-браузер можно только в Adv. Opts, а выбрать браузер по умолчанию -- только в Basic Opts!
Причём некоторые изменения настроек (не изменения поведения в рез-те изменения настроек!) становятся видны только после перезагрузки среды в целом. Т. е. добавил/удалил/переименовал узел в дереве настроек -- перезапусти!
Причём значения тех настроек, что находятся в обоих мн-вах (Basic и Adv.) отнюдь не всегда синхронизированы (т. е. здесь true, а там -- false и vice versa и т. д.)
Причём редактор настроек сохраняет совместимость с таковым от 3.x -- он до сих пор зачастую выдаёт NullPointerException. Это, граждане, уже разгильдяйство.
Шестое "--".
Маленький штрих касательно редактора кода. Установил раскладку а-ля Emacs. Выделил кусок текста, решил скопировать. Скопировать -- это Alt+W (в оригинале было Meta+W или Esc,W, причём Swing принципиально может ловить и первый, и второй вариант, но простим на первый раз). Нажимаю клавишу Alt+W. После первого нажатия вылезло "Add Watch Expression", после второго -- скопировалось. И так далее с переменным успехом.
Седьмое "--".
Визуальный редактор -- отдельная песня. Во-первых, если я хочу, скажем, JFrame с дочерними компонентами, т. е. бин со свойствами, отличными от таковых по умолчанию, но неизменным в сравнении с родителем поведением, то мне всё равно предлагают унаследоваться от JFrame. Вопрос, зачем мне наследование, если я не переопределяю ни единого метода JFrame, остался открытым. Воспользоваться сторонней фабрикой внутри Matisse я, увы, не могу.
Код генерится замечательный. Несмотря на то, что source code level равен 1.6, в автосгенерированном коде присутствуют
new Runnable() {
public void run() {
// do smth
}
}
но никак не
new Runnable() {
@Override
public void run() {
// do smth
}
}Каждый не-ASCII-шный символ свойства "text" любого бина тщательно преобразуется в \uXXXX, даже несмотря на то, что системная кодовая страница -- KOI8-R, и исходный код -- тоже в KOI8-R. "Мы поливаем цветы даже в дождь."
Но вот незадача -- если в прочих (т. е. не упомянутых в классах BeanInfo) местах автосгенерированного кода у меня присутствуют строковые литералы (например, я на месте инициализировал таблицу доморощенной моделью данных) и мне, наоборот, нужно преобразовать их к ASCII-виду (например, символ "№", отсутствующий в таблице KOI8-R) -- то здесь NetBeans упрётся рогом и откажется что-л. делать. Мол, сам запускай свою native2ascii, а я здесь ни при чём. И включай ей принудительную интернационализацию GUI, не включай -- всё едино.
Да, про интернационализацию. Запустил, сделал. Создал bundle по умолчанию, ему в соответствие поставился язык "<default language>". Захотелось мне добавить ещё один bundle -- на этот раз для ru_RU. Добавил. После этого решил попереключать design language в дизайнере (формально это поддерживается)... Шиш!.. Локаль ru_RU не видна, даже перезапуск среды не помог.
В конце каждой строки кода, подвергшейся изменению при интернационализации, заботливо воставлен комментарий: "// NOI18N". Это, конечно, здорово, но:
- зачем изобретать велосипед, если уже есть механизм, используемый в Eclipse: "// NON-NLS-<n>"?
- существующая в NetBeans схема не позволяет избирательно игнорировать строковые литералы в строке, содержащей несколько таких литералов (т. е. либо все включены, либо все выключены).
Далее, автосгенерированный код формально можно сделать либо распахнутым по умолчанию, либо свёрнутым по умолчанию. Есть такой булевский флаг -- Generated Code Folding -- отдельный от настроек свёртывания прочего кода (Code Folding). На деле же этот флаг всего лишь включает/выключает свёртывание всего кода!
Наконец, в палитре компонентов -- ни Box.createBox(), ни Box.createGlue(), ни Box.createStrut().
Резюме
Вы, наверное, спросите, зачем всё это я пишу здесь, вместо того чтобы посетить сей ресурс и там изложить свои взгляды.
Да потому что для того, чтобы участвовать в бета-тестировании продукта, надо этим продуктом регулярно пользоваться, а промежуточными milestone'ами NetBeans (в отличие от достаточно стабильных бета-версий Eclipse) пользоваться регулярно нельзя (исключая, разумеется, случаи, когда свободного времени вагон, а пользователь является фанатом и готов жрать свой кактус).
Я не помню, чтобы при использовании Eclipse у меня возникали проблемы с глючностью/непродуманностью интерфейса. Была либо бинарная несовместимость SWT с native-библиотеками (но это исправлялось командой в течение двух-трёх недель, и никогда не встречалось в релизе), либо на больших проектах
Наконец, вы не задавались вопросом, почему Eclipse Foundation, помимо feature releases (3.0, 3.1, 3.2) выпускала и bugfix releases (3.0.1, 3.0.2, 3.1.1, 3.2.1), а вот NetBeans -- никогда? Воистину, все версии NetBeans: 3.6, 4.0, 4.1, 5.0, 5.5 -- это были feature releases.
И 3.6 из них -- лучший.
