”Płatna Java” podana na zimno

Październik 11, 2018 Józef Tokarski

„Java teraz będzie płatna” – takie hasło krąży ostatnio po sieci. Należy uczciwie stwierdzić, że nie wzięło się znikąd. Warto jednak odczarować pewne mity, które wokół tego narosły, szczególnie jeśli twoja kariera lub biznes w jakiś sposób wiążą się z użytkowaniem platformy Java SE.

TL;DR:

Jeżeli jesteś deweloperem, który nigdy nie płacił za Javę i nadal chce z niej bezpłatnie korzystać:

Przede wszystkim miej świadomość, że Oracle JDK to troche co innego, niż OpenJDK.
Zwracaj uwagę skąd pobierasz binarną dystrybucję JDK. Dziś najlepszym wyborem dla Ciebie jest http://jdk.java.net/, za 3-6 miesięcy -będzie to https://adoptopenjdk.net/. Jeśli na co dzień pracujesz na Linuxie, dobrym wyborem będzie też korzystanie z OpenJDK, dostarczonego w pakiecie zarządzanym przez package-managera (apt, dnf, …) Twojej dystrybucji Linuxa.
Troszcz się w pierwszej kolejności o kompatybilność swojego kodu z tymi JDK.

Jeśli świadomie wybierasz jednak Oracle JDK i chcesz go używać tylko do dewelopowania i testowania swojego softu, to nowa licencja pozwala ci go nadal używać za darmo.

Jeżeli jesteś odpowiedzialny za biznes, używasz Javy na produkcji, nigdy za nią nie płaciłeś i chcesz by tak zostało:

Miej świadomość że od teraz, nie możesz już polegać na oficjalnych gwarancjach. Od teraz opierasz się na wsparciu wolnej społeczności projektu open-source. Przy czym rozwój wydarzeń w tej społeczności daje bardzo duże nadzieje, że to wsparcie będzie.

Używasz Javy 8 i nie masz szans na migrację wyżej:

Bezpłatne wsparcie Oracle dla JDK 8 kończy się w styczniu 2019. Jest natomiast bardzo duże prawdopodobieństwo, że OpenJDK będzie wspierane jeszcze przez długi czas, nie przez Oracle, ale inny podmiot który przejmie nad tym opiekę. Dlatego jeśli używasz Oracle JDK (i nie korzystasz z jego płatnych funkcjonalności), przejdź na OpenJDK (patrz instrukcja wyżej dla dewelopera)

Zamierzasz używać Javy 11 i wyższych wersji:

Oracle JDK 11 jest płatne do zastosowań komercyjnych. Zatem przejdź na OpenJDK (patrz instrukcja dla dewelopera). Co prawda, na ten moment Oracle daje gwarancję bezpłatnych updateów OpenJDK 11 przez (tylko) 6 miesięcy od wydania. Jest jednak bardzo duże prawdopodobieństwo, że inny podmiot przejmie opiekę nad update’ami OpenJDK 11 przez kilka lat.

Ale właściwie dlaczego? O co w tym wszystkim chodzi?

Zacznijmy od początku.
We wrześniu 2017 miała zostać wydana Java 9. I zgodnie z niesławną tradycją było to wydanie opóźnione prawie o rok. Wszyscy chcieli dobrze, ale wyszło tak jak zwykle: funkcjonalności zaplanowane do implementacji w „dziewiątce”, w szczególności przełomowy JPMS pochłonęły znacznie więcej czasu i wysiłku niż na początku sądzono. Pojawiła się jednak zapowiedź zerwania z tą tradycją: ogłoszono nową kadencyjność wydań Javy (1). Od teraz, kolejne wydania Javy mają być oparte na sztywnym harmonogramie. Nowe wydanie będzie następowało co 6 miesięcy i będzie zawierać te funkcjonalności i ulepszenia które na ten moment uda się dostarczyć – jeśli niektóre będą niegotowe, to po prostu zostaną przesunięte do następnego wydania.

Społeczność przyjęła te wiadomości z entuzjazmem. Oznaczają one, że Java będzie miała szansę dorównać innym językom i platformom w dynamice rozwoju. Każdy kto śledzi nowości będzie znacznie szybciej miał okazję je wypróbować i ewentualnie dostarczyć cenną informację zwrotną. Świadomość powoli do wszystkich docierała.

