Czy Java wreszcie stanie się dobrym językiem do nauki programowania? - JVM Weekly vol. 126

1. Czy Java wreszcie stanie się dobrym językiem do nauki programowania?

Java jest popularnym językiem programowania dla dużych, złożonych aplikacji, ale jest również powszechnie używana jako pierwszy język dla początkujących – na przykład w środowisku szkolnym czy też akademickim. Te światy jest z założenia trudno pogodzić – cechy języka, zaprojektowane dla dużych programów mogą być przytłaczające dla nowych uczniów. O ile więc sam na studiach miałem kurs Javy, to już w takim liceum podstaw programowania uczyli mnie na znacznie łatwiejszym do zrozumienia Pascalu (pamięta ktoś jeszcze ten język?).

Twórcy Javy ostatnimi czasy stwierdzili w ramach publikacji Paving on the on-ramp, o której mieliście w przeszłości okazję już czytać, że należy obniżyć próg wejścia dla początkujących. Teraz obietnice materializują się w pierwszym z opisywanych dziś JEP-ów – JEP draft: Anonymous Main Classes and Enhanced Main Methods (Preview). Nawet jeśli nie jesteście „świeżakami”, to i Wy odnajdziecie w nim coś interesującego dla siebie

Bo Wy też kiedyś możecie się znaleźć w powyższej sytuacji.

Twórcy JDK postanowili bowiem uprościć składnie języka dla osób, które używają Javy jako pierwszego języka programowania (i jednak głównie dla nich, o czym za chwilę). Osiągnięte zostanie to dzięki kilka wynikającym z siebie krokom. Pierwszym z nich jest zmiana tak zwanego „protokołu uruchomieniowego” dla Javy. Spójrzmy sobie na ten wszystkim znany fragment kodu:

public class HelloWorld { 
    public static void main(String[] args) { 
        System.out.println("Hello, World!");
    }
}

Całość posiada bardzo wiele nadmiarowej składni – static, void, tablica argumentów. Podejrzewam, że bardzo wiele z Waszych aplikacji nigdy, przykładowo, nie odczytywała argumentów z linii komend, w którym to wypadku String[] args stanowi tylko niepotrzebny szum. Tego typu koncepty powinny być możliwe do przekazania nowicjuszom w momencie, gdy realnie będą potrzebne – ale nie wcześniej. Tutaj wchodzi jednak wspomniany Launch Protocol – czyli zbiór zasad definiujący to, jak musi wyglądać funkcja stanowiąca punkt wejściowy do programu. Ten ma zostać znacznie uproszczony i umożliwić sprowadzenie całości nawet do poniższej postaci:

class HelloWorld { 
    void main() { 
        System.out.println("Hello, World!");
    }
}

Oczywiście, żeby zachować odpowiedni poziom wstecznej kompatybilności, całość obwarowana została zbiorem reguł definiujących, który wariant zostaje wybrany jako ten główny main. Ale po takowe odsyłam już do oryginalnego JEP-a.

Teraz czas, aby zająć się drugim członem nazwy nowego Draftu. Skoro uproszczony został sam kod main, warto byłoby zająć się również drugą częścią „boilerplate”:

class HelloWorld { 
    (...)
}

Dzisiaj, żeby w ogóle zacząć przygodę z Javą, niezbędne jest zrozumienie konceptu klas, co bywa bardzo trudne do wyjaśnienia nowicjuszom. Dlatego też twórcy Javy zdecydowali, że i ten element powinien zostać odchudzony i zamierzają wprowadzić klasy anonimowe – czyli umożliwić pominięcie powyższego fragmentu kodu i pisanie w bardziej „skryptowy” sposób.

Dzięki temu pisanie programu przy użyciu anonimowej klasy głównej jest bardziej skoncentrowane na tym, co program rzeczywiście robi, nie wprowadzając nadmiarowych, niepotrzebnych koncepcji. Każda anonimowa klasa główna obsługuje te same modyfikatory co zwykłe klasy nazwane, posiada domyślny konstruktor bezargumentowy i może posiadać inicjator statyczny. Anonimowa klasa główna musi posiadać również funkcję main.

W praktyce sprowadza się to do tego, że kod:

String greeting() { return "Hello, World!"; }

void main() {
    System.out.println(greeting());
}

opakowywany zostaje w:

new Object() {
    String greeting() { return "Hello, World!"; }

    void main() {
         System.out.println(greeting());
    }
}.main()

Ponownie, jest w powyższym trochę uproszczenia – oryginalny JEP zawiera wiele ciekawych detali.

Co ciekawe – podczas pierwszej publikacji, całość nazywała się JEP draft: Implicit Classes and Enhanced Main Methods. Pewnie wielu programistów Scali nazwa brzmi aż nazbyt znajomo, dodatkowo termin ten opisuje zupełnie inny koncept. W związku z czym dobrze, że postanowiono się z niej wycofać – i tak mamy w branży za dużo konfliktów nazw między poszczególnymi językami programowania.

Źródła

2. JDK żegna się z architekturą procesorów x86-32

Mówi się, że nie ma nic przyjemniejszego niż usuwanie niepotrzebnego już kodu. Wydaje mi się, że utrzymując projekt taki jak JDK można zrobić krok bliżej w stronę nirwany – a to poprzez usuwanie całych środowisk uruchomieniowych.

