Java 9 е тук: Всичко, което трябва да знаете

Java 9 - официално, Java Platform Standard Edition версия 9 - най-накрая е тук и неговият Java Development Kit (JDK) е достъпен за изтегляне от разработчиците.

Той има няколко важни, но противоречиви нови функции, но също така е последният от редицата за стария стил на доставка на Java.

Къде да изтеглите Java 9 JDK

Oracle публикува Java SE 9 JDK и документация за изтегляне от разработчиците.

Ключовите нови функции в Java 9

Дебютирайки почти три години след Java SE 8, Java SE 9 има няколко ключови архитектурни промени, както и множество подобрения.

Модулността на Java 9 променя играта

Новите, противоречиви възможности за модулност, базирани на Project Jigsaw, със сигурност ще предизвикат интереса на авангардни Java магазини, които искат да видят какво може да предложи JDK 9 сега, дори ако по-консервативните магазини решат да изчакат модулността да узрее.

Модулността - под формата на Java Platform Module System - разделя JDK на набор от модули за комбиниране по време на изпълнение, компилация или изграждане. Модулността е наречена „преходна“ промяна, позволяваща разбиране на зависимостите между модулите.

Модулността на Java 9 трябва да позволи на разработчиците по-лесно да събират и поддържат сложни приложения. Освен това трябва да направи Java по-способна да се мащабира до по-малки устройства, като същевременно се подобрят сигурността и производителността.

Аспектите на модулността на Java 9 включват пакетиране на приложения, модулиране на самия JDK и реорганизиране на изходния код в модули. Системата за изграждане е подобрена за компилиране на модули и налагане на границите на модулите по време на изграждане. JDK и Java Runtime Environment (JRE) изображения са преструктурирани, за да се справят с модули. Също така JavaFX потребителските интерфейси за управление и CSS API вече са достъпни за модулност.

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

С модулността разработчиците ще могат по-добре да конструират и поддържат библиотеки и големи приложения както за Java SE (Standard Edition), така и за Java EE (Enterprise Edition). Но по време на разработката на Java 9 Oracle, IBM, Red Hat и други имаха големи разногласия относно това как точно да се направи такава радикална промяна в платформата. Самата модулна система беше отхвърлена през май, за да бъде одобрена на второ гласуване през юни, след като беше постигнат напредък.

Дори при съгласие между основните доставчици на Java, остава противоречие относно това дали модулността ще направи много добре разработчиците на Java, като някои експерти казват „да“, а други казват „не“. Независимо от това, Java 9 вече е модулирана.

За да улесни миграцията към модулирана Java 9, Java 9 позволява нелегален отразяващ достъп за код по пътя на класа, използван от JRE за търсене на класове и файлове с ресурси. Тази възможност ще бъде забранена след Java 9.

Подобрения на компилатора за Java 9 код

Надстройката на Java 9 включва няколко нови възможности за компилиране на код, като основната сред тях е компилацията преди време (AoT). Все още в експериментална фаза, тази възможност позволява компилиране на класове Java в собствен код преди да бъде стартирана във виртуалната машина. Тази функция е предназначена да подобри времето за стартиране както на малки, така и на големи приложения, с ограничено въздействие върху пиковата производителност.

Точно навреме (JIT) компилаторите са бързи, но Java програмите са станали толкова големи, че отнема много време, докато JIT се загрее напълно, оставяйки някои Java методи некомпилирани и отслабвайки производителността. Предварителната компилация има за цел да отговори на тези проблеми.

Но Дмитрий Лесков, маркетингов директор на доставчика на технология Java Excelsior, се притеснява, че технологията за компилация преди време не е достатъчно зряла и желае Oracle да е изчакал Java 10 за по-солидна версия.

Java 9 също предлага фаза две от интелигентното внедряване на Oracle. Тази функция включва подобряване на s javac стабилността и преносимостта на  инструмента, така че по подразбиране може да се използва в JVM (Java Virtual Machine). Инструментът също ще бъде обобщен, за да може да се използва за големи проекти извън JDK. JDK 9 също актуализира  javac компилатора, за да може да компилира програми Java 9, които да се изпълняват на някои по-стари версии на Java.

