JVM Tuesday vol. 30

1. Żywot Applet API zbliża się ku końcowi…

Zacznijmy od nowiny, która pewnie wielu zaciekawi, choć podejrzewam, że z początkiem roku 2021 raczej nie wywróci nikomu pracy. Otóż wraz z Javą 17 i JEP-398, Applety oficjalnie znikają z JDK.

Nie jest to prawdopodobnie dla nikogo szczególna niespodzianka, gdyż “deprekacja” Appletów w JDK nastąpiła już parę lat temu, przy okazji Javy 9. Jednak tak naprawdę prawdziwym “pocałunkiem śmierci” dla tego sposobu dystrybucji Javowych aplikacji, były jednak działania podmiotów zewnętrznych – przeglądarek. Żeby zrozumieć dlaczego, musimy przyjrzeć się kontekstowi, w którym applety powstawały.

W roku 1995 przeglądarka Netscape Navigator była domyślnym wyborem dla każdego bardziej świadomego użytkownika internetu. Były to czasy zanim internet na dobrą sprawę zaczął się standaryzować. Także twórcy przeglądarek mogli sobie pozwolić na nieco bardziej szalone pomysły niż w dzisiejszym świecie – jak np. znienawidzony przez wszystkich ActiveX, znany userom Internet Explorera. Jednak i Navigator mógł poszczycić się “własnościowymi” rozwiązaniami łączącymi świat przeglądarek i aplikacji desktopowych. Najważniejszym z nich był Netscape Plugin Application Programming Interface – w skrócie NPAPI. Był to pierwszy popularny standard pisania wtyczek do przeglądarek i to właśnie na nim oparli się twórcy Javy, dając możliwość uruchamiania JVMowych aplikacji “zaembedowanych” w przeglądarce.

Mimo śmierci Netscape w 2003, standard NPAPI nie umarł. Został on bowiem zaadaptowany przez Firefox, Chrome czy Safari. Jednak z czasem jego dobra passa zaczęła przygasać. NPAPI było pełne luk bezpieczeństwa, zasobożerne i bardzo często powodowało zawieszanie przeglądarek. Wraz z rozwojem “natywnych”, webowych alternatyw, mniej więcej od 2013 roku poszczególni vendorzy powoli zaczęli się z tego standardu wycofywać. Oracle zaś już w 2016 roku zapowiedziało, że nie zamierza proponować alternatywy.

Tak więc mniej więcej za pół roku ostatecznie pożegnamy Applety. Ciekawe, jak wiele korporacyjnych środowisk nigdy nie będzie mogło się zaktualizować (zarówno do nowej Javy, jak i aktualniejszych wersji przeglądarek), gdyż jakiś np. system rozliczania delegacji nigdy nie zostanie przepisany z Appletu na coś bardziej przystającego do roku 2021.

Źródła:

2. …za to Valhalla otrzymuje nowe Preview

Oracle zabiera, Oracle również daje. W zeszłym tygodniu pojawiły się aktualizacje dwóch “Kandydatów”, związanych z projektem Valhalla.

JEP 401: Primitive Objects przewijał się już w jednej z naszych poprzednich edycji (notabene, pierwszej, która opublikowana została na tym blogu), wtedy jeszcze jako draft. W celu przypomnienia – obiekty prymitywne (używanie tłumaczenia “prymitywne obiekty” wydaje mi się być ciut niestosowne) to nowy sposób deklarowania typów przez użytkowników języka. Celem jest tutaj możliwość stworzenia przez programistów własnych “prymitywów”, czyli obiektów nieposiadających nagłówka (o nagłówkach więcej pisaliśmy tydzień temu) oraz “tożsamości”, trzymanych na stosie, a nie w heapie.

Jednak tym co tak naprawdę ciekawe, jest JEP 402: Unify the Basic Primitives with Objects. Podchodzi on do tematu z zupełnie drugiej strony. Otóż jego celem jest migracja wszystkich istniejących już typów prymitywnych (jak int, boolean czy char) do obiektów prymitywnych, sprawiając że te ostatnie stają się wspólną abstrakcją również dla tych bardzo podstawowych elementów języka. Sprawia to, że ostatecznie każda wartość na JVMie będzie miała cechy obiektu.

W proposalu jest kilka smaczków. Po pierwsze, dotychczas istniejące wrappery, znane wszystkim programistom Javy od edycji piątej, finalnie znikną z języka. Pewnie wielu z Was w tym momencie osiwiała z przerażenia na myśl, jak bardzo uderzy to w kompatybilność wsteczną, ale już śpieszę z wyjaśnieniem. Otóż np. takie java.lang.Integer zostanie “reużyte” jako klasa powiązana z obiektami prymitywnymi int. W ten sposób zapewniona będzie kompatybilność wsteczna, przy wyeliminowaniu narzutu, który wiązał się z autoboxingiem.

JVM dokopująca się do wartości w `java.lang.Integer`

Nie oznacza to jednak końca problemów. Jak się okazuje, świeżo wydana Java 16 wprowadza JEP 390: Warnings for Value-Based Classes, który jakoś umknął naszej uwadze. Dodaje on ostrzeżenia przy próbie użycia publicznego konstruktora klas wrappujących. Według aktualnej wersji JEPa, te ostatecznie mogą zniknąć z języka po wprowadzeniu Valhalli. Zmianom ulegnie również nieco sposób zachowania refleksji, a także to jak typy prymitywne reprezentowane będą w bytecodzie .

Faza Preview oznacza, że już niedługo będziemy mogli się tymi nowymi możliwościami języka pobawić. Osobiście spodziewam się Javy 18, ale trzymam kciuki, że już 17 udostępni “podgląd” choć jednego ze wspomnianych proposali. Niebezpośrednio zapowiedziana został również kolejny krok całego procesu – umożliwienie używania obiektów prymitywnych jako generyków. Czekamy niecierpliwie.

Źródła:

3. Co pod kątem bezpieczeństwa zmieniło się w Javie 16

Na sam koniec – króciutko o bezpieczeństwie.

Każda nowa edycja Javy to także nowy artykuł od Seana Mullana, który od kilku wydań szczegółowo opisuje wszelkie zmiany pod kątem security.

Klasycznie nowa wersja
Javy to zmiana we wspieranych algorytmach i ponownie lista ta jest stosunkowo długa. Dodana została m.in. kompatybilność z nowymi pozycjami z rodziny SHA-3. Oprócz tego możliwość użycia TLS 1.0 i 1.1 domyślnie zostały wyłączone i w celu ich użycia trzeba je celowo włączyć na poziomie maszyny wirtualnej. Dodano też możliwość podpisywania plików JAR za pomocą wprowadzonej w Javie 15 nowej rodzinie algorytmów eliptycznych.

Nie będę się już więcej rozwodził, Sean zrobił to za mnie. Jeśli chcecie więcej szczegółów, zapraszam do artykułu…

… crypto nerdy.

1. Żywot Applet API zbliża się ku końcowi…

Źródła:

2. …za to Valhalla otrzymuje nowe Preview

Źródła:

3. Co pod kątem bezpieczeństwa zmieniło się w Javie 16

Źródła:

Odkryj więcej świetnych treści!