Временни издания на Java

1. Въведение

В тази статия ще обсъдим новите базирани на времето версии на Java и въздействието върху всички видове разработчици.

Промените в графика за пускане включват актуализиране на нивата на доставка на функции и поддръжка за версии на Java. Като цяло тези промени са значително различни от Java, която се поддържа от Oracle от 2010 г.

2. Защо шестмесечни издания?

За тези от нас, свикнали с историческия бавен каданс на Java, това е доста значително отклонение. Защо такава драматична промяна?

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

Просто казано, по-кратките периоди на издаване водят до по-малки, по-управляеми стъпки напред. А по-малките функции са по-лесни за възприемане.

Такъв модел се сдвоява добре в настоящите условия и позволява на разработката на JDK да работи по гъвкави методологии, подобни на общността, която поддържа. Също така, това прави Java по-конкурентоспособна с времена на изпълнение като NodeJS и Python.

Разбира се, по-бавното темпо също има своите предимства и така шестмесечният цикъл на пускане също играе роля в по-голяма рамка за дългосрочна поддръжка, която разглеждаме в раздел 4.

3. Промяна на номера на версията

Механичен аспект на тази промяна е нова схема с номер на версия.

3.1. JEP 223 Схема на версия-низ

Всички сме запознати със стария, кодифициран в JEP 223. Тази схема направи номерата на версиите нарастващи и предаде допълнителна информация.

 Actual Hypothetical Release Type long short ------------ ------------------------ Security 2013/06 1.7.0_25-b15 7u25 Minor 2013/09 1.7.0_40-b43 7u40 Security 2013/10 1.7.0_45-b18 7u45 Security 2014/01 1.7.0_51-b13 7u51 Minor 2014/05 1.7.0_60-b19 7u60

Ако изпълним java -version на JVM за версия 8 или по-стара, ще видим нещо като:

>java -version java version "1.6.0_27" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07) Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

В този случай може да предположим, че това е за Java 6, което е правилно, и 27-та актуализация, което е грешно. Схемата за номериране не е толкова интуитивна, колкото изглежда.

Малките издания бяха кратни на 10, а изданията за сигурност изпълниха всичко останало. Обикновено ще видим краткия низ, добавен към нашите локални инсталации, като JDK 1.8u174. Следващата версия може да бъде JDK 1.8u180, което би било незначителна версия с нови корекции.

3.2. Схема на нова версия-низ

Новата схема за низове на версията ще „ преработи номерата на версиите, за да кодира не съвместимост и значимост, а по-скоро изтичането на времето по отношение на циклите на освобождаване “, според Марк Рейнхолд в JEP.

Нека да разгледаме някои:

9.0.4 11.0.2 10.0.1

На един бърз поглед това изглежда като семантична версия; това обаче не е така.

При семантичното управление на версии типичната структура е $ MAJOR. $ MINOR. $ PATCH , но новата структура на версията на Java е:

$FEATURE.$INTERIM.$UPDATE.$PATCH

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

Първо, $ INTERIM е резервоар, запазен от Oracle за бъдещи нужди. За момента тя винаги ще бъде нула.

И второ, $ UPDATE се основава на времето като $ FEATURE, като се актуализира ежемесечно след последната версия на функцията.

И накрая, крайните нули се съкращават.

Това означава, че 11 е номерът на версията за Java 11, издаден през септември 2018 г., 11.0.1 е първата му месечна актуализация през октомври, а 11.0.1.3 ще бъде хипотетична трета версия на корекцията от октомврийската версия.

4. Разпределения на множество версии

След това нека разгледаме как да изберем правилната версия.

4.1. Стабилност

Просто казано, Java вече има бърз канал на всеки шест месеца и бавен на всеки три години. Всяко издание за третата година се нарича LTS.

По бързия канал езикът пуска функции в инкубация. Тези езикови функции се стабилизират в LTS версията.

Така че, за компании, които могат да приемат нестабилност в замяна на използването на нови функции, те могат да използват бързия канал. За предприятия, които оценяват стабилността и могат да изчакат да се надградят, те могат да надграждат при всяко LTS издание.

Експериментирането с версиите на JDK позволява на разработчиците да намерят най-подходящото.

4.2. поддържа

Има и, разбира се, въпросът за подкрепата. Сега, след като поддръжката на Java 8 залезе, какво да правим?

И както беше обсъдено по-рано, отговорът идва във версиите на LTS, като Java 11 е най-новата версия на LTS, а 17 е следващата . Актуализациите ще бъдат достъпни и поддържани от доставчици като Oracle и Azul.

Ако можем да се доверим на подкрепата на общността, тогава Redhat, IBM и други са заявили подкрепата си за прилагане на корекции на грешки за OpenJDK. Също така проектът AdoptOpenJDK предоставя предварително изградени двоични файлове за OpenJDK.

4.3. Лицензиране

Една област на объркване за някои е разликата между OpenJDK и Oracle JDK.

Всъщност те са почти идентични, като се различават само по това, че са били взети корекции на грешки и корекции за сигурност, според Брайън Гьотц.

OpenJDK acts as the source of most derived JDKs and remains free. Starting with Java 11, Oracle will charge commercial license fees for the Oracle JDK with additional support and services included.

4.4. Fragmentation

With more frequent releases, fragmentation may become an issue. Hypothetically, everyone could be running on different versions of Java with different features even more so than now.

Of course, containerization could help address this. From Docker and CoreOS to Red Hat's OpenShift, containerization provides the needed isolation and no longer forces one installation location for Java to be used across the server.

5. Conclusion

В заключение можем да очакваме много повече от екипа на Java в Oracle с редовно пускане на Java на всеки шест месеца. Като разработчик на Java, перспективата за нови езикови функции на всеки шест месеца е вълнуваща.

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