JVM Weekly #97 - IntelliJ dostaje dużego kopa na MacOS

1. Wyszedł nowy Intellij Idea 2022.2

Nie wiem, czy jest choć jedna osoba świadomie czytająca tą serię, która nie kojarzy czym jest IntelliJ Idea. Twórcy najlepszego (chyba mogę tego słowa użyć i nie czeka mnie lincz, prawda?) IDE dla Javy regularnie wydają nowe wersje swojego narzędzia, jednocześnie potrafiąc uczynić każdą kolejną edycję interesującą. Nie inaczej jest i tym razem, zwłaszcza, że oprócz nowych funkcjonalności wprowadzono naprawdę duże zmiany „pod maską” – zwłaszcza dla użytkowników macOS.

I to nie że są jakoś uprzywilejowani… po prostu Idea na MacOS miał pewne braki.

Wydany wczoraj IntelliJ Idea 2022.2 wprowadza bowiem nową wersję JetBrainsRuntime, czyli utrzymywanego przez JetBrains forka OpenJDK. Nie wiem czy każdy zdaje sobie sprawę, że mimo iż Idea jest napisana w Javie, to od dawna już nie używa zainstalowanej w systemie wersji JDK, zamiast tego operując na własnej, zbundlowanej. Takową da się podmienić, co w przeszłości pomagało z wydajnością, bowiem fork jak to fork – czasem pozostawał trochę z tyłu za możliwościami Javy. Przykładowo, dostarczana do tej pory wersja JBR opierała się na JDK 11, nie mogła więc skonsumować zmian, które przez ostatnie parę lat trafiły do Javy. Teraz się to zmieni.

Pewnie w tym momencie zastanawiacie się, jakież to zmiany mogą być istotne z punktu widzenia IDE. JetBrainsRuntime w wersji 17 przynosi min. wsparcie Projektu Lanai, czyli prowadzonej przez JetBrains inicjatywy mającej na celu „pożenienie” Javy z Metal API, czyli (nie tak już) nowym pipeline renderującym dla systemu macOS. Dotychczas używany OpenGL od dawna wyleciał poza obszar zainteresowań firmy z Cupertino, Metal zaś jest regularnie rozwijany, w efektywny sposób konsumując wszystkie nowości wprowadzane w hardwarze MacBooków – a tych przecież ostatnio była masa (M1, anybody?). JetBrains chwali się znacznym wzrostem wydajności na Apple Silicon, aczkolwiek nie dogrzebałem się konkretnych benchmarków. JBR17 przynosi też pierwsze eksperymenty firmy z Vector API, częścią Projektu Panama, która pozwala na bezpośredni dostęp do hardware, z (prawie)pominięciem javowej abstrakcji.

Co jednak przynosi nowy IntelliJ poza zwiększoną wydajnością? Oczkiem w głowie firmy wydaje się być Zdalny Development i ten doczekał się w nowej edycji IDE kolejnych usprawnień. Pomimo dalszego pozostawania w Becie, usprawnieniom doczekało się wsparcie pracy poprzez SSH na zdalnej maszynie, a także JetBrains Gateway, czyli w wizji JetBrains nowe centrum naszej pracy zdalnej, cienki klient pozwalające na zarządzanie zewnętrznymi środowiskami. Sporo usprawnień doczekali się też szczęśliwcy mający dostęp do zamkniętej bety JetBrains Spaces, czyli bezpośredniej konkurencji dla VSCode.

Ucieszą się też użytkownicy Springa – IntelliJ od teraz wspiera bowiem nadchodzące Spring 6 i Spring Boot 3, których premiera ma nastąpić już tą jesienią, a od pewnego czasu dostępne są w wersjach testowych. Firma zwiększyła też kompatybilność z własnym Kotlinem 1.7 czy wsparcie featurów Groovy 4. Nie braknie również nowych inspekcji kodu. Ogólnie, jeśli jesteście ciekawi pełnej listy zmian, zachęcam do pełnej listy zmian.

Z ciekawości – czy ktoś jeszcze ogarnia wszystkie narzędzia jakie daję IntelliJ? Mam wrażenie, że to daje jakieś nadludzkie supermoce, ale z drugiej strony zastanawiam się, czy ktoś rzeczywiście używa wszystkiego 😉

Dla kompletności tego postu – swojej nowej wersji doczekał się też Plugin dla Scali. Ten doczekał się standardowego zestawu zmian, takich jak nowe możliwości Scali czy nowe automatyczne refaktoringi. Najciekawszym dodatkiem wydają się być możliwość użycia zewnętrznego Error Highlightera.

Na koniec łyżka dziegciu. Jest to bowiem dobra okazja by przypomnieć, że parę tygodni JetBrains zapowiedział wzrost cen swoich subskrypcji od 1 października. Inflacja bije biednych Devów po kieszeni z kolejnego kierunku, mimo że twórcy zarzekają się, że jest to bardziej związane z nowymi możliwościami narzędzia niż inflacją jako taką.

Może niektórzy łaskawszym okiem spojrzą na Visual Studio Code.

Źródła

2. Co pozostało do powiedzenie w sporze dziedziczenie vs kompozycja?

Tak jak wszyscy kojarzą IntelliJ Idea, tak podejrzewam, że niewiele jest tak ogólnie znanych książek o Javie jak Effective Java. Ta swoista biblia javowego programowania co prawda nie była od pewnego czasu aktualizowana (ostatni raz przy okazji Javy 9), w dalszym ciagu pozostaje jednak lekturą obowiązkową i źródłem większości wiedzy plemiennej, którą programiści przekazują sobie z pokolenia na pokolenie, w ramach procesu nazywanym przez antropologów jako „review kodu”. Trochę tutaj ironizuje, ale mam wiele szacunku dla pana Blocha i jego opracowania – pozwala nam nie wymyślać każdorazowo koła na nowo, a większość z porad jest naprawdę użyteczna i umożliwiająca pisanie lepszego kodu.

Bo zawsze lepiej uczyć się na cudzych błędach.

Dlaczego jednak piszę o Effective Java? Z jakiegoś powodu Oracle zdecydowało się na swojego Java Magazine zamieścić jej zaadaptowany rozdział, dotyczący powodów, dla których warto rozważyć kompozycje zamiast dziedziczenia. Nie wiem czy w świecie programowania obiektowego w Javie jest bardziej oklepany temat – w momencie gdy sam język i jego najbardziej zaangażowane community po drodze zdążyło już flirtować zarówno z programowaniem funkcyjnym, a ostatnio coraz modniejsze jest mówienie o mezaliansie z programowaniem zorientowanym na dane (Data-Oriented Programming). Okazuje się, że jest to jednak pewna banieczka, ponieważ temat Dziedziczenie vs Kompozycja w dalszym ciągu rozgrzewa – na javowym Reddicie wygenerował on bowiem dyskusję na ponad 160 łapek w górę i więcej niż 65 komentarzy, co jest rzadko spotykane w ramach tej społeczności. Niektóre przykłady w dyskusji są na tyle interesujące, że polecam lekturę wątku – w odróżnieniu od Blocha, (który jak wspomniałem zatrzymał się na poziomie JDK 9) dyskusja kręci się bardziej w koło tego, jak nowe dodatki do języka typu sealed class dokładają argumentów do tego starego jak programowanie obiektowe problemu.