Анонсированы новые функции Java 9

    Компания Oracle серьёзно взялась за разработку JDK9 и опубликовала первый список «предложений на улучшение» (JEP), в которых описаны новые функции Java 9. Список невелик и консервативен, но его наверняка дополнят в предстоящие почти два года до выпуска Java 9.

    Программные интерфейсы


    Представлены три новых программных интерфейса.

    • Обновление Process API для лучшего взаимодействия с не-Java процессами операционной системы (сейчас разработчики часто вынуждены использовать нативный код).
    • Новый HTTP-клиент с поддержкой HTTP 2.0, веб-сокетов и заменой устаревшему HttpURLConnection.
    • Облегчённый JSON API для обработки и генерации JSON-документов и потоков данных.


    Производительность/JVM


    Здесь тоже предложено три улучшения (для начала).

    • Улучшенное разрешение конфликтов при захвате блокировки (contended locking) при многопоточной работе и совместном доступе нескольких потоков к объектам. Тут речь идёт об общем улучшении производительности за счёт ускорения операций мониторов, таких как notify/notifyAll и PlatformEvent::unpark().
    • Умный Java-компилятор (sjavac) будет улучшен до такой степени, чтобы его использовать по умолчанию в билдах JDK и на постоянной основе для сборки других больших проектов. Сейчас он пока не годится для этих целей по разным причинам, в том числе из-за нестабильной работы. Код компилятора кардинально переработают и протестируют. Возможно, его даже выпустят как отдельное независимое приложение без привязки к JDK. Планируется реализовать в нём и новые функции, в том числе параллельную и shared-компиляцию.
    • Сегментирование кеша кода. Эта область используется JVM, когда включена JIT-компиляция, в ней кешируется скомпилированный платформенно-зависимый код. После модернизации кеш разделят на несколько частей, каждая из которых будет содержать скомпилированный код определённого типа: non-method (внутренний код JVM), profiled и non-profiled. Это увеличит производительность и позволит легче внедрять будущие расширения.


    One More Thing...


    Ещё одним нововведением в Java 9 станет стандартная модульная структура исходного кода JDK.

     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
                            native/include/*.{h,hpp}
                                   $LIBRARY/*.{c,cpp}
                            conf/*

    Изменение никак не повлияет на бинарники, но зато сильно улучшит работу с исходниками: легче станет портировать Java на мобильные устройства, «отсекая» ненужные модули, проще станет изучать структуру кода и искать баги/уязвимости и т.д. В конечном итоге, это приведёт и к улучшению производительности приложений, и к упрощению создания и поддержки библиотек и больших проектов на платформах Java SE и EE.

    Рефакторинг кода станет продолжением старого проекта Jigsaw.



    Раньше анонсировалось несколько десятков мелких улучшений в Java 9, но эти, о которых объявлено сейчас, — наиболее значительные.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 39

      +7
      Новые API годные (особенно встроенный JSON), но в целом релиз, судя по всему, будет довольно унылым. Одну из самых ожидаемых фич — Jigsaw — в девятку не только не включили, но и вообще, собственно модульность для конечных пользователей JDK отложена на неопределённый срок. Печально :(
        +1
        Почему печально? Вы действительно чувствуете острую необходимость в ней?
          +1
          Там, где я сейчас работаю — уже нет, в связи со спецификой архитектуры и технологий. А вот там, где я был раньше, модульности очень сильно не хватало. Понятно, что одним лишь изменением в языке всё не исчерпывается, здесь нужна инфраструктура — библиотеки, сервера приложений и т. д., но даже изменение в языке было бы очень приятным.
            0
            Какая специфика «того» места требовала модульности?
        +5
        А где же Value Types, Continuations, отказ от Erasure, поддержка примитивных типов в дженериках, легковесные потоки? Печально… Кажется что-то не так в консерватории…
          +3
          Value Types — в данный момент идет обсуждение
          openjdk.java.net/jeps/169

          отказ от Erasure — и отвалится scala, только за счет Erasure она и работает на jvm, но толком не работала на .net, не сталкивался когда он так уж сильно мешал, если чего и хотелось бы, так это Value Types для большей локальности данных.

          поддержка примитивных типов в дженериках — в контексте Value Types возможно частично будет сделано, так как обсуждение идет, отдельно еще тестируют в www.infoq.com/news/2014/07/Project-Valhalla

          Continuations/легковесные потоки — для первого придется заниматься перебрасыванием стека (что сразу усложняет ещё и jit), для второго тянуть еще и свой шедулер в jvm

          Почему по первым JEP которые войдут в 9ку делается вывод о том, что там будет, а чего не будет?
          Никто же не пытается по первым строкам кода говорить «какой говняный релиз вы делаете, ни нормальной админки, ни ui, а уж производительность вообще печальна»
            +1
            да, чуть не забыл, еще не анонсированны какие-либо наработки из graal, из наиболее интересных это работа с gpu (генерация как opencl кода, так и ptx, ну и единый jit для пачки архитектур, причем написанный на java) и Truffle

            wiki.openjdk.java.net/display/Graal/Main
            www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf
            aosd.net/2014/sites/default/files/2014-04-24Graal_Modularity.pdf
              +5
              > отказ от Erasure — и отвалится scala, только за счет Erasure она и работает на jvm, но толком не работала на .net, не сталкивался когда он так уж сильно мешал, если чего и хотелось бы, так это Value Types для большей локальности данных.

              Что за бред? Они (Scala) сами постоянно жалуются на то, что из-за грёбаного Erasure они не могут делать pattern-matching на обобщённых типах данных. Для обхода Erasure в Scala пришлось «изобретать» Manifest[T] и т.п.: docs.scala-lang.org/overviews/reflection/typetags-manifests.html
                0
                www.scala-lang.org/old/node/10299

                The key limitation for the moment is that Scala programs cannot use libraries in .Net that are compiled using CLR generics, such as the .Net collections. However, for this particular example that's a minor limitation as the much better Scala collections library would be the natural developer choice anyway. Just to be clear: it's only CLR generics that are not implemented in the Scala.Net compiler, all the Scala features (including Scala generics) are available to the programmer. The .Net generics will be supported in the fall.

                stackoverflow.com/questions/11607170/reified-generics-in-scala-on-net-clr

                The net-net is that if the JVM had reified generics (no type erasure), it would not be possible to implement Scala's type system… Scala's type system is more complex than Java's and if the JVM had generics based on Java generics, we'd still have problems in Scala. On the other hand, type erasure allows the compiler to implement a complex type system, even if all the type information is not available at runtime. (David Pollak, ему то хоть немного можно верить)

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

                По поводу Manifest я знаю.
                  0
                  1) Поддержку .NET платформы выпилили в Scala 2.11: docs.scala-lang.org/scala/2.11/
                  2) Накладные расходы возникают как раз тогда, когда пытаясь заткнуть «баг» языка, начинают придумывать всякие Manifest[T] в коде прикладного уровня… А вот, например, на этапе выполнения JIT, зная тип, которым нужно параметризовать generic, может скомпилировать нужную версию generic'а и никаких проблем с производительностью не будет. Это как один из вариантов, можно и другие предложить.
                    0
                    1) правильно, помучались немного и решили, что овчинка не стоит выделки.
                    2) вот это в данный момент и обсуждается, причем нужно сделать так, чтобы не поломать совместимость со всем существующим кодом (это вам не c# где можно все взять и поломать, пользователи спокойно проглотят, для stream api в 8ке даже придумали default methods).

                    Из последнего:
                    cr.openjdk.java.net/~jrose/pres/201407-JVMEvolution.pdf

                    там половина ответов на ваши вопросы.

                    хочется быстрее? так никто не мешает принять участие в дискуссии КАК это должно быть сделано или помочь РЕАЛИЗОВАТЬ.

                    p.s. может я и ошибаюсь, но считаю что любой кто следит за разработкой именно платформы, видит куда все движется и что движение последнее время активизировалось. indy из 7й jvm более ограничен чем он же в 8й, так как в 7й его активно уже начал использовать ruby и дал хороший feedback, что нужно чтобы работало быстро. Похожий подход пытается применяться везде, так как после того как уйдет в люди, что-то менять будет уже очень сложно, а местами и невозможно.
                0
                [промахнулся]
                0
                Сдаётся мне, что Value Types и отказ от Erasure не могут быть сделаны без поломки обратной совместимости. Плюс будут ли существующие классы JDK поддерживать нововведения? Помнится, во времена второго дотнета возник целый неймспейс — System.Collections.Generic, и так до сих пор в .NET два неймспейса с коллекциями. А в Java намеренно сделали дженерики просто в виде опциональной метаинформации для компилятора и удалось их запихнуть в существующие классы.

                А зачем встраивать continuations в JDK? Это реализуемо на уровне библиотек. Лично мне известен apache javaflow, может ещё какие реализации есть.
                  0
                  Если на пальцах. Вот выполняется функция, у неё есть локальный стек, вы делаете yield, куда и как сохранить стек, причём так, чтобы без фатального ущерба для производительности? Библиотекой такую задачу не решить без поддержки на уровне виртуальной машины… Никак…
                    0
                    Я думаю, что сохранить стек даже с поддержкой виртуальной машины быстро не получится. Наверное, нужно просто не так часто заниматься этой операцией. Вон, даже на уровне процессора переключение контекста не очень быстро выходит, поэтому шедулер ОС на самом деле переключается между параллельными задачами сравнительно редко по меркам процессора. javaflow для сохранения стека после каждого INVOKE* вставляет байт-код, сохраняющий стек и локальные переменные. Работает это достаточно быстро, чтобы быть приемлемым в реальных задачах, единственная проблема — серьёзное разбухание байткода. Но на самом деле, если не вставлять эти continuations вообще везде, будет не так уж и страшно. А если они нужны вообще везде… а вы уверены, что на Java напишете лучший шедулер для fibers, чем есть в ОС для потоков?
                  +1
                  +5
                  Пишу на C# и Java.
                  Очень не хватает в Java свойств (property) как в C#. Со свойствами читабельность и компактность кода сильно повышаются.

                  Сравните:
                  C#:
                  User.Profile.Money += 10;
                  Java:
                  user.getProfile().setMoney(user.getProfile().getMoney() + 10);
                    +1
                    Переходите на Groovy, хе-хе.
                      +1
                      Посмотрите на Scala — это язык способен помочь вам не писать много кода, он типизированнный и вы сможете использовать Java библиотеки.
                        0
                        Также можно обратить внимание и на Kotlin.
                          +4
                          О, да, согласен с вами…
                          У нас разрастается до: user.getProfile().setMoney(user.getProfile().getMoney().add(new BigDecimal(«10.0»)));

                          Бяка по сравнению с шарпом…
                            –6
                            Ничего так у вас юзеры, если у них Money в BigDecimal'ах измеряются. Или это вам точности не хватает?
                              0
                              А в чем бы вы измеряли Money?
                                0
                                В условиях моновалюты должно за глаза хватать дробного числа с фиксированной точностью (скажем, int64, у которого из 18 доступных значащих десятичных цифр две отведены под дробную часть). Нет?
                                  –1
                                  нет. строго целые числа.
                                    0
                                    И почему же тогда BigDecimal вместо long или BigInteger (если у юзеров ну очень много денег)?
                                      0
                                      Разве это не то же самое?
                                  0
                                  Я работаю в банке.
                                  Думаю вопросы о точности валютных операций отпадают сами собой ?:)
                                    +1
                                    Да даже если бы вы работали в заборокрасительной конторе вы были бы абсолютно правы. Лперации с деньгами — всегда на числах с неограниченной точностью должны выполняться.
                                  0
                                  Тут проблема не столько в том, что Decimal, а что валюты нет. Денег не бывает абстрактных.
                                  У Money должен быть конструктор, который не работает без валюты.
                                    0
                                    Тут не в яве дело…
                                    https://ru.wikipedia.org/wiki/Закон_Деметры
                                    +1
                                    Свойства, скорее всего, не подружатся с соглашениями по оформлению кода Java: имена свойств будут конфликтовать с именами полей. В .NET методы и свойства именуются с заглавной буквы, поэтому имена поля и свойства будут всегда отличаться. И да, в своё время, когда я переходил с .NET на Java, я тоже сильно боялся того, что придётся от свойств отказаться, а сейчас ничего, привык.
                                      +2
                                      Ну такое по-факту в одном месте кода надо написать (геттеры и прочее опущены).

                                      IAccountOperations {
                                          void processTransaction(Transaction t);
                                      }
                                      
                                      Transaction {
                                           Type type;
                                      }
                                      DepositTransaction: Transaction (type=Deposit) {
                                          UserId userId;
                                          BigDecimal depositAmount;
                                          String description;
                                      }
                                      
                                      

                                      Ну и потом уже в реализации
                                      
                                      ....
                                      processDeposit(DepositTransaction t) {
                                          ctx.beginTransaction();
                                          User u = dao.lockUser(t.userId);
                                          BigDecimal newBalance = u.profile().getBalance().add(t.depositAmount);
                                          u.profile().setBalance(newBalance);
                                          dao.saveTransaction(t);
                                          dao.saveUser(u);
                                          ctx.commitTransaction();
                                          
                                      }
                                      


                                      И вообще, странно искать откровений в синтаксисе языка программирования :)
                                        0
                                        Используйте Jruby :)

                                        user.profile.money += 10.rubles
                                          0
                                          :-D

                                          Люто не люблю скриптовые языки. И пусть меня за это закидают тапками — не люблю.
                                          Отладка любого legacy в них представляет собой АД.
                                          Особенно учитывая всякие mixin'ы.

                                          И за возможность статического анализа кода средствами IDE очень люблю языки со строгой статической типизацией а-ля Java. И еще лучше — с автоматическим выводом типов. :-)
                                        –2
                                        Хотелось бы ключевое слово var, как в C# и других JVM-based языках.
                                          +1
                                          Для локальных переменных — соглашусь.
                                          Для параметров и возвращаемого значения методов — категорически против.
                                            0
                                            И вообще — чем больше можно ограничить контекст для чтения кода — тем лучше.
                                            Подчеркиваю — тут идет разговор о возможности.
                                            Должна быть возможность ограничений типов. Так же как и возможность их ограничивать менее строго (через generic'и, например). Одно дело, когда есть инструмент для гибкости а-ля mixin'ы, а другое дело — когда они навязываются, и никак не могут быть устранены.

                                            Я за гибкость, но против навязываний.
                                          0
                                          WebGL опять нет?????????????

                                          Only users with full accounts can post comments. Log in, please.