Java - общие проблемы

Пойду первым, вот один, которого я поймал сегодня. Это было связано с путаницей Long / long.

public void foo(Object obj) {
    if (grass.isGreen()) {
        Long id = grass.getId();
        foo(id);
    }
}
private void foo(long id) {
    Lawn lawn = bar.getLawn(id);
    if (lawn == null) {
        throw new IllegalStateException("grass should be associated with a lawn");
    }   
}

Очевидно, имена были изменены, чтобы защитить невиновных :)

если у вас есть метод с тем же именем, что и конструктор, НО имеет возвращаемый тип. Хотя этот метод выглядит как конструктор (для новичка), это НЕ.

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

прохождение. в качестве аргумента пути к классам для выполнения программы в текущем каталоге.

Понимая, что имя массива строк неочевидно

hashCode и равно: многие java-разработчики с опытом работы более 5 лет не совсем понимают это.

Установить против списка

До JDK 6 в Java не было NavigableSets, чтобы можно было легко перебирать Set и Map.

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

Сравнение равенства объектов с использованием == вместо .equals() - что ведет себя совершенно иначе для примитивов.

Эта проблема гарантирует, что новички будут сбиты с толку, когда "foo" == "foo", но new String("foo") != new String("foo").

Переопределение equals (), но не hashCode ()

Это может привести к неожиданным результатам при использовании карт, наборов или списков.

Я думаю, что очень хитрым является метод String.substring. Это повторно использует тот же базовый массив char[], что и исходная строка, с другими offset и length.

Это может привести к очень трудно заметным проблемам с памятью. Например, вы можете анализировать очень большие файлы (возможно, XML) на несколько небольших битов. Если вы преобразовали весь файл в String (вместо того, чтобы использовать Reader для «обхода» файла) и использовали substring для захвата нужных вам битов, вы все равно несете за кулисами полный массив char[] размером с файл. Я видел, как это происходило несколько раз, и заметить это бывает очень сложно.

Фактически, это прекрасный пример того, почему интерфейс нельзя полностью отделить от выполнение. И это было прекрасным введением (для меня) несколько лет назад, почему вы должны с подозрением относиться к качеству стороннего кода.

Еще один момент, на который я хотел бы обратить внимание, - это (слишком распространенное) стремление сделать API универсальными. Использование хорошо продуманного универсального кода - это нормально. Создать свой собственный сложно. Очень сложный!

Достаточно взглянуть на функции сортировки / фильтрации в новом Swing JTable. Это полный кошмар. Очевидно, что вы, вероятно, захотите объединить фильтры в цепочку в реальной жизни, но я обнаружил, что это невозможно сделать без использования только необработанной типизированной версии предоставленных классов.

Манипулирование компонентами Swing извне потока отправки событий может привести к ошибкам, которые чрезвычайно трудно найти. Это то, о чем часто забываем даже мы (как опытные программисты с 3-мя годами опыта в Java)! Иногда эти ошибки проникают внутрь после правильного написания кода и небрежного рефакторинга впоследствии ...

Смотрите этот руководство, почему вы должен.

Хэш по умолчанию не является детерминированным, поэтому, если он используется для объектов в HashMap, порядок записей на этой карте может меняться от запуска к запуску.

В качестве простой демонстрации следующая программа может давать разные результаты в зависимости от того, как она выполняется:

public static void main(String[] args) {
    System.out.println(new Object().hashCode());
}

То, сколько памяти выделено для кучи или запускаете ли вы ее в отладчике, может повлиять на результат.

SimpleDateFormat не является потокобезопасным.

(un) Бокс и долгая / долгая путаница. В отличие от опыта до Java 5, вы можете получить исключение NullPointerException во второй строке ниже.

Long msec = getSleepMsec();
Thread.sleep(msec);

Если getSleepTime () возвращает значение null, при распаковке выполняется ошибка.

List<Integer> list = new java.util.ArrayList<Integer>();
list.add(1);
list.remove(1); // throws...

Старые API-интерфейсы не разрабатывались с учетом бокса, поэтому перегружайте их примитивами и объектами.

Среди распространенных ошибок, хорошо известных, но все же иногда кусающих программистов, есть классический if (a = b), который встречается во всех C-подобных языках.

В Java это может работать, конечно, только если a и b логические. Но я слишком часто вижу, как новички тестируют if (a == true) (тогда как if (a) короче, читаемее и безопаснее ...) и иногда по ошибке пишут if (a = true), задаваясь вопросом, почему тест не работает. Для тех, кто этого не понимает: последний оператор сначала присваивает truea, а затем выполняет тест, который всегда успешен!

