Przyszłość Javy, bliższa i dalsza
Język Java wkracza odważnie w nową erę w dziejach. W tym artykule pragnę krótko przedstawić, co nas czeka w przyszłych wydaniach, które... są bliżej niż się wydaje!
czwartek, 12 października 2017
Nie opadł jeszcze kurz po premierze Javy 9. Choć wiele wskazuje na to, że upłynie trochę czasu, zanim cały ekosystem dostosuje się do nowej rzeczywistości, to już snute są plany tego, co pojawi się w przyszłych wersjach Javy. Warto trzymać rękę na pulsie, bowiem są one bliżej niż się wielu programistom wydaje i dlatego postanowiłem trochę na ich temat napisać.
Nie będzie Javy 10
Zaraz... że co? Jeśli po przeczytaniu tego nagłówka spadłeś/spadłaś z krzesła, to najwyższa pora się podnieść. Java wcale nie przestaje istnieć, po lecz po prostu zmienia się jej cykl wydawniczy. Jakiś czas temu temu Oracle zapowiedział, że chce wypuszczać nowe wersje co dwa lata, jednak planu tego nigdy nie udało się dotrzymać. W praktyce każde wydanie było napędzane przez jedną wiodącą funkcjonalność i gdy prace nad nią się obsuwały, opóźnienie dotykało całego projektu. Na dodatek w międzyczasie zmieniły się trendy; podczas gdy inne języki ewoluują obecnie dość szybko, czerpiąc dużo z informacji zwrotnej od programistów, w Javie proste usprawnienie trzeba czekać latami. Taka sytuacja nie prowadzi oczywiście na dłuższą metę do niczego dobrego.
Nowy cykl wydawniczy jest odpowiedzią na te potrzeby. Od teraz wydania Javy mają ukazywać się regularnie w półrocznych odstępach i zbierać te funkcjonalności, które akurat będą gotowe. Jeśli któryś z projektów złapie opóźnienie i nie zdąży na dane okienko, przesuwa się po prostu na kolejne. Natomiast Javy 10 nie będzie, ponieważ wraz z cyklem wydawniczym zmienia się też schemat numeracji, który będzie wyglądać następująco:
- Java 9 - wrzesień 2017,
- Java 18.3 - marzec 2018,
- Java 18.9 - wrzesień 2018,
- Java 19.3 - marzec 2019
- ...
Tak więc... powitajmy Javę 18.3!
Aktualizacja z grudnia 2017: pod wpływem krytyki Oracle wycofał się z opisanej powyżej numeracji. Cykl wydawniczy pozostanie, natomiast główne numery wydania będą kontynuować obecną numerację: w marcu Java 10, we wrześniu Java 11 itd.
Wsparcie
Kolejna zmiana dotyczy wsparcia dla starszych wersji języka. Już kilka lat temu skończono z praktyką oficjalnego wspierania w nieskończoność starych wersji Javy. Obecnie ten okres został jeszcze bardziej skrócony, bowiem publiczne wsparcie dla danej wersji ma się kończyć wraz z ukazaniem się kolejnej. Wyjątkiem ma być Java 8, która wciąż będzie utrzymywana do września przyszłego roku. Dla klientów zainteresowanych dłuższym wsparciem będą wydania LTS ukazujące się co trzy lata, aczkolwiek dostęp do poprawek będzie płatny. W sumie jest to zrozumiałe, jeśli się popracuje w firmie sprzedającej oprogramowanie - utrzymanie starych linii kodu oraz środowisk do ich budowania/testów kosztuje, a praktyka pokazuje, że programiści niezbyt chętnie takie linie utrzymują.
Projekt Amber
Przejdźmy teraz do ciekawszych rzeczy, czyli tego, co pojawi się w kolejnych wersjach. Projekt Amber to seria niewielkich usprawnień, których celem jest zmniejszenie ilości pisanego przez programistów kodu. Prace nad trzema z nich są najbardziej zaawansowane i mają one dużą szansę załapać się na marcowe wydanie.
Pierwszym usprawnieniem jest inferencja typów zmiennych lokalnych, czyli możliwość deklarowania zmiennych poprzez var - ich typ ma być wyliczony automatycznie przez kompilator na podstawie wartości początkowej. Java jest ostatnim dużym językiem, któremu tego brakuje, choć mechanizmy wyliczania typów są już wykorzystywane np. przy typach generycznych. Przykład użycia:
public void foo() {
var name = "abc";
}Kolejne usprawnienie umożliwia nam korzystanie z typów generycznych w enumeratorach:
public enum ScalarTypes<T> {
INTEGER<Integer>(Integer.class),
STRING<String>(String.class),
BIGINT<BigInteger>(BigInteger.class);
private final T type;
public ScalarTypes(Class<T> type) {
this.type = type;
}
public Class<T> getType() {
return type;
}
}Ostatnim jest dokończenie rozpoczętego jeszcze w Javie 8 procesu użycia podkreślenia do reprezentowania nieużywanych argumentów w lambdach:
BiFunction<Integer, String, String> f3 = (i, _) -> String.valueOf(i);Aktualizacja z czerwca 2018: pierwotna propozycja projektu Amber zakładała wprowadzenie dwóch nowych słów kluczowych: var oraz val dla zmiennych finalnych. Ostatecznie zrezygnowano z val z dwóch powodów. Pierwszy to optyczne podobieństwo obu słów, co mogłoby powodować ich "zlewanie się" w dłuższych ciągach deklarowania zmiennych. Drugi powód związany jest z tym, że Java idzie obecnie w kierunku tworzenia zmiennych "effective final" i ich jawne deklarowanie w ten sposób przestaje być potrzebne.
Projekt Valhalla
Ten projekt to kolejna dość duża rewolucja w języku, a związany jest mocno z koncepcją typów prymitywnych. Obecnie Java posiada podział na dwa rodzaje typów:
- typy prymitywne:
int,char,boolean, itd. - typy obiektowe - wszystko inne.
Jest pomiędzy nimi wiele zasadniczych różnic. Typy prymitywne są bardzo bliskie temu, jak dane zapisywane są fizycznie w komputerach. Nie posiadają jednak cech obiektowych: kopiowane są zawsze przez wartość, nie można utworzyć do nich referencji, nie mają też żadnych pól, ani metod. Nie można tworzyć nowych typów prymitywnych, ani używać istniejących w generykach. Typy obiektowe są bardzo wygodne w użyciu, jednak jeśli chcemy wykorzystać je np. do reprezentowania prostych wartości (by stworzyć sobie np. ComplexNumber), musimy liczyć się z narzutem wydajnościowym. Obiekt alokowany jest na stercie, musi być czyszczony przez odśmiecacz pamięci, a pomiędzy metodami przekazywana jest tylko referencja.
Jak widać, są sytuacje, kiedy aż prosi się o dodanie nowego "typu prymitywnego", albo tego, żeby typ prymitywny posiadał metody. I temu właśnie służy Projekt Valhalla. Pozwoli on na stworzenie specjalnych klas (value classes), które będą zachowywać się podobnie do typów prymitywnych: nie będą alokowane na stercie, nie będzie można tworzyć więc do nich referencji, a kopiowanie będzie odbywać się przez wartość. Druga część projektu dotyczy rozwinięcia typów generycznych tak, aby mogły one obsługiwać value classes oraz typy prymitywne. Autorzy jednak jasno zaznaczają: It is not a goal of this effort to produce fully reified generics. A oto przykład tego, co ma być możliwe:
var foo = ArrayList<int>();Ten projekt wygląda na dużo mniej zaawansowany niż poprzedni. Przede wszystkim nie doszukałem się sensownych materiałów prezentujących docelową składnię nowych rozwiązań, co może oznaczać, że wciąż jest ona w trakcie opracowywania. Dlatego osobiście nie nastawiam się, że w marcu będzie można z tego skorzystać.
Projekt Loom
Celem tego projektu jest dodanie obsługi lekkich wątków programowych (ang. fibers) do biblioteki standardowej Javy. Wątki programowe nie zapewniają prawdziwego równoległego przetwarzania danych - z punktu widzenia systemu operacyjnego program wciąż widziany jest jako jednowątkowy, jednak w tym wypadku właśnie o to chodzi. Przełączanie się między zadaniami jest realizowane w całości przez aplikację, dzięki czemu jest znacznie szybsze, a lekkie wątki nie wymagają dużo pamięci. Twórcy projektu rozważają również dodanie możliwości wywłaszczania, co pozwoli na przerwanie lekkiego wątku w momencie rozpoczęcia operacji I/O i powrót do niego, kiedy dane będą dostępne.
Podsumowanie
We wpisie przedstawiłem trzy wybrane funkcjonalności, które pojawią się w Javie w bliższej lub dalszej przyszłości. Oczywiście trwających projektów jest dużo więcej, a zmiana cyklu wydawniczego Javy powinna sprawić, że dostęp do nich będziemy uzyskiwać dużo szybciej. Jak będzie w praktyce? Zobaczymy, a tymczasem zamieszczam kilka odnośników do zewnętrznych materiałów:
zobacz inne wpisy w temacie
Komentarze (0)