Java: покончим со старым, войдем с новым

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

Обновлено:

До:

List l = someList;
Iterator i = l.getIterator();
while (i.hasNext()) {
    MyObject o = (MyObject)i.next();
}

После

List<MyObject> l = someList;
for (MyObject o : l) {
    //do something
}

Q1: Что ж, наиболее очевидные ситуации находятся в коллекциях для конкретных типов / типов. Еще один момент, который сразу приходит в голову, - это улучшенный цикл for, который, как мне кажется, выглядит намного чище и проще для понимания.

Q2: Как правило, я объединяю JVM вместе со своим приложением для приложений, ориентированных на клиентов. Это позволяет нам использовать новые языковые функции, не беспокоясь о несовместимости JVM.

Если бы я не собирал JRE, я бы, вероятно, придерживался 1.4 из соображений совместимости.

Преобразование числа в строку:

String s = n + "";

В этом случае я думаю, что всегда был лучший способ сделать это:

String s = String.valueOf(n);

Простое изменение с версии 1.5, но имеет небольшое различие - в Swing API, обращающемся к contentPane JFrame:

myframe.getContentPane().add(mycomponent);

становится

myframe.add(mycomponent);

И, конечно же, введение Enums изменило поведение многих приложений, которые в прошлом использовали константы.

String.format () значительно улучшил манипуляции со строками, а тернарный оператор if весьма полезен для облегчения чтения кода.

Enums. Замена

public static final int CLUBS = 0;
public static final int DIAMONDS = 1;
public static final int HEARTS = 2;
public static final int SPADES = 3;

с

public enum Suit { 
  CLUBS, 
  DIAMONDS, 
  HEARTS, 
  SPADES 
}

Вот один, который я вижу:

String.split() против StringTokenizer.

StringTokenizer не рекомендуется для нового кода, но я все еще вижу, что люди его используют.

Что касается совместимости, Sun прилагает огромные усилия для обеспечения обратной и прямой совместимости с Java. Это частично объясняет, почему дженерики такие сложные. Предполагается, что устаревание также поможет облегчить переход от старого кода к новому.

Использование локальных переменных типа StringBuffer для конкатенации строк. Если синхронизация не требуется, теперь рекомендуется использовать StringBuilder, потому что этот класс предлагает лучшую производительность (предположительно, потому что он не синхронизирован).

Использование локальных переменных типа Vector для хранения списка объектов. Если синхронизация не требуется, теперь рекомендуется использовать реализацию списка, такую ​​как ArrayList, потому что этот класс обеспечивает лучшую производительность (поскольку он не синхронизирован).

Явное преобразование между примитивным типом и типом оболочки (например, Integer в int или наоборот), которое выполняется автоматически с помощью автобокса / распаковки, начиная с Java 1.5.

Примером является

Integer myInteger = 6;
int myInt = myInteger.intValue();

Можно просто записать как

Integer myInteger = 6;
int myInt = myInteger;

Но остерегайтесь NullPointerExceptions :)

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

Если вы просто оставите старый код в покое, то писать новый код с использованием новых функций не так страшно.

Общие коллекции делают кодирование более устойчивым к ошибкам. СТАРЫЙ:

Vector stringVector = new Vector();
stringVector.add("hi");
stringVector.add(528); // oops!
stringVector.add(new Whatzit());  // Oh my, could spell trouble later on!

НОВЫЙ:

ArrayList<String> stringList = new ArrayList<String>();
stringList.add("hello again");
stringList.add(new Whatzit()); // Won't compile!

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

Видеть:

java.util.Timer

javax.swing.Timer

java.util.concurrent. *

Используя итератор:

List list = getTheList();
Iterator iter = list.iterator()
while (iter.hasNext()) {
  String s = (String) iter.next();
    // .. do something
}

Или иногда можно увидеть альтернативную форму:

List list = getTheList();
for (Iterator iter = list.iterator(); iter.hasNext();) {
  String s = (String) iter.next();
  // .. do something
}

Теперь все заменено на:

List<String> list = getTheList();
for (String s : list) {
  // .. do something
}

Строковые сравнения, действительно старые программисты Java, которых я встречал, сделали бы:

String s1 = "...", s2 = "...";

if (s1.intern() == s2.intern()) {
    ....
}

(Предположительно по соображениям производительности)

В то время как в наши дни большинство людей просто делают:

String s1 = "...", s2 = "...";

if (s1.equals(s2)) {
    ....
}

VARARGS тоже могут быть полезны.

Например, вы можете использовать:

public int add(int... numbers){
    int sum = 0 ;
    for (int i : numbers){
        sum+=i;
    }
    return sum ;
}

вместо:

public int add(int n1, int n2, int n3, int n4) ;

или же

public int add(List<Integer> numbers) ;

Использование вектора вместо новых коллекций.

Использование классов вместо перечислений

 public class Enum
  {
      public static final Enum FOO = new Enum();
      public static final Enum BAR = new Enum();
  }

Использование Thread вместо нового пакета java.util.concurrency.

Использование интерфейсов маркеров вместо аннотаций

Изменение тестов в стиле JUnit 3:

