Java SE 8

ага, все джависты от optional в таком восторге, как будто это какое-то откровение. псевдомонады в джаве, все в машину!

у них там всегда жестко с версией жабы)

Я уже почитал историю.
«ответственный за JSR47 товарищ Graham Hamilton решил взять за основу не log4j, а оригинальный IBM logging toolkit»
Буду теперь знать как звали того наркомана.

Ура! Отличная новость!

Java Logging: история кошмара: http://habrahabr.ru/post/113145/

Это под венду

А Oracle в курсе?

JavaFX Downloads:

As of JDK 7u6 JavaFX is included with the standard JDK and JRE bundles. Please download the JDK or JRE to use JavaFX.

JDK 7 Downloads:

JavaFX SDK is now included in JDK 7 for Windows, Mac OS X, and Linux x86/x64.

JDK 7u6 Release Notes:

JavaFX SDK and JavaFX Runtime included in JDK 7u6 and JRE 7u6

Starting from 7u6, JavaFX SDK and JavaFX Runtime are included in JDK 7u6 and JRE 7u6 respectively. JavaFX is installed as part of the JDK or JRE installation with no extra steps if you are installing on Windows, Mac, and Linux platforms.

$ tar -xf jdk-7u6-linux-x64.tar.gz 
$ find jdk1.7.0_06/ -iname '*fx*'
jdk1.7.0_06/man/ja_JP.UTF-8/man1/javafxpackager.1
jdk1.7.0_06/man/man1/javafxpackager.1
jdk1.7.0_06/jre/lib/jfxrt.jar
jdk1.7.0_06/jre/lib/amd64/libjfxmedia.so
jdk1.7.0_06/jre/lib/amd64/fxavcodecplugin-53.so
jdk1.7.0_06/jre/lib/amd64/fxavcodecplugin-52.so
jdk1.7.0_06/jre/lib/amd64/fxplugins.so
jdk1.7.0_06/jre/lib/amd64/libjavafx-iio.so
jdk1.7.0_06/jre/lib/amd64/libjavafx-font.so
jdk1.7.0_06/jre/lib/amd64/libjfxwebkit.so
jdk1.7.0_06/jre/lib/javafx.properties
jdk1.7.0_06/jre/THIRDPARTYLICENSEREADME-JAVAFX.txt
jdk1.7.0_06/bin/javafxpackager
jdk1.7.0_06/lib/javafx-doclet.jar
jdk1.7.0_06/lib/ant-javafx.jar
jdk1.7.0_06/lib/javafx-mx.jar
jdk1.7.0_06/THIRDPARTYLICENSEREADME-JAVAFX.txt

а из анонимного класса-то нельзя локальные переменные захватить?

Да вообще-то, на сколько помню, анонимные классы не бывают статическими (если только не объявлены в статическом контексте). А переменные из нестатического контекста нельзя использовать в статическом. Иначе в многопоточной программе можно устроить израиль и ад. Смутоно как то это на задворках памяти. Но точно это на пользу кодеру сделано. С нестатическими переменными должны работать методы несущего класса.

Наконец то штатные утилиты для Base64

Они всегда в Java были.

появление беззнаковой арифметики

а можно подробней?

Нашёл. Да фигня какая то, пара статик методов. Такие можно было и самому написать.

Они всегда в Java были.

Где? (Чур пакет sun.misc не считать)

Спасибо кэп.

javax.xml.bind.DatatypeConverter

может не всегда, но давно. То, что местоположение не совсем логичное, согласен, но в целом проблем это не вызывает, апи понятное и рабочее.

А да, забыл про него, конечно формально я был не прав и средство работы с base64 было, только для base64 там всего 2 метода (byte[]->String, String->byte[]), и нет возможности работать с потоками.

Хорошо, наконец то появилось нормальное штатное средство для работы с Base64

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

Жрать-то хоть меньше стал?

еще больше

Т.н. «лямбды», которые обещали несколько лет, но так и не осилили — всего лишь обертки вокруг анонимных классов, синтаксический сахарок.