We wrześniu 2018 zaplanowane była publikacja Javy 11 – pierwszej wersji w nowym cyklu, posiadającej Long-Term Support. Wszyscy na to czekali gdyż wdrożenie LTS ma być gwarancją, że przez długi czas będziemy otrzymywać patch’e krytycznych luk (szczególnie bezpieczeństwa) odkrytych w platformie. Jeżeli Twoje oprogramowanie ma działać przez wiele lat, dobrze jest oprzeć je na wspomnianym wydaniu Javy 11.

Jednakże gdy pojawiła się odpowiedź na czym w praktyce ma polegać LTS, był to pewien szok. Wszystko za sprawą tego, że główny vendor Javy owszem, ma zamiar dostarczyć LTS, z tą drobną różnicą, że … nie za darmo.

Okazało się więc, że nowy sposób wydawania Javy będzie miał konsekwencje idące znacznie dalej niż na początku się wszystkim wydawało.

Tu sprawy zaczynają się komplikować …

Żeby to dobrze zrozumieć, trzeba sięgnąć trochę głębiej i wyjaśnić jak wygląda proces powstawania (wytwarzania) platformy Java SE. Jakie są role różnych podmiotów i osób zaangażowanych w to, by każdy mógł sobie na komputerze, serwerze zainstalować kolejną wersję Javy? Można powiedzieć o trzech zasadniczych rolach:

  • stewardzi i zespół OpenJDK– to osoby takie jak Mark Reinhold, John Rose, Brian Goetz. Ludzie, którzy tworzą platformę Java SE od lat i są w tym zakresie największymi ekspertami na świecie. Odpowiadają za rozwój platformy zgodny z wyzwaniami współczesności i feedbackiem community. Na dzień dzisiejszy są etatowymi pracownikami sponsora. Mimo to mają pewną niezależność myślenia w tworzeniu wizji rozwoju platformy. Uczestniczą w konstruktywnych dyskusjach z innymi przedstawicielami społeczności. Ich praca i decyzje są w dużym stopniu transparentne. Jednoznaczne utożsamianie ich z polityką sponsora, jako ślepych wykonawców, byłoby wobec nich krzywdzące. Polecam niedawne, ciekawe wystąpienie głównego stewarda Javy (2)
  • sponsor – czyli Oracle. To właśnie ta firma sponsoruje deweloperów implementujących OpenJDK. Źródła OpenJDK, choć na licencji GPLv2+CE, są własnością Oracle i leżą na serwerach tej firmy (3).
  • vendorzy – inne podmioty, które korzystając ze źródeł OpenJDK budują, udostępniają (czasem za pieniądze) i wspierają binarne dystrybucje JDK. Dominującym vendorem jest oczywiście Oracle. Lecz innym przykładem vendora może być Red Hat budujący OpenJDK do dystrybucji z systemami RHEL. W pewnym sensie również sam team OpenJDK też przyjmuje rolę vendora budując i udostępniając binarne dystrybucje. Z racji tego że OpenJDK posiada licencję GPLv2+CE, vendorem komercyjnym tak na prawdę może być każdy, kto posiada odpowiednie umiejętności (4).

Mówiąc w dużym skrócie i uproszczeniu, każda nowa wersja Javy powstaje najpierw jako specyfikacja tworzona i uzgadniana przez stewardów i innych leaderów społeczności w ramach Java Community Process. Ta specyfikacja to zbiór popularnych JSR-ów. To z nich powoływana jest tzw. Expert Group, składająca się z ekspertów z obszaru, którego dany JSR dotyczy. Taka forma konsultacji ze społecznością ma szczególne znaczenie w procesie. Jednym z najbardziej doniosłych przykładów takiej współpracy był udział Stephen’a Colebourne’a, twórcy biblioteki Joda Time w grupie eksperckiej tworzącej Java Time API wydane w Javie 8 (14). Gdy JSR-y są gotowe, team OpenJDK tworzy referencyjną implementację tej specyfikacji. Gdy to już jest gotowe, vendorzy biorą źródła OpenJDK, wprowadzają udoskonalenia specyficzne dla swoich docelowych platform sprzętowych lub OSowych i dystrybuują.