-

Тот, который кусает многих новичков и даже некоторых отвлекающих более опытных программистов (нашел это в нашем коде), if (str == "foo"). Обратите внимание, что мне всегда было интересно, почему Sun отменяет знак + для строк, но не знак ==, по крайней мере, для простых случаев (с учетом регистра).

Для новичков: == сравнивает ссылки, а не содержимое строк. У вас может быть две строки с одинаковым содержимым, хранящиеся в разных объектах (разные ссылки), поэтому == будет ложным.

Простой пример:

final String F = "Foo";
String a = F;
String b = F;
assert a == b; // Works! They refer to the same object
String c = "F" + F.substring(1); // Still "Foo"
assert c.equals(a); // Works
assert c == a; // Fails

-

Еще я видел if (a == b & c == d) или что-то в этом роде. Это работает (как ни странно), но мы потеряли ярлык логического оператора (не пытайтесь писать: if (r != null & r.isSomething())!).

Для новичков: при оценке a && b Java не оценивает b, если a ложно. В a & b Java оценивает обе части, а затем выполняет операцию; но вторая часть может провалиться.

[EDIT] Хорошее предложение от J Coombs, я обновил свой ответ.

Есть два, которые меня немного раздражают.

Дата / Календарь

Во-первых, классы Java Date и Calendar серьезно испорчены. Я знаю, что есть предложения по их устранению, я просто надеюсь, что они удастся.

Calendar.get (Calendar.DAY_OF_MONTH) основан на 1
Calendar.get (Calendar.MONTH) - 0 на основе

Автобокс мешает думать

Другой - Integer vs int (это касается любой примитивной версии объекта). Это, в частности, раздражение, вызванное тем, что вы не думаете, что Integer отличается от int (поскольку вы можете обрабатывать их одинаково большую часть времени из-за автобокса).

int x = 5;
int y = 5;
Integer z = new Integer(5);
Integer t = new Integer(5);

System.out.println(5 == x);     // Prints true
System.out.println(x == y);     // Prints true
System.out.println(x == z);     // Prints true (auto-boxing can be so nice)
System.out.println(5 == z);     // Prints true
System.out.println(z == t);     // Prints SOMETHING

Поскольку z и t являются объектами, даже несмотря на то, что они имеют одинаковое значение, они (скорее всего) являются разными объектами. На самом деле вы имели в виду:

System.out.println(z.equals(t));   // Prints true

Это может быть проблемой для отслеживания. Вы что-то отлаживаете, все выглядит нормально, и вы, наконец, обнаруживаете, что ваша проблема в том, что 5! = 5, когда оба являются объектами.

Возможность сказать

List<Integer> stuff = new ArrayList<Integer>();

stuff.add(5);

так приятно. Это сделало Java настолько удобнее в использовании, что не нужно было помещать все эти строки «new Integer (5)» и «((Integer) list.get (3)). IntValue ()» повсюду. Но эти преимущества приходят с этим.

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

ClassNotFoundException --- вы знаете, что класс находится в пути к классам, НО вы НЕ уверены, почему класс НЕ загружается.

Собственно, у этого класса есть статический блок. Произошло исключение в статическом блоке, и кто-то съел исключение. они НЕ ДОЛЖНЫ. Они должны бросать ExceptionInInitializerError. Так что всегда ищите статические блоки, которые могут вас сбить с толку. Это также помогает переместить любой код в статических блоках в статические методы, чтобы упростить отладку метода с помощью отладчика.

Целочисленное деление

1/2 == 0 not 0.5

Поплавки

Я не знаю, много раз я видел

floata == floatb

где должен быть "правильный" тест

Math.abs(floata - floatb) < 0.001

Я действительно хочу, чтобы BigDecimal с буквальным синтаксисом был десятичным типом по умолчанию ...

ИМХО 1. Использование vector.add (Collection) вместо vector.addall (Collection). Первый добавляет объект коллекции в вектор, а второй добавляет содержимое коллекции. 2. Использование синтаксических анализаторов xml, которые поступают из нескольких источников, таких как xerces, jdom, не имеет прямого отношения к программированию. Полагаться на разные парсеры и иметь их jar-файлы в пути к классам - это кошмар.

Неизменяемые строки, что означает, что некоторые методы не изменяют исходный объект, а вместо этого возвращают измененную копию объекта. Начиная с Java, я все время забывал об этом и задавался вопросом, почему метод replace не работает с моим строковым объектом.

String text = "foobar";
text.replace("foo", "super");
System.out.print(text); // still prints "foobar" instead of "superbar"

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