Это не синтаксический сахарок.

Ну а замыканий нет и не будет, например.

Замыкания есть. С read-only переменными.

Ну а кто на лямбды повелся, сидит и кушает local variables referenced from a lambda expression must be ‘effectively final’, ха-ха.

Хорошее улучшение. Раньше нужно было писать final.

Ну jfxrt с восьмёрки не надо отдельно в classpath прописывать

Вы наверное не в теме, раз так рассуждаете. Речь не об этом. А о нормальной поддержки API логирования на уровне Java. То что есть сейчас назвать жалким подобием, язык не поворачивается. А библиотеки есть, не спорю. На любой вкус и цвет.

Какая разница, где этот байткод - в rt.jar или в slf4j.jar? Это стандарт-де факто практически во всех проектах.

Никогда не страдал подобное фигней. Не считаю это чем-то важным.

Это очень важно.

То есть без модульности никак? Скажу более это то, без чего можно обойтись.

Модульность для ряда проектов это тоже очень важно. Например для десктопных приложений, которые хочется распространять с JRE.

Какая разница, где этот байткод - в rt.jar или в slf4j.jar? Это стандарт-де факто практически во всех проектах.

Большая разница. Так как подключить любимую библиотеку проще будет, потому что она основана на совместимом API. А сейчас это совершенно разные интерфейсы, которые не совместимы между собой. Давно можно было бы это исправить.

Модульность для ряда проектов это тоже очень важно. Например для десктопных приложений, которые хочется распространять с JRE.

Хотеть и мочь совсем разные вещи. Вы можете распространять приложение и без модульности. Это удобство, чем необходимость.

jfxrt с восьмёрки не надо отдельно в classpath прописывать

Но всё-таки действия «сделать частью стандартной библиотеки» и «встроить в JDK» несколько отличаются по смыслу. Конечно, первое невозможно без второго, но положить библиотеку в изкоробку JDK/JRE можно и без впихивания её (библиотеки, не изкоробки :) ) в rt.jar.

Большая разница. Так как подключить любимую библиотеку проще будет, потому что она основана на совместимом API. А сейчас это совершенно разные интерфейсы, которые не совместимы между собой. Давно можно было бы это исправить.

Ничего не понял. В чём проблема сейчас подключить slf4j? Как её ещё проще будет подключить? Она подключается за 10 секунд.

Хотеть и мочь совсем разные вещи. Вы можете распространять приложение и без модульности. Это удобство, чем необходимость.

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

Ничего не понял. В чём проблема сейчас подключить slf4j? Как её ещё проще будет подключить? Она подключается за 10 секунд.

Твое счастье) Ликбезом заниматься не буду. Есть время и желание почитай на эту тему, много нового узнаешь. Даже возможно поймешь почему многие по прежнему предпочитают log4j.

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

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

Приведи конкретный пример с модульностью и без. Тогда можно будет о чем то поговорить. А так пока только слова.

Твое счастье) Ликбезом заниматься не буду.

Т.е. аргументов нет?

Есть время и желание почитай на эту тему, много нового узнаешь. Даже возможно поймешь почему многие по прежнему предпочитают log4j.

Я много читал в своей жизни. log4j хорошая библиотека, но она давно устарела. Её можно использовать, просто slf4j + logback лучше.

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

Какие библиотеки? Ты вообще понимаешь, что такое модульный JRE? Это значит, что я могу не брать с собой огромную часть стандартной библиотеки, которую моя программа не использует. Например AWT, Swing, JDBC, там CORBA где то ещё зарыта, всякие WEB SERVICES, это же мегабайты байткода, ненужного во многих программах. И в случае с ЖРЕ вычистить их сложно и юридически спорно.

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

JSR-305, можно сделать свой компилятор, можно юзать аспекты.

/prefiles.com/r1vmite1to4h/PB.Functional.Programming.in.Java.Feb.2014.pdf