Ponieważ do tej pory, firma Oracle (wcześniej Sun) była zarówno pracodawcą stewardów, sponsorem oraz głównym vendorem, to utarł się stereotyp, że „Java to produkt Oracle’a”, a wszystkie decyzje dotyczące platformy to arbitralne narzucenie swojej woli przez tę firmę, motywowane jedynie jej partykularnymi interesami. Nie było to do końca prawdziwe i uzasadnione stwierdzenie. A na pewno będzie coraz mniej prawdziwe od momentu wydania Javy 11.

Wróćmy jednak do próby wyjaśnienia jak najprawdopodobniej będzie działać LTS.

Jak już wiemy, co 3 lata JCP będzie wypuszczać wersję Javy z LTS. Jednakże oznaczenie przez stewardów danej wersji jako LTS nie oznacza, że biorą oni na siebie zobowiązanie jej supportowania. Jest to jedynie „wskazówka” dla vendorów, że jeśli chcą dystrybuować Javę zgodnie z „umową społeczną” społeczności Javy, to powinni swoim użytkownikom docelowym zapewnić długoterminowe wsparcie tych wersji. To więc vendorzy biorą na siebie zobowiązanie poniesienia kosztów wsparcia na konkretny okres. Mogą to jednak robić za darmo, lub pobierając opłaty.

I tak do LTS Javy 11 różnie odnoszą sie różni vendorzy:

  • Oracle: dostarczy dla Oracle JDK kilkuletni LTS ale płatny
  • OpenJDK team (vendor „grzecznościowy”): na obecną chwilę planuje wspierać OpenJDK 11, ale tylko przez 6 miesięcy od wydania (trudno to nazwać wsparciem długoterminowym).

I w tym miejscu trzeba opowiedzieć o nowej inicjatywie społeczności Javy, mianowicie o AdoptOpenJDK (5). Co to takiego? Jest to infrastruktura CI na której są budowane i udostępniane publicznie i bezpłatnie binarne dystrybucje JDK. Budowane są ze źródeł OpenJDK, lecz poza infrastrukturą Oracle’a. Na stronie AdoptOpenJDK można pobrać JDK do zainstalowania na swoim komputerze.

Czy zatem AdoptOpenJDK jest nowym vendorem? Nie jest. Misją tej inicjatywy jest stworzenie niezależnej, publicznej, otwartej infrastruktury do budowania JDK ze źródeł, ale patchowanie tych źródeł już nie. Zatem aby Java była darmowa z długoterminowym wsparciem, potrzebny jest jeszcze ochotnik do patchowania źródeł OpenJDK 11 przez długi czas. Oprócz ochotnika potrzebna jest też zgoda Oracle’a na to by po 6 miesiącach przekazać opiekę nad OpenJDK 11 innemu podmiotowi. I tutaj są dwie dobre wiadomości:

  • wydaje się, że Oracle bez sprzeciwu, a wręcz z przyjemnością zgodzi się na przekazanie opieki. Tak przynajmniej można wnioskować z niedawnej wymiany mailowej na listach OpenJDK, patrz (6)
  • jest ochotnik do wzięcia na siebie długoterminowego supportu nie tylko OpenJDK 11, ale również kontynuacji supportu OpenJDK 8. Ochotnikiem tym jest Andrew Haley, przedstawiciel Red Hata. Jako doświadczony vendor, podmiot ten dysponuje kompetencjami niezbędnymi do podjęcia tej roli. Innym istotnym faktem jest, że Red Hat jest od jakiegoś czasu strategicznym partnerem AWSa, który też zgłasza gotowość zaangażowania swoich zasobów ludzkich w support OpenJDK. Patrz (7)

Jest więc bardzo pradwopodobne (choć jeszcze nie pewne), że faktycznie, Red Hat weźmie na siebie LTS dla OpenJDK, a wolontariusze AdoptOpenJDK udostępnią nam binarne buildy. Za darmo, bardziej za darmo niż kiedykolwiek wcześniej.

Czy to wszystko musiało się wydarzyć? Czy idzie to w dobrym kierunku?

