Каков самый вводящий в заблуждение метод в Основе Java API? [закрытый]

Метод URL equals () сравнивает IP-адреса, использует сетевое соединение и является операцией блокировки!

Из документации javadocs:

Два хоста считаются эквивалентными, если оба имени хоста могут быть решено на одни и те же IP-адреса; иначе, если имя хоста не может быть разрешено, имена хостов должны быть одинаковыми без учета регистра; или оба имена хостов равны нулю.

Поскольку сравнение хостов требует разрешения имен, эта операция блокирующая операция.

Примечание. Определенное поведение для equals известно несовместимы с виртуальным хостингом в HTTP.

Вместо этого используйте URI.

Одна из моих любимых проблем с Java - это тот факт, что сбой в Integer.parseInt ("SomeString") просто указывает на то, что произошла ошибка синтаксического анализа, и не может сказать нам, что такое "SomeString" был. Из-за этого иногда необходимо выполнить множество отладок, чтобы выяснить, что это за строка. Если бы сообщение об ошибке включало ошибочную строку, выявление проблемы было бы намного быстрее.

Я бы не стал помещать его в раздел «Самый неловкий», но java.security.MessageDigest.getInstance () меня немного смутил.

Обычно я вижу «getInstance» () "метод возвращает Singleton.

Если метод должен возвращать новый экземпляр, я могу ожидать увидеть MessageDigestFactory.newInstance () или, по крайней мере, newInstance () в классе MessageDigest вместо их getInstance ().

См .: MessageDigest.getInstance ()

Из того, что я тестировал, MessageDigest.getInstance () возвращает экземпляр New каждый раз, когда он вызывается.

BigDecimal .setScale (int) сеттер, который возвращает BigDecimal хммм

Согласен. Мне всегда было неудобно с этими методами.

Я даже обнаружил ошибку в нашей базе кода, которая была вызвана тем, что кто-то использовал Integer.getInteger () для анализа строки, не осознавая, что ищет свойство.

К сожалению, конечно, невозможно удалить API из соображений обратной совместимости.

Я не уверен, что кто-то все еще использует это, но сообщение об ошибке от DocumentBuilder.parse () , если что-то пойдет не так, (почти?) Всегда "Content is not разрешено в прологе ". даже если настоящая причина была совсем в другом.

Я так и не понял, почему JDBC API постоянно начинает отсчет с 1, в то время как остальная часть юниверса Java (и C, C ++, C #, ...) начинается с 0. Это относится к номера столбцов, номера параметров в подготовленных операторах и т. д.

InputStream.read (byte [])

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

Некоторые редакторы заметили, что String.substring приводит к утечкам памяти, потому что внутри он не копирует подстроку, а просто копирует указатель на всю строку + смещение + длина. Так что, если вы ожидали, что сборщик мусора будет собирать всю строку, вы ошиблись.

http://www.reddit.com/r/programming/comments/8ydvg/the_dangers_of_stringsubstring/c0au0gj

Ну, System.setOut () установит значение в final член System !!!!

Вероятно, это не худший метод, но мне никогда не нравился этот :

Предположим, x - это список, который, как известно, содержит только строки. Следующий код можно использовать для выгрузки списка во вновь выделенный массив String:

String[] y = x.toArray(new String[0]);

Передача в метод массива String размера 0 кажется мне безумной и неинтуитивной.

Только что узнал о методах isInterrupted и interrupted класса Thread . Из javadoc :

static boolean interrupted()
// Tests whether the current thread has been interrupted.
boolean isInterrupted()
// Tests whether this thread has been interrupted.

Проблема в том, что прервано на самом деле очищает статус прерывания, помимо выполнения теста, а isInterrupted просто проверяет статус.

String.getBytes()

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

Одна хорошо известная проблема с классом Calendar состоит в том, что месяцы нумеруются от 0 до 11, а не от 1 до 12. Очень легко сделать такую ​​ошибку:

Calendar cal = Calendar.getInstance();

// Set date to August 18, 2009? WRONG! Sets the date to September 18, 2009!
cal.set(2009, 8, 18);

Правильный способ сделать это, используя константы для месяцев:

cal.set(2009, Calendar.AUGUST, 18);

Но этот метод слишком легко делает ошибку, используя обычные номера месяцев от 1 до 12.

Я считаю это ошибкой при разработке Календаря. класс.

Моя проблема связана с методом подстроки String; каждый раз, когда я его использую, мне приходится писать слова «гамбургер» и «гамбургер». substring (4,8) = «настоятельно рекомендуется» вспомнить, как его правильно использовать

Только что получил это из здесь , относительно методов add и remove из List ( при параметрировании с помощью Целое число ). Например:

List<Integer> l = new ArrayList<Integer>();
l.add(20);
l.remove(20); // throws ArrayIndexOutOfBoundsException, because it will try to access index 20
l.remove(new Integer(20)); // this works   

java.util.Date.getDate () вернул число 1-31. getDayOfMonth () - точный способ объяснить это, в то время как вы обычно пытались вспомнить getTime () .

Не могу дождаться, пока Джода Тайм возьмет верх.