пятница, 27 июля 2012 г.

The Joda umbrella

Joda (http://joda.sourceforge.net/) - это группа java-проектов с открытым исходным кодом для расширения базовой функциональности jdk. В настоящее время включается в себя joda-money, joda-beans, joda-primitives, joda-convert и joda-time. Все библиотеки характеризуются узкой специализацией, небольшим размером, хорошим описанием и javadoc'ом, простотой и интуитивностью применения, совместимостью и удачным взаимодействием с jdk. Что же включает в себя эта группа и какие из них стОит поместить в свою "копилку" полезных библиотек?

пятница, 6 июля 2012 г.

//noinspection в IntelliJ IDEA

Как я уже упоминал в предыдущем посте, в IDEA есть интересный плагин InspectionGadgets, который на текущее время предлагает более 500 дополнительных проверок для этой IDE и является мощным инструментом статического анализа кода.
Инспекции этого инструмента весьма удобны в использовании, т.к. сгруппированы по содержанию и назначению и могут настраиваться индивидуально. Более того, результаты настройки можно сохранить в отдельный файл xml формата и загрузить его в IDE в другом месте. Ну, да разговор немного о другом. InspectionGadgets отслеживает и формирует гораздо больше предупреждений, чем java компилятор. И если требуется подавить какое-то из предупреждений, то аннотация @SuppressWarnings отлично работает. Но как узнать название нужного предупреждения, чтобы указать его в параметрах аннотации?

вторник, 3 июля 2012 г.

@SuppressWarnings: пример

@SuppressWarnings в java (list of warnings) список предупреждений

1) Praemonitus praemunitus (предупреждён, значит, вооружён)
Практически все компиляторы в процессе компилирования исходного программного кода выполняют статический анализ этого кода, что позволяет идентифицировать и предупреждать о наличии некоторых общих ошибок программирования. Положительный эффект заключается в том, что каждое имеющееся предупреждение - потенциальная проблема, и чем раньше эта проблема выявляется (в данном случае - уже на этапе компиляции), тем дешевле её решение. В целом, многие опытные разработчики придерживаются мнения, что конечный код не должен вызывать предупреждений компилятора. Более того, в некоторых компаниях идут дальше и настраивают политики систем контроля версий таким образом, чтобы коммиты не вызывали подобных предупреждений.
Однако жизнь такова, что иногда исключения из строгих правил всё-таки возникают. И оказывается, что в каком-то конкретном случае выдаваемое компилятором предупреждение легально, и что было бы здорово указать  компилятору проигнорировать конкретное предупреждение. Как вообще можно управлять политикой предупреждений в java?