Друга нова, но експериментална функция за компилация е интерфейсът на JVM Compiler на ниво Java (JVMCI). Този интерфейс позволява компилатор, написан на Java, да се използва като динамичен компилатор от JVM. API на JVMCI предоставя механизми за достъп до VM структури, инсталиране на компилиран код и включване в системата за компилация на JVM.

Писането на JVM компилатор в Java трябва да позволи висококачествен компилатор, който е по-лесен за поддръжка и подобряване от съществуващите компилатори, написани на C или C ++. В резултат на това компилаторите, написани в самата Java, трябва да бъдат по-лесни за поддръжка и подобряване. Други съществуващи усилия за активиране на компилаторите в Java включват Graal Project и Project Metropolis.

Нова възможност за контрол на компилатора е предназначена да осигури фино и зависим от контекста на метода контрол на JVM компилаторите, позволявайки на разработчиците да променят опциите за контрол на компилатора по време на изпълнение без влошаване на производителността. Инструментът също така дава възможност за заобикаляне на грешки в JVM компилатора.

REPL най-накрая стига до Java 9

Java 9 разполага с инструмент за четене-отпечатване на печат (REPL) - друга дългосрочна цел за Java, която става реална в тази версия, след години на разработка по проект Kulia.

Наречен jShell, REPL на Java 9 интерактивно оценява декларативни изявления и изрази. Разработчиците могат да получат обратна връзка за програмите преди компилацията, само като въведат някои редове код.

Възможностите на инструмента за команден ред включват попълване на раздели и автоматично добавяне на необходимите запетаи на терминала. JShell API позволява jShell функционалност в IDE и други инструменти, въпреки че самият инструмент не е IDE.

Липсата на REPL е посочена като причина училищата да се отдалечат от Java. (Езици като Python и Scala отдавна имат REPL.) Но основателят на езика Scala Мартин Одерски поставя под въпрос полезността на REPL в Java, казвайки, че Java е ориентирана към изявления, докато REPLs са ориентирани към изрази.

Подобрения на API за потоци в Java 9

Потоците в Java позволяват на разработчиците да изразяват изчисления, така че паралелизмът на данните да бъде ефективно използван. Възможността за поток в Java 8 е за декларативна обработка на данни, като същевременно се използват многоядрени архитектури.

В Java 9 Streams API добавя методи за условно вземане и пускане на елементи от Stream, итерация над Stream елементи и създаване на поток от стойност, която може да бъде обезсмислена, като същевременно разширява набора от Java SE API, които могат да служат като поточни източници.

Кеш кодът може да бъде разделен в Java 9

JDK 9 позволява кодовият кеш да бъде разделен на сегменти, за да се подобри производителността и да се позволят разширения като фино заключване. Резултатите трябва да се подобрят времената за почистване поради специализирани итератори, прескачащи неметодния код; разделяне на неметодов, профилиран и непрофилиран код; и подобряване на времето за изпълнение на някои критерии. 

По-добро архивиране на JavaScript в Java 9 чрез Project Nashorn

Project Nashorn, който осигурява леко изпълнение на JavaScript за Java, се подобрява в JDK 9. Project Nashorn е опит за внедряване на високоефективен, но лек JavaScript изпълнение в Java, следвайки проекта Rhino, който беше стартиран в Netscape. Проектът Nashorn беше натоварен с възможността за вграждане на JavaScript в Java приложения. Той предостави на Java двигател на JavaScript в JDK 8.

JDK 9 включва API за парсер за синтаксичното дърво ECMAScript на Nashorn. API позволява анализ на ECMAScript код от IDE и сървърни рамки, без да зависи от вътрешните класове за изпълнение на Project Nashorn.

HTTP / 2 клиентският API идва към Java 9

API за бета HTTP / 2 клиент стигна до JDK 9, внедрявайки в Java надстройката до основния HTTP протокол в мрежата. WebSocket се поддържа и от API.

