Here I come, there I am.

Очакваните новости в Java 7

at 11:02 by nofearinc
Category: Java

Вчера в 2140 в ТУ се проведе интересен семинар към BGJUG Java потребителската група на тема "Новости в Java 7" с лектори Светлин Наков и Михаил Стойнов. Презентацията е достъпна тук и тук, а при попътен вятър скоро може да се появи и видео материал от събитието.

След няколко месеца се очаква да се радваме на новата Java 7. Едни от ключовите спорове последните месеци, ако не и година-две, е дали ще има промени в езика и отваряне на виртуалната машина към други езици. Засега прогнозите са именно в тази насока, макар и повечето информация да е само теоретична. Въпреки всичко на семинара вчера Наков и Мишо показаха някои работещи трикове от бетата, така че част от очакваните нововъведения вече се тестват и почти сигурно ще останат в пълната версия на JDK-то.

За момента още няма JSR за Java 7 (като Java 6 излезе под JSR 270), така че може да прилагаме колкото си искаме теория на вероятностите, докато не видим хартийката :) Работната версия на сегашното JDK е към гигабайт и половина и може да се дръпне от SVN-а: https://jdk7.dev.java.net/svn/jdk7/trunk . NetBeans има стабилна поддръжка на част от новите features, които могат да се пуснат с допълнителни инструкции при извикването на компилатора.

Сред очакваните нововъведения е оптимизация и компресиране на обектните указатели. Тъй като в Java указателите не зависят от типа обект и не могат да се итерират байт по байт или на парчета (както е в C++ например), всички указатели са по 4 байта за 32-битовите машини и по 8 за 64-вите. Новата виртуална машина обещава оптимизация на паметта и компресиране на 64-битовите указатели с цел бързодействие и пестене на heap-а.

Вече официално ще има поддръжка на новия garbage collector G1. Въпросният съществува от месеци с възможност за интеграция в Java 6, но не по подразбиране. G1 ще дели обектите на "млади" и "стари", като новото приоритизиране ще спестява чистенето на паметта. Друга стабилна оптимизация е дефрагментиране само на малка област (като 1 мегабайт) от паметта по време на чистене, което би спестило огромни замръзвания при повече отделена памет на виртуалната машина и пълен garbage collection.

Java 6 представи на света интересна интеграция с Javascript през Java Scripting API и извикване на код от единия език в другия. Това носи много предимства в уеб среда. По някое време се появи и Groovy - скриптов Java-подобен език за виртуалната машина. Откровено казано, до вчера смятах, че Groovy се компилира до байткод директно за JVM, но вчера чух коментар от Мишо Стойнов, че има междинен слой - тип втора виртуална машина - което ми се струва погрешно (ако съм го разбрал правилно). Както и да е, новостите на Java 7 предоставят много силен toolkit за изпълнение на различни скриптови езици - добавка на Jython, JRuby например - с нетипизирани данни и конверсия към Java типове runtime. Не мога да си представя как ще се пренапише отдолу, за да се прави конверсия, но демотата от презентацията бяха доста обещаващи (макар и отчасти псевдокод). Въпросните новости ще спомогнат за често срещани проблеми като налагането за анонимни класове в елементарни случаи или необходимостта (но невъзможността) за лесен interface injection.

Ако някой се е замислял за смисъла на rt.jar, то това са всички основни библиотеки, които се изискват при работа в Java. Пакетите от JDK-то с най-важната функционалност в себе си. Защо обаче са в един .jar е интересен въпрос. В презентацията има интересен пример по темата:

Suppose you are using the Logging API
Logging requires NIO (for file locking)
And JMX (as loggers are managed)
JMX requires JavaBeans, JNDI, RMI and CORBA (JMX remote API mandates that the RMI connector support both JRMP and IIOP)
JNDI requires java.applet.Applet (huh?) and JavaBeans has dependencies on AWT, Swing

Колкото и да е смешно, за да се зареди един прост логинг, депендънситата включват дълбочина чак до AWT/Swing и половината мрежови възможности на платформата. Основна цел на кодерите по новата Java е да се модуляризират пакетите и да се намали coupling-а заради някои безсмислици и частни случаи в практиката.

Горните, както и доста други промени, целят трите основни неща, които се цитират като недостиг на Java:

  • управление на паметта (тежки приложения)
  • slow execution
  • и многобройни редове код за тривиални задачи (или нарушение на DRY принципа, един вид)

Предвижда се малък тунинг в анотациите - добавяне преди полета, след дефиниция на методи и т.н. Според мен при възможностите на доста от фреймуърците, използващи анотации, може да се получи малко подобрение и да се замени доста от XML-а, използван наред.

