Entries tagged with java

Entry tags:

java

java try parse integer

А почему в java нету готовых методов, которые бы позволяли парсить числа, не кидая исключений?
Т.е. возвращали бы true+число, либо false, типа как int.TryParse в дотнете.

Entry tags:

Разбираюсь потиху с Intellij IDEA и скалой. И, как обычно, утыкаюсь в "расхождения по земельному вопросу" с жабными инструментами. Сколько раз это все дело открывал - столько утыкался.

Вот у нас есть на данный момент что: jdk (много разных), мавен(две версии), sbt(аналог мавена для скалы), IDEA и тыщи плагинов под мавен, sbt и идею.
Я прочел документацию по мавену и sbt, но от входа все равно не понимаю, как принято создавать проекты с нуля и как принято их деплоить. Открываешь какой-нибудь пример, а там все заканчивается строкой вида sbt container:start, которая работает исключительно внутри запущенного sbt и с помощью плагина типа "com.github.siasia" %% "xsbt-web-plugin. Или мавен с jetty-плагином.

Предположительно, можно поставить jetty сервисом и деплоить туда приложение в виде war. Но сборка этого war и особенно копирование зависимостей для него для меня темный лес.
Я обычно начинаю с того, что запускаю jetty внутри своего приложения, передавая ему хендлер явно, т.к. таким образом для меня проще понять, что в каком порядке работает и откуда берется конфигурация. Но даже в этом случае количество вариаций на тему "запустить жабу с указанием classpath и main class" просто поражает.
Т.е. запуск из мавена, запуск из sbt, запуск из idea, деплоймент в контейнер и запуск из консоли руками и запуск в виде jar - это все совершенно между собой различающиеся варианты, с разными classpath, разными репозиториями и прочим таким.

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

Entry tags:

Злонравия достойные плоды

Скачал вчера EAP 12.1 Intellij IDEA.
Еле нашел, потому как гугл выдает ссылку на 12, которое уже релиз, но в нем по некоей причине не ставится Scala плагин.

Жаба-хелло-ворлд в идее делается и запускается, как положено, за 1 минуту.

Ради эксперимента импортировал проект на Clojure. Количество чернейшего вуду, которое при этом откопалось, не поддается осмыслению.
Во-первых, пришлось в конце-концов разобраться как правильно обращаться к файлам .properties, которые лежат в classpath.
Во-вторых, отсутствие явного разделения фаз "сборка" и "запуск" играет злые шутки с auto-make в IDEA - у меня импорт некоторых файлов (который выполняется класс-лоадером на этапе компиляции) вызывает обращение к БД, а обращение к БД при отсутствующем файле конфига кидает совершенно дикие ошибки вида "Clojure Compiler: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (GDS Exception. 335544382. Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long".
Это так Firebird JDBC драйвер кидает ошибку, когда не указано имя пользователя, пароль или роль. Без многолетнего опыта общения с этим говнищем - никогда в жизни по сообщению не догадаешься, что сделано не так.

В-третьих, запуск кложурных приложений бывает в таком количестве вариаций, что как их всунуть в идею, я пока не догоняю. Сервис-приложение-исходники-скомпилированные классы-репл-черти лысые.

Зато в идее логичный auto-completion и есть (наконец-то!!) поиск символа по всему проекту по горячей клавише. Причем именно так, как это должно быть - "вызвал поиск, нашел, нажал enter, оказался где надо".
И есть в хелпе первым пунктом поиск действий по описанию.

Entry tags:

clojure,
java

О проверке входных параметров, принятой в Java

Есть такой оккультный стек-трейс: https://gist.github.com/def1fa8666a8ac83130a.
Причина в том, что в деконструктор массивов кложури вида (let [sql & params] some-array] передан пустой массив и строка sql в таком случае становится null и оный null передается в jdbc драйвер.
Строка на которой валится NPE, выглядит следующим образом:
protected boolean checkForEscapes(String sql) {
sql = sql.toLowerCase();

А вопрос, вообще говоря, в следующем: почему никто не проверяет параметр на валидность хотя бы в одной точке входа в одной из трех либ (clojure.java.jdbc, apache dbcp или jaybird)?

Выглядит так, как будто нормальную проверку параметров на валидность на границах API в жабе делать не принято.

PS:

artureg упорно убеждает меня, что "пусть валится", потому что проверка должна быть "в другом слое". Судя по всему, все разработчики думают, что обработка ошибок должна быть в другом слое :)

java try parse integer

Java-экосистема

Злонравия достойные плоды

О проверке входных параметров, принятой в Java