Jak wynika z JEP draft: Deprecate the Windows x86-32 Port, twórcy Javy przymierzają się bowiem do usunięcia wersji JDK na system operacyjny Windows w wersji 32-bitowej. Na taki krok złożyło się kilka czynników, jak choćby fakt, że Microsoft ostatecznie przestał już wydawać nowe wersje 32-bitowych systemów operacyjnych, a ostatni z nich (Windows 10) straci wsparcie twórców w drugiej połowie 2025. Znacznie ciekawsze są jednak tutaj pobudki praktyczne – z JEP-a okazuje się bowiem, że implementacja Wirtualny Wątków nie jest kompatybilna z 32-bitowymi procesorami.

Pewnie powyższe było wiadome od dawna, a tylko dla mnie to wzięło z zaskoczenia.

Także już niedługo chcących zbudować aplikację przy pomocy JDK na porzuconych systemach, przywita Was poniższy komunikat.

configure: error: The Windows x86-32 port is deprecated and may be removed in a future release.

No cóż, procesory 32-bitowe odchodzą już w niepamięć – ostatnią wspieraną wersją pozostanie ta na architekturę arm32. Jeśli z jakiegoś powodu kluczowym jest dla Was utrzymanie wsparcia dla Windows x86-32, twórcy JDK zostawiają furtkę – wycofają się z powyższego JEP-a, jeśli znajdzie się podmiot zdeterminowany do migracji wirtualnych wątków na 32-bity, ale również dalszego utrzymywania całości portu. Od razu mówię, że nie ma co liczyć na Microsoft – to oni sami zaproponowali tego JEP-a.

PS: Jeśli byliście kiedyś ciekawi, co w ogóle oznacza to x86 które przewija się przy okazji procesorów 32-bitowych – termin oznacza kontynuatorów linii Intel 8086. Tak, żeby było prosto i oczywiście.

Źródła

3. JDK 20 doczekało się zmian w liście JEP-ów

Jak już jesteśmy w świecie JEP-ów, to mamy do czynienia z bardzo nietypową sytuacją. JDK 20 – mające mieć swoją premierę jeszcze w marcu – od grudnia zeszłego roku znajduje się bowiem w fazie Rampdown. Oznacza to, że z założeń nie powinniśmy już spodziewać się pojawienia w nim żadnych nowości. W zeszłym tygodniu, z zaskoczenia został dodany jednak nowy JEP – 438: Vector API (Fifth Incubator).

Wszystkich tych, którzy boją się o stabilność JDK 20 w oblicz tak późnego rozszerzenia uspokajam – piąta już inkubacja Vector API została przypadkowo pominięta, ponieważ jest to kolejna już wersja edycja proposala, nie przynosząca żadnych nowych zmian w API i kodzie źródłowym w stosunku do JEP 426: Vector API (Fourth Incubator), nie ma więc ryzyka jakichkolwiek nieprzewidzianych regresji i zmiana ma charakter formalny. Całość sytuacji wyjaśnia w mailu Mark Reinhold.

Można powiedzieć, że Release Train odjechał i nie zabrał pasażera.

W samym JEP-ie można jednak znaleźć nową ciekawą informację – tak naprawdę na samo Vector API będziemy czekali jeszcze długo, nie należy się bowiem spodziewać żadnej wersji Preview przed stabilizacją Projektu Valhalla. Długoterminowym celem Vector API jest wykorzystanie ulepszeń Valhalli, zwłaszcza Value Classes, nie posiadających tożsamości. API Vector będzie więc inkubowane przez wiele wydań, aż niezbędne funkcje Projektu Valhalla staną się dostępne jako Preview. Po udostępnieniu, API Vector dostosuje się i również dopiero wtedy trafi do Preview. Ciekawe, ile jeszcze kolejnych inkubacji nas w związku z tym czeka.

Pozwolę sobie zacytować tutaj Reddit r/java.

A jak już poświęciłem kilka akapitów, zmuszając Was do zapoznania się z detalami JEP-u, na którego jeszcze poczekamy, to w nagrodę podrzucę Wam dwie bardzo dobre, świeże publikacje, podsumowujące zarówno obecny stan Valhalli, jak sposoby i użycia Vector API. Zainteresowanych tematem odsyłam odpowiednio do publikacji Project Valhalla: A look inside Java’s epic refactor oraz Accelerating vector operations on the JVM using the new jdk.incubator.vector module. Oba tematy mają tendencje do przedawniania się, teksty te pozwolą Wam lepiej uporządkować sobie wiedzę.

A skoro już było o JDK 20, to na sam koniec wspomnę o wydaniu, które będzie mu towarzyszyć. Ukazała się bowiem pierwsza testowa edycja GraalVM CE 23.0.0, która zbudowana została w oparciu o zbliżającą się wersję JDK. Dowiedzieliśmy się również, że GraalVM 23.0 będzie zawierał wsparcie dla ZGC. Umożliwi to używanie wspomnianego Garbage Collectora w sytuacji, gdy Graal jest używany jako kompilator JIT. Żeby nie było za słodko – ZGC ciągle jednak nie będzie wspierany w wypadku Native Image. Te jednak również doczekają się usprawnień – mają być bowiem dostępne out-of-the-box, bez potrzeby doinstalowywania dodatkowych zależności.

Czy Java wreszcie stanie się dobrym językiem do nauki programowania? – JVM Weekly vol. 126

1. Czy Java wreszcie stanie się dobrym językiem do nauki programowania?

Źródła

2. JDK żegna się z architekturą procesorów x86-32

Źródła

3. JDK 20 doczekało się zmian w liście JEP-ów

Źródła

Odkryj więcej świetnych treści!