API на HTTP / 2 може да замени API на HttpURLConnection, който е имал проблеми, включително да бъде проектиран с вече несъществуващи протоколи, да предсказва HTTP / 1, да е твърде абстрактен и да е труден за използване.

Подобрена поддръжка на HTML5 и Unicode в Java 9

В JDK 9 инструментът за документация Javadoc е подобрен, за да генерира HTML5 маркиране. Поддържа се и стандартът за кодиране Unicode 8.0 - който добавя 8 000 знака, 10 блока и шест скрипта.

DTLS API за защита е добавен към Java 9

За сигурност Java 9 добавя API за DTLS (Datagram Transport Layer Security). Протоколът е създаден, за да предотврати подслушване, подправяне и фалшифициране на съобщения в комуникация клиент / сървър. Осигурено е изпълнение както за клиентски, така и за сървърни режими.

Това, което Java 9 отменя и премахва

Java 9 отменя или премахва няколко функции, които вече не са на мода. Главен сред тях е API на Applet, който е остарял. Излезе от мода сега, когато производителите на браузъри, съобразени със сигурността, премахнаха поддръжката за приставки за браузър Java. Появата на HTML5 също спомогна за тяхната смърт. Разработчиците вече са насочени към алтернативи като Java Web Start, за стартиране на приложения от браузър или инсталируеми приложения. 

Инструментът за преглед на аплети също се оттегля.

Java 9 също отхвърля събирача на боклук Concurrent Mark Sweep (CMS), с поддръжка за спиране в бъдещо издание. Целта е да се ускори развитието на други събирачи на боклук във виртуалната машина HotSpot. Събирачът на боклук G1 с ниска пауза е предназначен да бъде дългосрочен заместител на CMS.

Междувременно комбинациите за събиране на боклук, остарели в JDK 8, се премахват в JDK 9. Те включват рядко използвани комбинации като Incremental CMS, ParNew + SerialOld и DefNew + CMS, които добавят допълнителна сложност към кодовата база на събирача на боклук.

Java 9 също така изтрива Java предупрежденията в операторите за импортиране, за да помогне да се изчистят големи кодови бази от предупреждения за мъх. С тези кодови бази, оттеглената функционалност често трябва да се поддържа за известно време, но импортирането на оттеглена конструкция не гарантира предупредително съобщение, ако употребите на конструкцията са умишлени и потиснати.

Също така в Java 9 е премахната възможността за избор на JRE по време на стартиране чрез функцията Multiple JRE (mJRE). Възможността се използва рядко, усложнява внедряването на Java стартера и никога не е напълно документирана, когато дебютира в JDK 5.

Oracle премахна агента hprof (Профилиране на купчина) на JVM TI (Tool Interface), който беше заменен в JVM. Инструментът jhat също беше премахнат, след като беше остарял от превъзходни визуализатори на купчина и анализатори.

Java 9 е краят на неговия ред, тъй като започва новият ред на Java 9

Може да се каже, че Java 9 излиза с гръм и трясък, с всички нови възможности. Oracle наскоро разкри, че Java 9 е последната по рода си по отношение на нейното предназначение и времето, изминало между основните издания.

Оттук нататък Java се планира да има шестмесечен ритъм на пускане, със следващата основна версия, която ще се нарича Java 18.3, март 2018 г., последвана от Java 18.9 шест месеца по-късно.

Новият каданс на Java също означава, че JDK 9 няма да бъде определен като дългосрочна версия за поддръжка. Вместо това следващото дългосрочно издание ще бъде Java 18.9.

По-бързият каданс на Java означава, че разработчиците няма да трябва да чакат толкова дълго за големи издания. Също така може да означава, че разработчиците ще пропуснат Java 9 и нейните „незрели“ модулни функции и ще чакат шест месеца за новата версия, която вероятно ще изглади kinks, каза Саймън Мейпъл, директор на застъпничеството за Java в доставчика на инструменти за инструменти ZeroTurnaround.