Pisząc klasy w typowej aplikacji Java (mam na myśli wersję 8) – finalnie prawdopodobnie pakujemy te pliki w archiwa jar. Kompilując czy uruchamiając program – musimy dodać do classpatha wszystkie wykorzystywane “jarki”. Czasem, gdy nie jesteśmy ostrożni może to skutkować tzw. “JAR Hell” – stanem, w którym wczytywanie klas nie przebiega prawidłowo. Java 9 wspiera programistę w tym, by uniknąć tego upokorzenia – wprowadzając modularyzację.
Java 9 – Nowa reprezentacja Stringów
Dotychczas w Javie Stringi, czyli łańcuchy znaków były reprezentowane właśnie w ten konkretny sposób: jako dosłownie łańcuch znaków, a raczej tablica, char[]. Każdy char ma alokowane 16 bitów pamięci, dla reprezentowania palety znaków UTF16. W najpopularniej wykorzystywanym języku łacińskim o kodowaniu UTF8 chary nie były wykorzystywane w pełni, ponieważ każdy znak alokowane miał 16 bitów, a wypełniał 8. A co, gdyby udało się pozbyć tej pustej przestrzeni i wykorzystać wszystkie bajty przeznaczone na dany napis?
Java 9 – Garbage Collector G1GC
Java ma bardzo przyjemny mechanizm – Garbage Collector. Jest to dodatkowy program uruchamiany przez wirtualną maszynę po to, aby czyścić pamięć ze starych, nieużywanych obiektów. Gdyby nie on, kolejne tworzone obiekty lądowałyby na stercie tak długo, aż aplikacja zajęłaby całą pamięć, co uniemożliwiłoby jej pracę. Dzięki GC nie musimy się specjalnie zamartwiać alokacją i zwalnianiem pamięci. Od Javy 9 standardem jest Garbage Collector zwany G1GC (Garbage First GC), który wprowadzony był już wcześniej, jednak jeszcze wtedy nie był domyślnym czyścicielem w JDK. Na czym polega? Jak działa? Czytaj dalej „Java 9 – Garbage Collector G1GC”
Java 9 – Unmodifiable Collections
Java się bardzo rozwija. Początkowe podejście, według którego nowa wersja Javy wychodziła co kilka lat, odeszło do lamusa. Obecnie w każdym roku mamy dwa wydania – w marcu oraz we wrześniu.
Nie znaczy to, że co pół roku musimy updatować nasze wszystkie biblioteki. Wraz z częstymi updatami w Javie wprowadzono pojęcia LTS (Long Term Support) oraz non-LTS. I tak, co pół roku dostajemy nową wersję Javy, jednakże co trzy lata mamy “duży” update, który ma długoterminowe wsparcie. Na ten moment najnowszy LTS to Java 17, która zostanie zmieniona we wrześniu tego roku. Oprócz tego, do 2030 roku wsparcie będzie utrzymywane dla Javy 8.
W Javie 9 mamy wprowadzonych kilka nowości, a jedną z nich, które zostaną podjęte w tym wpisie są metody fabryczne dla niemodyfikowalnych kolekcji.
#BeEffective – Wzorzec Singleton
Singleton jest wzorcem projektowym, którego celem jest zapewnienie o istnieniu dokładnie jednej instancji danej klasy i udostępnieniu jej globalnie. W tym wpisie poruszę temat jego wykorzystania, zalet, wad oraz sposobów implementacji w oparciu o książkę Joshuy Blocha – Java – Efektywne programowanie. Czytaj dalej „#BeEffective – Wzorzec Singleton”
#BeEffective – Zastosowanie wzorca Builder (budowniczego)
W pierwszym wpisie z cyklu #BeEffective poruszony został temat statycznych metod fabrycznych i konstruktorów. Posiadają one jednak pewną wspólną wadę – nie są optymalne do obsługi wielu parametrów opcjonalnych. Rozważmy przypadek klasy reprezentującej etykiety z informacją o składnikach odżywczych. Taka etykieta z pól wymaganych posiada wielkość porcji, ilość porcji na opakowanie oraz liczbę kalorii na 100g produktu. Posiada także wiele pól opcjonalnych – od prostego podziału węglowodany / białka / tłuszcze, po rozbite na części pierwsze wszystkie mikro i makroelementy. Większość produktów niezerowe wartości ma tylko dla kilku z pól opcjonalnych. Czytaj dalej „#BeEffective – Zastosowanie wzorca Builder (budowniczego)”
Co to są klasy wewnętrzne
Czasem struktura danych naszej aplikacji daleko odbiega od idealnej, kiedy wszystko jest oddzielnym obiektem z jasnymi powiązaniami. Istnieją takie sytuacje, w których wykorzystanie danej klasy ma sens jedynie w połączeniu z inną. Poznajmy więc klasy wewnętrzne.
Wyjątki w Javie
Każda aplikacja zawiera błędy. Tak samo w każdej aplikacji pewne ścieżki są nieprzewidziane. Zadaniem zespołu tworzącego aplikację jest znaleźć te miejsca w kodzie i odpowiednio je obsłużyć. W ten sposób można płynnie dojść do javowego mechanizmu wyjątków, który pomaga programistom w obsłużeniu błędnych ścieżek w algorytmach.
Nowy cykl – #BeEffective – Statyczne metody fabryczne zamiast konstruktorów
Dość późno w mojej karierze dotarłem do książki, którą każdy middev powinien przeczytać, bo dopiero teraz. Ten tytuł to oczywiście Java. Efektywne programowanie od Joshuy Blocha. Tym samym otwieram cykl #BeEffective, w którym omawiać będę kolejne lekcje tego podręcznika. W końcu, jak stoi w przedmowie tejże książki – na podstawie tej książki możesz zaprojektować własny kurs. Czytaj dalej „Nowy cykl – #BeEffective – Statyczne metody fabryczne zamiast konstruktorów”
Czy na pewno tu nie będzie nulla?
java.lang.NullPointerException. Każdy go zna, każdy uwielbia, a debugując enterprisową aplikację (napisaną oczywiście przez kogoś innego, my byśmy takiego błędu nie popełnili!), natrafiwszy na taki zapis w logach można dostać białej gorączki. I niby każdy wie, że powinno się stosować null-checki w newralgicznych miejscach. Tak samo jak każdy wie, że jakby co to są Opszonale. A i tak w tym jednym jedynym miejscu ani null-checka ani typu Optional nie będzie, bo przecież tam i tak nie będzie nulla. Zapraszam do lektury. Czytaj dalej „Czy na pewno tu nie będzie nulla?”