Tags: java

nyaload

maven magen

Сегодня количество магии в maven зашкалило.

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

Библиотеки вроде как берутся из местного repo, а не из интернета, вирусов AVZ и касперский у меня на компе не нашли. Может бага в плагине и дейфейс сайта поддержки плагина. Может я или кто-то из коллег подцепил нечто, что сейчас притихло. Этот "hacked by" ищется в инете на 15000 страничках, но неясно как и зачем оно "задефейсило" бинарные jar-файлы.

Collapse )
nyaload

(no subject)

Ага. По умолчанию в jar-файлы запихиваются timestamp скомпилированных java-файлов. Из-за этого-то бинарные дифы и отличаются. Пидарасы.
И файлик кладётся pom.properties в jar, "#Generated by Maven Fri Nov 12 21:02:43 MSK 2010". Пидарасы. Гуглить по "addMavenDescriptor false" (я выкинул целиком дескрипторы, из-за даты).
nyaload

Run Maven, Use Maven, Write Maven, Improve Maven, Develop Maven

maven делает всё, но очень хреново.

Резолв версий библиотек: в теории хорошо, но на практике сторонние либы ставят слишком точные версии зависимостей и содержат копии классов чужих библиотек внутри, в результате в проекте оказывается несколько разных версий библиотек. Вообщем, полуавтоматический резолв версий - это единственное за что его можно терпеть, лучше так, чем совсем руками. Ну и клёво что они скачиваются из одного места, не надо прыгать по sourceforge и apache.org. Но это минор.

Компиляция: Работает тупо медленно, я уже писал об этом, не пытается за один os.stat/листинг директории выяснить про файл всё, спрашивает атрибуты по кусочкам, лезет в папки где исходников быть не может (.svn). IDEA пересборку проводит в 50 раз быстрей при типичных изменениях.
Не умеет многопоточную сборку. Спрашивается, зачем связывать пользователя по рукам и ногам, и не использовать это для оптимизации.

"Линковка"-сборка в jar: По мистическим причинам пересобирает jar когда это не надо. jar получаются бинарно разные, одну причину точно вижу - всовывает туда имя пользователя и компьютера, и самого себя, типа "собрано мавеном". Блин, да работай ты как простой зип, приходится деплоить 100 мегабайт jar, хотя исходники не поменялись.

Вывод логов - максимально grep-unfrendly, невозможно регулировать уровни INFO/WARNING.

Лезет в сеть (слава богу, в местный репо) за библиотеками. Можно настроить на офлайн, но блин, чую библиотеки вне контроля версий чувствую ещё станут поводом для ада.
nyaload

int i; /** получить i*/ int getI { return i; }; /** установить I */ void setI(int i) { this.i = i}

А зачем Java IDE навязывает геттеры и сеттеры для public полей? Прямо пишет inspection-предупреждение, "тут public field, лучше сгенерить сеттер и геттер".

Инкапсуляции это никакой не даёт, если есть и set, и get.
Если внезапно понадобится что-то делать в сеттере, вместо простого присваивания - то эти геттеры/сеттеры могут быть созданы именно тогда, когда понадобятся.

А то в 95% случаев только код усложняет, и для глаз, и для полнотекстового поиска.
int i; /** получить i*/ int getI { return i; }; /** установить i */ void setI(int i) { this.i = i;} //осмысленной информации в этом коде - только первые 5 букв.

Лучше бы IDE предупреждала наоборот, "нашла бессмысленные getter и setter, давайте уберу".

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

exceptions

1. Относительно checked exceptions в Java (список разрешённых исключений в декларации метода):
у меня нет проблем с мего-списком исключений, такой список от непонимания кода и непонимания как транслировать исключения. И от того, что Collapse )

2. Моя точка зрения на жизнь с исключениями:
Collapse )

3. Геймдевелоперы живут без исключений, они им не нужны, Collapse )
nyaload

Java

Спешно обмазываюсь Java.

Вкратце про генерики, на русском - http://www.rsdn.ru/article/java/genericsinjava.xml

Наиболее понятная ( хоть и не полная ) диаграмма часто использующихся коллекций - http://dobrokot.ru/pics/tya2010-10-12__12-06-37_c0.jpg .
*TreeSet/TreeMap - сортированные, сделаны на красно-черном дереве.
*ArrayList - динамический массив.
*HashSet/HashMap - понятно из названия.
*LinkedHashMap/LinkedHashSet - запоминают порядок вставленных элементов.
*Vector, Hashtable - потокобезопасные, поэтому чуть тормозней, а так же устарели, вместо них - java.util.concurrent.*, более эффективные и с адекватным интерфейсом для многопоточности.
Более полный (и таки остающийся лаконичным) обзор - http://en.wikibooks.org/wiki/Java_Programming/Collection_Classes

Про @Annотации можно прочитать здесь и простой, но жизненный пример здесь.

Для сравнения строк надо использовать str1.equals(str2) и возможно проверить str1 на null o_O. '==' сравнивает ссылки на объекты в памяти.

Писать легко, читать написанное не очень, много строчек кода ни о чем. Геттеры, классы для пары интов с мнемоническим именем за километр от использования, толстая кожура анонимных классов с небольшим семечком унутре, ручной парсинг строк, импорты, XML-конфигурации, дерево папок проекта, цепочка объектов AbstractCreator.createManager(new XmlConfiguration(getXmlConfigurationFilename())).getExecutor().Execute() для одной операции, методы equals (напоминаю, мы читаем для дебага, а не автогенерим).
Что бы прочитать код, который складывает строки, надо или читать простыную кода со StringBuilder, или знать org.apache.commons (StringUtils), этакий С++ boost, только для Java.