JAVA

индекс
157,35

Что же всё-таки будет в Java 7 — окончательный список

Joe Darcy (лидер проекта Project Coin из Sun) выложил окончательный список нововведений языка Java 7 (оригинал тут). Вот эти нововведения:


String в switch-case выражениях:
Пример:

String s = ... 
switch(s) { 
    case "foo": processFoo(s); 
    break; 
}


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

BufferedReader br = new BufferedReader(new FileReader(path)); 
try {
    return br.readLine(); 
} 
finally { 
    br.close(); 
}

можно будет написать:

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
    return br.readLine(); 
}


Улучшенный вывод типов (type inference) при создании generic-экземляров

На сегодня в Java часто приходится повторяться при инициализации переменной generic-типом. Java 7 позволит делать то же самое более элегантно. Например, старая конструкция:

Map<String, List<String>> anagrams = new HashMap<String, List<String>>();

может быть переписана так:

Map<String, List<String>> anagrams = new HashMap<>();


Улучшенный вызов методов с переменным числом аргументов (varargs)

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

static <T> List<T> asList(T... elements) { ... } 
static List<Callable<String>> stringFactories() { 
    Callable<String> a, b, c; ... 
    *// Warning: **"uses unchecked or unsafe operations"*
    return asList(a, b, c); 
}

Теперь:

*// Warning: **"enables unsafe generic array creation"* 
static <T> List<T> asList(T... elements) { ... } 
static List<Callable<String>> stringFactories() {
    Callable<String> a, b, c; ... 
    return asList(a, b, c); 
}


Улучшенные литералы

Тут будут два нововведения: бинарные литералы (вида 0b101 или 0B101 ) и поддержка подчёркиваний в числовых литералах для лучшей читаемости (например 9_223_372_036_854_775_807L).

Встроенная в язык поддержка коллекций

Объединяет два нововведения: литералы коллекций и новый вид доступа к Lists и Maps (через []). Литералы коллекций упрощают инициализацию новых Lists, Sets и Maps. Раньше:

final List<Integer> piDigits = Collections.unmodifiableList(Arrays.asList(3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 9 ));


Теперь:

final List<Integer> piDigits = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 9];


При использовании фигурных скобок создаётся Set:

final Set<Integer> primes = { 2, 7, 31, 127, 8191, 131071, 524287 };


Старый способ инициализации Map:

final Map<Integer, String> platonicSolids;
static { 
    solids = new LinkedHashMap;
    solids.put(4, "tetrahedron"); 
    solids.put(6, "cube"); 
    solids.put(8, "octahedron"); 
    solids.put(12, "dodecahedron"); 
    solids.put(20, "icosahedron"); 
    platonicSolids = Collections.immutableMap(solids); 
}

Новый способ инициализации Map:

final Map<Integer, String> platonicSolids = { 4 : "tetrahedron", 6 : "cube", 8 : "octahedron", 12 : "dodecahedron", 20 : "icosahedron" };


Обратите внимание, что созданные таким образом коллекции будут immutable.

Поддержка JSR 292 (динамическая типизация на уровне языка)

Для поддержки динамической типизации вводится новый тип java.dyn.Dynamic. Пример использования:

Dynamic x = (any type of expression can go here); 
Object y = x.foo("ABC").bar(42).baz();

Этот код всегда будет компилироваться, но выдаcт run-time exception, если указанные методы будут отсутствовать в переменной типа Dynamic.

Отвергнутые предложения

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

Ну и что вы об этом думаете?

Update: Прошу прощения за косяки в изначальной версии. Предпросмотр почему-то опубликовал топик. Да ещё и Хабр-тэги об generics спотыкались.
Update 2: antalus справедливо заметил, что это далеко не все нововведения в Java 7, а лишь относящиеся к языку. Полный список тут.
+57
16 сентября 2009, 11:20
13

комментарии (72)

+3
sse #
Форматировать не пробовали? Говорят, помогает )
+1
nooze #
Ну как же, смотрите сколько разного форматирования — и полужирный и начертания разные
+1
Lite #
Да у самого волосы дыбом встали. :) Только что пришло в голову, что виноват может быть какой-то из навешанных Greasemonkey-скриптов…
0
Lite #
И на будущее буду учитывать, что тэг - то ещё поделие. Уж лучше
.
+4
wdk #
Что-то пошло не так у вас.
+4
crazyprog #
Аццкийадд!
+2
hannimed #
Для полноты картины не хватает LowerCase и убрать все знаки препинания :)
–1
wdk #
Охуенный топик!
0
wdk #
Автор выкладывает непонятно что -> получает комментарии -> меняет топик -> авторы старых комментариев получают минусы. Превосходно.
0
Lite #
wdk прав, не минусуйте его. Хотя можно бы и без мата. ;)
+9
pieceofsummer #
Так и вижу: using, collection initializers…
К восьмой версии будут extension methods и свой linq с преферансом и блудницами?
–4
apple_fan #
Нет замыканий? Отстой…
+3
sse #
Пишите на Scala — там и замыкания, и управляемая вариантность, и синтакс-билдеры есть :)
+1
akuznetsov #
А так же можно писать jruby, jython, goorvy.
0
xflower #
Это распространённый совет.
Однако:
— для scala нет качественного ide с вышеупомянутыми пасьянсом и проститутками
— у меня есть проект на несколько сотен тыщ мильонов строчек с постоянными конструкциями типа

