Что является наиболее вводящим в заблуждение методом в Java Base API?
Недавно я пытался преобразовать строковый литерал в boolean когда метод boolean Boolean.getBoolean(String name) выскочил из окна автозаполнения. Был и другой способ (boolean Boolean.parseBoolean(String s)) появился сразу после этого, что привело меня к поиску, чтобы выяснить, в чем были различия между этими двумя, так как они оба, казалось, делали то же самое.
Оказывается, что, что Boolean.getBoolean(String name) на самом деле это проверить, существует ли System свойство (!) данного имени и если его значение true, Я думаю, что это очень вводит в заблуждение, так как я определенно не ожидаю, что метод Boolean на самом деле звонит System.getProperty и, просто взглянув на сигнатуру метода, он выглядит (по крайней мере для меня) так, как будто он должен использоваться для анализа String как boolean, Несомненно, Javadoc ясно заявляет об этом, но я все еще думаю, что у метода есть вводящее в заблуждение название, и это не в правильном месте. Другие обертки примитивного типа, такие как Integer Также есть аналогичный метод.
Кроме того, кажется, что это не очень полезный метод для включения в базовый API, так как я думаю, что не очень часто иметь что-то вроде -Darg=true, Может быть, это хороший вопрос для интервью о позиции на Java: "Каковы результаты Boolean.getBoolean("true")?". Я считаю, что более подходящее место для этих методов будет в System класс, например, getPropertyAsBoolean; но опять же, я все еще думаю, что нет необходимости иметь эти методы в базовом API. Было бы разумно иметь их в чем-то вроде Properties класс, где очень распространены такие преобразования.
Что вы думаете обо всем этом? Кроме того, если есть еще один "неуклюжий" метод, который вам известен, пожалуйста, опубликуйте его.
NB Я знаю, что могу использовать Boolean.valueOf или же Boolean.parseBoolean преобразовать строковый литерал в boolean, но я просто хочу обсудить дизайн API.
17 ответов
Метод URL equals() сравнивает IP-адреса, использует сетевое соединение и является блокирующей операцией!
Из Javadocs:
Два хоста считаются эквивалентными, если оба имени хоста могут быть преобразованы в одинаковые IP-адреса; в противном случае, если какое-либо имя хоста не может быть разрешено, имена хостов должны быть равны без учета регистра; или оба имени хоста равны нулю.
Поскольку сравнение хостов требует разрешения имен, эта операция является операцией блокировки.
Примечание. Известно, что определенное поведение для equals несовместимо с виртуальным хостингом в HTTP.
Вместо этого используйте URI.
Одна известная проблема с классом 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.
Я считаю это ошибкой в дизайне класса Calendar.
Только что получил это здесь, относительно add а также remove методы List (при параметризации с Integer). Например:
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
String.getBytes()
часто причиной многих глупых проблем кодирования символов в приложениях, потому что используется базовая кодировка символов платформы.
Просто узнал о методах isInterrupted а также interrupted класса Thread, От javadoc:
static boolean interrupted()
// Tests whether the current thread has been interrupted.
boolean isInterrupted()
// Tests whether this thread has been interrupted.
Проблема в том, что interrupted на самом деле очищает прерванный статус помимо выполнения теста, в то время как isInterrupted просто проверяет статус.
Это, вероятно, не самый плохой метод, но мне никогда не нравился этот:
Предположим, что x - это список, который содержит только строки. Следующий код может быть использован для выгрузки списка во вновь выделенный массив String:
String[] y = x.toArray(new String[0]);
Передача массива String размером 0 в метод просто кажется мне безумной и не интуитивно понятной.
Не заполняет массив; вместо этого он читает произвольное количество байтов и возвращает это число. Вы должны зациклить. Противно, потому что это работает правильно для небольших массивов большую часть времени. Я не думаю, что кто-то понимает это правильно в первый раз, когда они его используют.
Некоторые redditor заметили, что String.substring приводит к утечкам памяти, потому что внутренне он не копирует подстроку, а просто копирует указатель на целую строку + смещение + длина. Так что, если вы ожидали, что вся строка будет собрана GC, вы облажались.
http://www.reddit.com/r/programming/comments/8ydvg/the_dangers_of_stringsubstring/c0au0gj
Хорошо, System.setOut() установит значение для конечного члена System!!!!
Моя проблема с методом подстроки String; каждый раз, когда я использую его, я должен написать слова "гамбургер" и "гамбургер".substring(4,8) = "побуждение" вспомнить, как правильно его использовать
Я никогда не понимал, почему JDBC API последовательно начинает считать с 1, в то время как остальная часть юниверса Java (и C, C++, C#, ...) начинается с 0. Это относится к номерам столбцов, номерам параметров в подготовленных операторах и т. Д.
Согласен. Мне всегда было неудобно с этими методами.
Я даже нашел ошибку в нашей кодовой базе, которая была вызвана тем, что кто-то использовал Integer.getInteger() для анализа строки, не понимая, что он ищет это свойство.
К сожалению, конечно, нет способа удалить API из-за обратной совместимости.
BigDecimal.setScale(int) установщик, который возвращает BigDecimal хммм
Одно из моих любимых явлений в Java - тот факт, что сбой в Integer.parseInt("SomeString") просто говорит о том, что произошла ошибка синтаксического анализа, не сообщая нам, что такое "SomeString". Из-за этого иногда необходимо выполнить множество отладок, чтобы выяснить, что это за строка. Если в сообщении об ошибке указана ошибочная строка, поиск проблемы будет гораздо быстрее.
Я не уверен, что кто-то еще использует это, но сообщение об ошибке от DocumentBuilder.parse() если что-то идет не так (всегда?), всегда "Содержание не разрешено в прологе". даже если настоящая причина была совсем в другом.
Я не стал бы подавать его в "Most Awkward", но java.security.MessageDigest.getInstance() дал мне некоторую путаницу.
Обычно я вижу, как метод getInstance () возвращает Singleton.
Если метод должен вернуть новый экземпляр, я мог бы ожидать увидеть MessageDigestFactory.newInstance () или, по крайней мере, newInstance () в классе MessageDigest вместо их метода getInstance ().
Смотрите: MessageDigest.getInstance ()
Из того, что я тестировал, MessageDigest.getInstance () возвращает новый экземпляр каждый раз, когда он вызывается.
java.util.Date.getDate() вернул число 1-31. getDayOfMonth() это точный способ объяснить это, в то время как вы обычно пытались вспомнить getTime(),
Не могу дождаться, когда Йода Времени вступит во владение