Rok dopiero nabiera rozpędu, dlatego w dzisiejszym wydaniu mam dla was poza newsami kilka dłuższych tekstów, które jednak mogą się Wam przydać. Nie zabraknie też ciekawych releasów.
1. Zestaw rad, jak zautomatyzować wykrywanie podatności w projekcie
Bezpieczeństwo to temat tak szeroki, jak i często zaniedbywany, co ostatecznie kończy się płaczem, zgrzytaniem zębów i sekcjami w newsletterach typu tego, który właśnie czytacie. Dlatego też początkiem 2023 chciałem podrzucić Wam publikacje The ultimate guide to Java Security Vulnerabilities (CVE) stanowiącą świetny poradnik, jak pracować z szeroko rozumianymi narzędziami SecOps w Javie.
Łukasz Myśliński opublikował końcem poprzedniego roku poradnik, w ramach którego opisał ekosystem narzędzi, którego programiści mogą używać do sprawdzenia swojego „łańcuchu dostaw” zależności. Takich tekstów w sieci nie brakuje, często są pisane przez choćby twórców pojawiających się w artykule narzędzi, ale tutaj zaletą jest Java-Centryczność. Wiele z porad jest po prostu bardzo łatwa do przeniesienia i działająca ze znanym, istniejącym ekosystemem narzędzi. Dlatego polecam lekturę, zwłaszcza jeżeli czeka was niedługo jakiś audyt, recertyfikacja ISO lub po prostu chcecie sprawdzić, czy nie macie u siebie jakichś przeoczonych dziur.
Do powyższej listy, ja bym od siebie podrzucił jeszcze SecHub – narzędzie Open-Source, stworzone przez Mercedes i napisane w Javie, pozawalające zagregować pod wspólną parasolką wiele skanerów bezpieczeństwa online. Będę przyglądał się rozwojowi całości, bo to co do tej pory zostało pokazane ma spory potencjał.
Źródła
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Natywne obrazy GraalVM uruchomione na procesorach RISC-V
Ten news jest nieco mniejszy, ale jakoś tak ładnie wpisuje mi się w ostatnie zmiany w JDK, że stwierdziłem, iż podzielę się z Wami faktem, że Natywne Obrazy GraalVM można odpalić na architekturze RISC-V, o czym poinformował Sacha Coppey, pracujący w Oracle Labs.
Czym RISC-V nie jest gotowym procesorem, a raczej modelem programowym procesora (z angielskiego ISA) opartego o filozofię dostarczania ściśle wyspecjalizowanego zestawu instrukcji (reduced instruction set computer – RISC właśnie). Cytując Wikipedię:
W kontraście do większości ISA, RISC-V może być swobodnie używany w dowolnym celu, umożliwiając każdemu projektowanie, produkcję i sprzedaż czipów i oprogramowania RISC-V. Chociaż nie jest pierwszą otwartą architekturą ISA ma duże znaczenie, ponieważ został zaprojektowany z myślą o nowoczesnych skomputeryzowanych urządzeniach, takich jak ogromne chmury obliczeniowe, wysokiej klasy telefony komórkowe i najmniejsze systemy wbudowane.
Z mojej perspektywy ciekawy jest sam proces, który tego typu operację umożliwił, przypomina on bowiem o wszechstronności całego projektu. Sam kompilator GraalVM nie pozwala bowiem na tworzenie binarek do tej architektury, ale architektura projektu jest na tyle elastyczna, że możliwe jest wpięcie kompilatora używanego przez LLVM – uniwersalnego kompilatora, używanego przez szereg różnych języków. Jeżeli jesteście ciekawi, czym jest LLVM, polecam publikację What is LLVM? The power behind Swift, Rust, Clang, and more. A moim zdaniem warto, bo mówimy tutaj o jednym z najważniejszych klocków świata programowania, który jednak nie jest znany szerokim masą programistów. Moim zdaniem warto mieć chociaż świadomość jego istnienia.
Ogólnie JDK coraz bardziej lubi się z RISC-V, w końcu to właśnie wsparcie dla tych procesorów pojawiło się dopiero co w JDK 19 jesienią zeszłego roku.
Źródła
3. Jak odpowiedzielibyście na pytanie, jak zostać programistą Javy w 2023?
Mam wrażenie, że biorąc pod uwagę zakres tematyczny tego newslettera, raczej nie mam wśród publiki za wielu osób, które dopiero zaczynają przygodę z Javą (jeśli się mylę, napiszcie proszę jak wytrzymaliście wstawkę o wsparciu RISC-V w GraalVM). Na pewno jednak wielu z nas ma młodszych znajomych (choć pewnie nie tylko), którzy pytają, jak w ogóle rozpocząć przygodę z tą całą Javą. Mnie się to czasem zdarza, i przyznam, że odpowiedź nie jest zawsze taka oczywista… zapomniał wół jak cielęciem był, i naprawdę ciężko nakreślić spójną, logiczną ścieżkę którą taka osoba miałaby podążać.
Dlatego też zawsze z wielką radością przytulam teksty, które mogę podrzucić jako takie „pierwsze kroki”. A taką właśnie publikację w zeszłym tygodniu przygotował Gunnar Morling. Getting Started With Java Development in 2023 — An Opinionated Guide z miejsca wylądowało w czołówce mojego prywatnym rankingu ulubionych pozycji dla nowicjuszy. Jego świeżość (nie bez kozery ma 2023 w nazwie) ma też ciekawy efekt uboczny – jeżeli pracujecie w projekcie, który utknął np. na Javie 8 i jakiejś starej wersji Springa, publikacja pozwoli Wam na odświeżenie sobie wiedzy i rozpatrzenie się, co mogło Was ominąć.
Źródła
Zainstaluj teraz i czytaj tylko dobre teksty!
4. Release Radar
A na sam koniec, kilka ciekawych releasów z ostatnich tygodni.
Kotlin 1.8
Tak, wiem, pisałem o nim dopiero co w zeszłym tygodniu jako o wydaniu widmo, a ono jak na złoś pojawiło się dokładnie tego samego dnia co mój rant. W dalszym ciągu jest to fakt godny odnotowania, ponieważ dzięki oficjalnej premierze dostaliśmy standardowy zestaw materiałów towarzyszących, jak np. wprowadzenie wideo do nowej wersji języka, które jak zawsze bardzo polecam.
Więcej moich przemyśleń znajdziecie w poprzedniej edycji.
Mockito 5.0
Drugim z ciekawych releasów z początku roku to Mockito 5.0. Jest to release nietuzinkowy, ponieważ obrazuje on to, że wszelkiej maści migracje na nowe wersje Javy nie zawsze będą takie bezproblemowe.
Mockito do bowiem dość nietypowy projekt – jako, że generuje ono Mocki obiektów, wielokrotnie musi obchodzić modyfikatory dostępu istniejące w Javie, czasem używając mechanizmów takich jak refleksja, w niektórych przypadkach zaś schodząc jeszcze głębiej – do internali JVM. Te ostatnie zaś nie są stabilnym API i zmieniają się pomiędzy poszczególnymi wersjami. Czasem rzeczona modyfikacje są przezroczyste, ale nie zawsze jest możliwe. Bardzo utrudnione jest też równoległe wspieranie wielu wersji JDK, bo każda z nich wymagać może innego mechanizmu.
W związku z tym w Mockito 5.0 postanowiono pozbyć się wsparcia dla starszych JDK, minimalną wspieraną wersją czyniąc JDK 11. Równolegle jednak, twórcy na przestrzeni ostatnich wersji musieli stworzyć nowy sposób mockowania podklas, ponieważ z każdym kolejnym wydaniem stare rozwiązania, ze względu na mocniejsze limitowanie dostępu do internali JDK w kolejnych edycjach, stawały się coraz bardziej ograniczone. Wraz z wersją 5.0, mockito-inline
– nowy mechanizm – stał się wreszcie rozwiązaniem domyślnym
Cała sytuacja jest mi bliska z dwóch powodów. Po pierwsze, jestem (z dumą!) członkiem GitHubowej organizacji Mockito, pracowałem kiedyś z jego twórcami nad ich innym Open-Source – shipkit, który niestety jest już od pewnego czasu martwy (ale dalej cudowne doświadczenie, dziękuję za możliwość 🤩). Dodatkowo, sam natknąłem się historycznie na problemy z internalami Mockito, które miałem okazję opisać w moim pierwszym tekście poświęconym JVM-owi