new IConditionCheck(){
     public boolean check(Object o){
       return o == objectIAmLookingFor;
     }
}

оно, конечно, работает. И даже понятно о чём речь. Но глаз всё же цепляется.
Переписывать все сотнитыщмильонов строк на scala — не хватит ни бюджета ни (surprise!) scala-разработчиков.
0
sse #
— Для scala есть плагины к Eclipse и Netbeans. Я пользовался вторым. Чего там нет, так это рефакторинга, но для функциональных языков более-менее сложный рефакторинг — это из разряда rocket science.
— А если бы появились замыкания, как бы вы сконвертировали существующий код? Предвижу ответ — вы бы не стали переписывать существующий код. Так чтобы использовать Scala, тоже не надо переписывать существующий код. Она (scala) нормально взаимодействует с java-программой.
0
isapioff #
вообще-то, есть анонимные классы. оно очень похоже на замыкания
+9
Lite #
Навеяло в тему:

Как-то однажды знаменитый учитель Кх Ан вышел на прогулку со учеником Антоном. Надеясь разговорить учителя, Антон спросил: «Учитель, слыхал я, что объекты — очень хорошая штука — правда ли это?» Кх Ан посмотрел на ученика с жалостью в глазах и ответил: «Глупый ученик! Объекты — всего лишь замыкания для бедных.»

Пристыженный Антон простился с учителем и вернулся в свою комнату, горя желанием как можно скорее изучить замыкания. Он внимательно прочитал все статьи из серии «Lambda: The Ultimate», и родственные им статьи, и написал небольшой интерпретатор Scheme с объектно-ориентированной системой, основанной на замыканиях. Он многому научился, и с нетерпением ждал случая сообщить учителю о своих успехах.

Во время следующей прогулки с Кх Аном, Антон, пытаясь произвести хорошее впечатление, сказал: «Учитель, я прилежно изучил этот вопрос, и понимаю теперь, что объекты — воистину замыкания для бедных.» Кх Ан в ответ ударил Антона палкой и воскликнул: «Когда же ты чему-то научишься? Замыкания — это объекты для бедных!» В эту секунду Антон обрел просветление.
0
nimeku #
а в Java были какие-то другие варианты замыканий? просто интересно
0
isapioff #
да вроде больше не знаю
0
vinni #
Спасибо.
0
Timmmm #
Совсем другое дело )
+19
Skiminok #
Круговорот фич в природе какой-то.
Карл у Клары украл dynamic, а Клара у Карла украла байткод.
+3
Lite #
Тут спросили про null-безопасные операторы. Предлагались три оператора:
"?:", "?.", "?[]"

Примеры:
String s = a ?: "value if a is null";
String s = a?.b?.c; // s is assigned with null if a or b is null
String s = a?[i]; // s is assigned with null if a is null


Неплохая была идея, кстати. Сужу по опыту работы с Groovy.
0
Scala #
В Groovy — действительно удобно. Java это не надо, для этого следует использовтаь @Nullable, @NonNull.

То же самое и по поводу замыканий — Scala язык функциональный, там они к месту. В Java можно обойтись упрощением синтаксиса для уже существующих анонимных классов — docs.google.com/Doc.aspx?id=k73_1ggr36h

Я рад ништякам — очень консервативно и по делу. Улучшенную обработку исключений и CICE всё же хотелось бы рано или поздно увидеть в языке.
+1
xflower #
Как @Nullable заменяет "?:"?
0
Jamon #
да, жаль. Но на sun tech days вроде бы говорили об операторе @, возвращающий левый операнд, если он не равен null, и правый в противном случае.
+1
nimeku #
интересно было бы почитать статью об операторе @, как и где его применять.
0
ice9 #
Это как раз и есть Элвис, т.е. оператор "?:".
+1
butaji #
Инициализация коллекций классная!
+1
miptalan #
синтаксис короче, но unmodifiable — это будет неудобно…
0
Scala #
Никто не мешает сделать их изменяемыми.
–2
mace #
Ну вот, теперь джава догоняет C#. Только лениво как-то.
+3
antalus #
Вопрос в том, нужно ли в Java все то что уже есть в С#
0
swk #
джваве-то все-равно, а вот джава-программистам очень бы хотелось )
+3
teran #
Не говори, плиз, за всех. Очень многие фишки в C# крайне вредны при коллективной разработке
0
Lite #
Например?
0
shai_xylyd #
Ленивость LINQ'а. Так как ленивость в языке с возможностью побочных эффектов может порождать неуловимые баги.
0
teran #
Например введение var. Это сильно ухудшает читабельность кода.
0
dmodeus #
Не стоит просто злоупотреблять с var. Для runtime типов самое оно.
0
sse #
Вы имеете в виду — анонимных? var никоим образом не связано с run-time
0
dmodeus #
Видимо я анонимные и имел ввиду: я про тот случай, когда linq запрос возвращает данные с определенными в select именами. Если посмотреть на тип переменной во время отладки, то пишет Runtime тип, если, конечно, меня не переглючило.
0
ashmind #
Наоборот.
MyClass<OtherClass, AnotherClass> my = new MyClass<OtherClass, AnotherClass>()
читается гораздо хуже чем
var my = new MyClass<OtherClass, AnotherClass>()