class Test extends TestCase {
    public void testYadaYada() { ... }
}

в тесты в стиле JUnit 4:

class Test {
   @Test public void yadaYada() { ... }
}

Хотя я признаю, что статическим импортом можно легко злоупотреблять, мне нравится использовать

import static Math.* ;

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

Новая конструкция for-each для перебора массивов и коллекций является для меня самой большой.

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

// AGGHHH!!!
int[] array = new int[] {0, 1, 2, 3, 4};
for (int i = 0; i < array.length; i++)
{
    // Do something...
}

Замена вышеуказанного на Конструкция for, представленная в Java 5:

// Nice and clean.    
int[] array = new int[] {0, 1, 2, 3, 4};
for (int n : array)
{
    // Do something...
}

Чистый, лаконичный и, что самое главное, он дает коду смысл, а не показывает, что как что-то делает.

Ясно, что код имеет смысл перебирать коллекцию, а не старый цикл for, говорящий, как перебирать массив.

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

Форматированная печать была введена только в JDK 1.5. Поэтому вместо использования:

String str = "test " + intValue + " test " + doubleValue;

или эквивалент с использованием StringBuilder,

можно использовать

String str = String.format("test %d test %lg", intValue, doubleValue);

Последний вариант гораздо более читабелен как в версии с конкатенацией строк, так и в версиях построителя строк. Тем не менее, я считаю, что люди очень медленно перенимают этот стиль. Например, фреймворк Log4j не использует это, хотя я считаю, что это было бы очень полезно.

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

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

В конце концов, этот пример на самом деле не удаляет код плиты котла., они просто используют более управляемые конструкции новых JDK для сделать красивый код котельной плиты.

Большинство способов сделать ваш код элегантным не входят в JDK.

Хорошо, теперь моя очередь кричать на меня.

Я не рекомендую 90% этих изменений.

Это не значит, что использовать их с новым кодом - плохая идея, но взлом существующего кода для изменения цикла for на цикл for (:) - это просто пустая трата времени и шанс что-то сломать. (IIWDFWI) Если работает, не исправляйте!

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

Если кто-то, выполняющий такого рода рефакторинг без всякой причины, вызвал ЛЮБУЮ проблему, я бы не стал им насрать.

С другой стороны, если вы находитесь в коде и все равно меняете что-то в этой строке, не стесняйтесь ее очищать.

Кроме того, все предложения в названии «Производительность» действительно нужно узнать о законах оптимизации. В двух словах: не надо! Всегда! (Погуглите "Правила оптимизации, если не верите)".

Относится к varargs; очень полезен служебный метод Arrays.asList (), который, начиная с Java 5, принимает параметры varargs.

Я часто замечаю, что упрощаю что-то вроде

List<String> items = new ArrayList<String>();
items.add("one");
items.add("two");
items.add("three");
handleItems(items);

используя

handleItems(Arrays.asList("one", "two", "three"));

чтение строки из стандартного ввода:

Java pre-5:

try {
    BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
    String str = reader.readLine();
    reader.close();
}
catch (IOException e) {
    System.err.println("error when closing input stream.");
}

Java 5:

Scanner reader = new Scanner(System.in);
String str = reader.nextLine();
reader.close();

Java 6:

Console reader = System.console();
String str = reader.readLine();

Использование нового Swing DefaultRowSorter для сортировки таблиц вместо создания собственных с нуля.

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

копирование существующего массива в новый массив:

до Java 5:

int[] src = new int[] {1, 2, 3, 4, 5};
int[] dest = new int[src.length];
System.arraycopy(src, 0, dest, 0, src.length);

Java 6:

int[] src = new int[] {1, 2, 3, 4, 5};
int[] dest = Arrays.copyOf(src, src.length);

раньше мне приходилось явно создавать новый массив, а затем копировать исходные элементы в новый массив (вызывая метод с большим количеством параметров). теперь синтаксис стал более чистым, и новый массив возвращается из метода, мне не нужно его создавать. кстати, у метода Arrays.copyOf есть вариант под названием Arrays.copyOfRange, который копирует определенную область исходного массива (очень похоже на System.arraycopy).

Аннотации

Интересно, что до сих пор об этом никто не упоминал, но многие фреймворки полагаются на аннотации, например Spring и Спящий режим.. Сегодня широко распространено устаревание файлов конфигурации xml в пользу аннотаций в коде (хотя это означает потерю гибкости при переходе от конфигурации к мета- код, но часто это правильный выбор). Лучшим примером является EJB 2 (и старше) по сравнению с EJB 3.0 и то, как программирование EJB было упрощено благодаря аннотациям.

Я считаю, что аннотации также очень полезны в сочетании с некоторыми инструментами АОП, такими как AspectJ или Spring AOP. Такое сочетание может быть очень мощным.

Улучшены одноэлементные шаблоны. Технически они относятся к популярным перечислениям ответов, но это важная подкатегория.

public enum Singleton {
    INSTANCE;

    public void someMethod() {
        ...
    }
}

чище и безопаснее, чем

public class Singleton {
    public static final Singleton INSTANCE = new Singleton();

    private Singleton() {
        ...
    }

    public void someMethod() {
        ...
    }
}