Реализация системы универсальных типов со стиранием типов ужасна и сбивает с толку большинство студентов, когда они впервые узнают о универсальных типах в Java: почему нам все еще нужно приводить типы, если параметр типа уже предоставлен? Да, они обеспечивали обратную совместимость, но довольно глупой ценой.

Я только что наткнулся на этот:

double[] aList = new double[400];

List l = Arrays.asList(aList);
//do intense stuff with l

Кто-нибудь видит проблему?

Что происходит, Arrays.asList() ожидает массив типов объектов (например, Double []). Было бы неплохо, если бы он просто выдавал ошибку для предыдущего ocde. Однако asList() также может принимать такие аргументы:

Arrays.asList(1, 9, 4, 4, 20);

Итак, код создает List с одним элементом - double[].

Я должен был догадаться, когда для сортировки массива из 750000 элементов потребовалось 0 мс ...

"a,b,c,d,,,".split(",").length

возвращает 4, нет 7, как вы могли (и я, конечно, сделал) ожидать. split игнорирует все завершающие возвращенные пустые строки. Это значит:

",,,a,b,c,d".split(",").length

возвращает 7! Чтобы добиться того, что я бы назвал «наименее удивительным», вам нужно сделать что-нибудь весьма удивительное:

"a,b,c,d,,,".split(",",-1).length

чтобы получить 7.

Я думаю, что у меня большая проблема, которая всегда ставила меня в тупик, когда я был молодым программистом, был исключение одновременной модификации при удалении из массива, который вы повторяли:

  List list = new ArrayList();
    Iterator it = list.iterator();
    while(it.hasNext()){
      //some code that does some stuff
      list.remove(0); //BOOM!
  }

Не совсем специфично для Java, поскольку многие (но не все) языки реализуют это таким образом, но оператор % не является истинным оператором по модулю, поскольку он работает с отрицательными числами. Это делает его оператором остаток и может привести к некоторым сюрпризам, если вы об этом не знаете.

Следующий код может выводить либо «четное», либо «нечетное», но это не так.

public static void main(String[] args)
{
    String a = null;
    int n = "number".hashCode();

    switch( n % 2 ) {
        case 0:
            a = "even";
            break;
        case 1:
            a = "odd";
            break;
    }

    System.out.println( a );
}

Проблема в том, что хэш-код для «числа» отрицательный, поэтому операция n % 2 в коммутаторе также отрицательна. Поскольку в переключателе нет случая, чтобы иметь дело с отрицательным результатом, переменная a никогда не устанавливается. Программа распечатает null.

Убедитесь, что вы знаете, как оператор % работает с отрицательными числами, независимо от того, на каком языке вы работаете.

Когда вы создаете duplicate или slice из ByteBuffer, он не наследует значение свойства order из родительского буфера, поэтому такой код не будет делать то, что вы ожидаете:

ByteBuffer buffer1 = ByteBuffer.allocate(8);
buffer1.order(ByteOrder.LITTLE_ENDIAN);
buffer1.putInt(2, 1234);

ByteBuffer buffer2 = buffer1.duplicate();
System.out.println(buffer2.getInt(2));
// Output is "-771489792", not "1234" as expected

    System.out.println(Calendar.getInstance(TimeZone.getTimeZone("Asia/Hong_Kong")).getTime());
    System.out.println(Calendar.getInstance(TimeZone.getTimeZone("America/Jamaica")).getTime());

Выход такой же.

Использование подстановочного знака универсальных шаблонов ?.

Люди видят это и думают, что должны, например используйте List<?>, когда им нужен List, к которому они могут добавить что угодно, не думая, что List<Object> уже делает это. Затем они задаются вопросом, почему компилятор не позволяет им использовать add(), потому что List<?> на самом деле означает «список какого-то определенного типа, которого я не знаю», поэтому единственное, что вы можете сделать с этим List, - это получить из него экземпляры Object.

Однажды мне было интересно отладить TreeSet, так как я не знал об этой информации из API:

Note that the ordering maintained by a set (whether or not an explicit comparator is provided) must be consistent with equals if it is to correctly implement the Set interface. (See Comparable or Comparator for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a TreeSet instance performs all key comparisons using its compareTo (or compare) method, so two keys that are deemed equal by this method are, from the standpoint of the set, equal. The behavior of a set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface. http://download.oracle.com/javase/1.4.2/docs/api/java/util/TreeSet.html

Объекты с правильными реализациями equals / hashcode добавлялись и никогда больше не встречались, поскольку реализация compareTo несовместима с equals.