Мне кажется, не обязательно читать одно и то же два раза, чтобы понять смысл.
0
Lite #
Если использовать вразумительные имена переменных, то как раз лучше упрощать левую часть. А в этом помогает var.
0
miptalan #
type inference в generics — это прекрасно, сколько конструкций на пару строк написано типа Map<long.key.name,List<Set<long.other.type.name>>> list = new HashMap<и тут по-новой>
0
Scala #
Да, хоть IDE и научились это дополнять и скрывать, всё равно это очевидный визуальный мусор.
+1
pieceofsummer #
Уж не знаю, по мне, так var в c# явно нагляднее. Логичнее видеть, что именно мы создаем, а не чему потом это присваиваем.
0
teran #
Лично я с детства привык читать слева направо и мне хотелось бы видеть тип переменной сразу, так что все ок.
0
xflower #
Map<Key, Value> map = Factory.createHashMap();
0
leave #
Строки в switch! Ура!
+1
Lite #
Ещё есть куда расти. Пример switch из Groovy:
switch (10) {
  case 0 : assert false ; break
  case 0..9 : assert false ; break
  case [8,9,11] : assert false ; break
  case Float : assert false ; break
  case {it%3 == 0}: assert false ; break
  case ~/../ : assert true ; break
  default : assert false ; break
}

Последний case — это совпадение с регулярным выражением.
0
eschava #
да, этот пример действительно показывает, насколько case наглядней if-else
0
krolser #
Нагляднее то нагляднее. А вы в курсе, во что разворачивает компилятор case?
+3
shai_xylyd #
Прогресс на лицо, чувствую лет через пять можно будет переключаться с Nemerle на любой mainstream язык без такого уныния, которое испытываю сейчас=)
0
Scala #
А Nemerle разве ещё развивается?
+2
shai_xylyd #
Да, он развивается.
Недавно была добавлена поддержка LINQ, скоро будет релиз версии 1.0 :) У языка есть хороший плагин для поддержки в студии, а так же своя бесплатная IDE на основе visual studio shell. На днях проект стал еще более открытым — репозиторий переехал на google code.

Хотя с другой стороны, создатели языка постарались: у них получился очень сбалансированный и мощный язык, который не утратил актуальности до сих пор. Mainstream языки, какие как Java и C# (в меньшей степени), с каждой новой версией стремятся к возможностям, которые предоставляет Nemerle, но, в отличии от них, он изначально был спроектирован под эти возможности и поэтому выглядит более элегантно.
+1
lig #
Мне кажется или многое из сего навеяно языком Python?
+3
trg #
Скорее C#.
0
Throwable #
Насколько я понимаю, сохраняется полная бинарная совместимость с Java 6.0? А ништяки зачетные.
+2
ShapovalovTS #
Дааа, проектировщикам Java7 еще далеко до проектировщиков нового стандарта С++, последние видать не любят делиться веществами…
0
Fortop #
Мгм, а вопрос профана в Java. Для чего ввели dynamic конструкции?
+1
Lite #
На уровне языка — непонятно. На уровне JVM — очень полезно для других языков: Groovy, JRuby, JPython…
0
Scala #
0
Fortop #
Короче, как я понял, основное достоинство — это легкость создания новых языков на JVM. Верно?
0
sse #
Новых динамических языков на JVM
+1
antalus #
В данной статье описан финальный список изменений в т.н. Project Coin, который идет с меткой «Small language enhancements».

В JDK7 помимо изменений в lang вносятся также изменения в части vm, core, client, web. Интересующимся читать на английском тут
0
Scala #
Больше всего интересно, чем закончатся споры о Jigsaw & JSR-294.
+1
intenter #
Нормальный эволюционный релиз. Как тут сказали выше, консервативный. Даже Dynamic добавили как тип, а не как ключевое слово.
0
AdOLF_04 #
Жалко, что не будет поддержки BigDecimal на уровне языка.
0
Kodeks #
два плюса тебе, хороший человек!
0
nile1 #
На мой взгляд, могли бы добавить и синтаксические вкусности вроде свойств, инициализаторов, анонимных функций и т.п. как в C#. JVM переделывать не надо, а удобочитаемость улучшается в разы (хотя, конечно, все хорошо в меру).
–1
mezastel #
Прочитав все это, очень рад что пишу на C#, ибо большинство изложенного у нас уже есть, причем даже покрасивее чем в Java.

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