Java SE od lat posiadała pełne spektrum zarówno sympatyków jak i kontestatorów. Co by o niej jednak nie mówiono, trudno jest zaprzeczyć, że jest to od lat najpopularniejsza platforma programistyczna. Tę popularność, w dużym stopniu zawdzięcza temu, że zawsze była dostępna nieodpłatnie Nagła jej komercjalizacja, jak to ma miejsce teraz, stwarza duże ryzyko dla jej rynkowej pozycji. Jest jak tornado wkraczające w strefę komfortu niezliczonych deweloperów i biznesów. Można sobie zadać pytanie, czy to ryzyko podejmowane przez właściciela platformy nie jest zbyt duże. Czy zamiast stać się źródlem dochodu, nie przyczyni się do autodestrukcji ? Czy jako użytkownik platfromy mogę żyć z przekonaniem, że sprawy idą w dobrym kierunku ?

Nie ma oficjalnego stanowiska firmy Oracle, które wyjaśniałoby jakie konkretne intencje stoją za tym posunięciem. Jest to więc pole do domysłów i spekulacji. Łatwo jednak przytoczyć pewne spostrzeżenia i fakty nieodległej przeszłości, które rzucą światło na tę sprawę:

  • Przy rozkwicie rozwiązań cloudowych, mocno opartych na Javie, dziś, bardziej niż kiedykolwiek, różne podmioty, przede wszystkim cloud-providerzy, czerpią korzyści z użytkowania platformy Java SE. Dość naturalną i zrozumiałą tendencją jest poszukiwanie przez sponsora sposobów na zaangażowanie innych podmiotów do partycypacji w kosztach. Szczególnie jeśli wziąć pod uwagę, że te podmioty (jak Amazon) są bezpośrednią konkurencją dla Oracle’a na rynku rozwiązań cloudowych.
  • Innym aspektem związanym z rozkwitem rozwiązań cloudowych jest uniwersalizm Javy SE. Współczesna rzeczywistość pokazuje, że jej rozwój jako monolitu stwarza zbyt wiele problemów i traci sens. Aby pozostać uniwersalna, musi dać możliwość większej customizacji swoim dużym użytkownikom (cloud-providerom). Przyjęcie takiego kursu ma swój wyraz we wprowadzeniu modułowości (Java Platform Module System) w Javie 9, która daje możliwość customizacji JRE pod bardzo konkretne potrzeby. Inny przykład to ulepszona w Javie 10 izolacja API Garbage Collector’a, ułatwiająca podmienianie implementacji tegoż. W Javie 11 idzie to krok dalej: zostaje dodany No-Op Garbage Collector – narzędzie ułatwiające testowanie własnych GC.
  • Stewardzi i zespół OpenJDK są tylko ludźmi, dysponują skończoną ilością czasu. Skoncentrowanie się na rozwoju platformy, kreowaniu jej przyszłości będzie lepszą inwestycją tego czasu, niż długoterminowe wsparcie starzejących się wydań OpenJDK.

Wnioski oczywiście każdy może wyciągnąć sam. Jednakże trudno oprzeć się wrażeniu, że Java zmienia się we właściwym kierunku. To znaczy takim, który odpowiada na potrzeby i wyzwania zmieniającego się świata.

Zatem na koniec

Trzymamy rękę na pulsie, śledzimy wydarzenia i decyzje Oracle, Red Hat’a i innych gigantów odnośnie podziału odpowiedzialności za OpenJDK. Jednocześnie kibicujemy wolontariuszom z AdoptOpenJDK.

Odnośniki:

  1. Mark Reinhold (2017/09/06) „Moving Java Forward Faster”
  2. Mark Reinhold (2018/08/01) „The Future of the Java Platform and the JDK: Who is in Charge?”
  3. OpenJDK Projects
  4. GNU General Public License, version 2, with the Classpath Exception
  5. AdoptOpenJDK
  6. http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001823.html
  7. Andrew Haley (2018/09/24) „The future of Java and OpenJDK updates without Oracle support”
  8. The OpenJDK Developer’s Guide
  9. (OpenJDK) JDK 11 General-Availability Release
  10. Nicolai Parlog (2018/09/25) „All You Need To Know For Migrating To Java 11”
  11. More on GPLv2 with the Classpath Exception
  12. Stephen Colebourne (2018/08/28) „Java is still available at zero-cost”
  13. Stephen Colebourne (2018/09/26) „Oracle’s Java 11 trap – Use OpenJDK instead!”
  14. JSR 310: Date and Time API

Najnowsze wpisy