Някои допълнителни фиксове, очаквани в езика:

  1. добавяне на String като аргумент на switch оператора (разгеле)
  2. автоматичен мениджмънт на ресурсите - премахване на досадните отваряния и затваряния на потоци и проверка на множество грешки, освен ако не се налага
  3. предефиниция на Closable и създаване на Disposable с generic exceptions
  4. даване на diamond метод за създаване на колекции и generics (примерно new ArrayList<>()), което ще си алокира типовете
  5. опростени varargs променливи (String... a)
  6. литерали в колекциите - много яко, най-накрая отпада концепцията за инстанциране на колекция и ръчно добавяне на обекти, като ще може да се прави елегантно: List<String> list = ["raz", "dva"];
  7. достъп по индекс на списъци и мапове (като масиви - return map[2]; например)
  8. създаване на специални променливи с литерали, различни от позволените в Java. С представка диез (#) могат да се създават променливи с интервали и специални символи - необходимост при работа със скриптови езици, които имат други имена за формиране на такива.
  9. подчертавки в големите номера - например променлива long l = 1_000_000, което всъщност е милион. Работи и в момента, а очевидно е по-четимо и спестява главоболия при четене и писане (атомната бомба е измислена заради изместване с една позиция на десетичната запетая) :)
  10. closures/lambda expressions в Java - все още на ниво псевдокод, но изглежда все пак има шанс да се стигне до такава промяна на езика, че да могат да се създават lambda функции и да се избегне много излишно писане на код. Това ще доведе до известно нарушаване на OOP концепциите (и доближаване до гъвкави езици като Ruby), но 'опасните' неща могат да се изключат в новото JDK от old school привържениците на езика.
  11. NIO2 API-то - внася някои подобрения и улеснения при работата с файлове, мощния клас FileSystem, както и възможност за копиране на файлове със запазване на атрибути като hidden или readonly. More to come, но дори това дотук радва.

Мишо и Наков показаха част от тези неща работещи в NetBeans 6.9 Beta (дори с интелигентни suggestions от IDE-то и насоки за новите възможности), а някои от тях все още не са довършени. Всеки с повече свободно време и желание може да си направи виртуална машина и да качи тестовото JDK, като пробва демотата от презентацията или онлайн.

Edit: Видео от семинара:

http://www.archive.org/details/Java_7_New_Features_2

http://www.archive.org/details/Java_7_New_Features_3

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • MySpace
  • Slashdot
  • Technorati
  • TwitThis
del.icio.us Digg DZone Facebook Google Google Reader Magnolia reddit SlashDot Technorati ReadMe.ru Dobavi.com Dao.bg Lubimi.com Ping.bg Pipe.bg Svejo.net Web-bg.com

Безподобния пост.

Related posts brought to you by Yet Another Related Posts Plugin.

Comments

11 Responses to “Очакваните новости в Java 7”

  1. Радослав Станков on May 21st, 2010 12:20 [#]

    За мен честно казано, като не java писач, ме интересуват главно промените във Витуалната машина който касаят другите езици в JVM-a. Много хора се надяват на една клауза call_dynamic или нещо такова, която колко пъти можела да ускори JRuby.

  2. nofearinc on May 21st, 2010 12:39 [#]

    Ами когато излезе, ще могат да се правят бенчмаркове. Със сигурност ще има неколкократно ускорение като работа вътре в самото VM, но ще видим опитно колко.

    Като цяло всички промени, описани горе, касаят или оптимизации по performance-а на виртуалната машина, или по-оптимизирано писане на код, което искрено ме радва. От Sun силно се дърпаха по промени по самия език, докато C# правят резки добавяния по синтаксиса редовно. Ако Java се направи ползваема и за по-малки/средни приложения, би било чудесно.

  3. Радослав Станков on May 21st, 2010 12:55 [#]

    100% JVM ще е по-бърз преди време гледах една презентация - http://www.infoq.com/presentations/enebo-jruby
    Която доста неща ми изясни за това как работи JVM и реално колко напред е като цяло.

  4. nofearinc on May 21st, 2010 13:14 [#]

    Просто милионите проверки, конверсии и пълната яснота, че трябва да е scalable, налагат множество забавяния в самата платформа. Вчера примерно се даде пример, че се обсъжда получаването на exception дали да проверява за nested exceptions и така - рекурсивно. Според мен това е много рядък case (да хвърлиш 3 изключения едно върху друго) и ще забави страшно много процеса с проверките (при вариант отделна нишка, която да следи и за това).

    Единичен пример, де - но аз съм силно "За" да се олекотят нещата. От Oracle пък смятат да направят джавата огромна, но под формата на модули - да има модули за често използваните неща (и снипети) и просто да се включват необходимите. Както е по фреймуърците например.

  5. mmateva on May 21st, 2010 15:30 [#]

    Много благодаря за този пост :)
    Само радостни новини дотук, изключително се радвам за интеграцията със скриптовите езици, както и за оптимизацията на референциите и новия GC. Ура :)

  6. nofearinc on May 21st, 2010 15:32 [#]

    Ако не съм развалил нещо, би трябвало да има и видео материал, който да се появи онлайн, след като се конвертира. Аз лично бих го гледал и повторно, семинарът беше много ползотворен :)

  7. ivan on May 30th, 2010 17:47 [#]

    Хубава статия.А какво стана с видеото?

  8. nofearinc on May 30th, 2010 19:43 [#]

    Обработва се от други хора и не зная кога ще е готово и качено някъде. Ще пусна линк, когато се появи.

  9. admin on June 7th, 2010 7:50 [#]

    Редактирах поста, вече има видео материали.

  10. ivan on June 18th, 2010 13:23 [#]

    Пуснах си видеата няколко пъти :)
    Но неразбрах ,дали след като променят Java SE т.е. модулизацията в смисъл до сега се пишеше примерно:
    javax.swing.event за прихващане на събитие та след промените пак ли ще си е така или ще се сменят имената на пакетите и класовете и примерно за да прихванем събитие ще трябва да извикаме примерно:
    javax.swingX.eventS

  11. nhasan on December 7th, 2011 11:23 [#]

    Здравейте може ли да обновите достъпа до презентацията и двата линка са неизползваемо в момента..... Благодаря!

Leave a Reply