Java: со старым, в с новым

Используя Вектор вместо новых Наборов.

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

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

Используя Поток вместо нового java.util.concurrency пакета.

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошо, теперь это - моя очередь, которая будет вопиться в.

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

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

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

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

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

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

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

Изменение JUnit тесты с 3 стилями:

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

к тестам с 4 стилями JUnit:

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

Связанный с 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"));

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

В эти дни, когда когда-либо я вижу шаблон 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 цикл, говорящий, как выполнить итерации по массиву.

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

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

String s = n + "";

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

String s = String.valueOf(n);

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

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
}

Универсальные наборы делают кодирование намного более стойким к ошибке. СТАРЫЙ:

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!

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

myframe.getContentPane().add(mycomponent);

становится

myframe.add(mycomponent);

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

String.format () значительно улучшил Обработку строк и троичное, если оператор довольно полезен в создании кода, легче читать.

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

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

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

Отформатированная печать уже была представлена в JDK 1.5. Таким образом вместо использования:

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

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

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

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

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

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

пример

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

, Может просто быть записан как

Integer myInteger = 6;
int myInt = myInteger;

, Но не упустить NullPointerExceptions:)

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) ;

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

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

См.:

java.util. Таймер

javax.swing. Таймер

java.util.concurrent.*

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

String.split() по сравнению с StringTokenizer.

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

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

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

РЕДАКТИРОВАНИЕ:

Прежде:

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
}

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

import static Math.* ;

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

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

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

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

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();

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

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

pre-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 и Hibernate. Сегодня обычным явлением является устаревание файлов конфигурации 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() {
        ...
    }
}