Dawno, dawno temu, na produkcji, pojawił nam się problem z wydajnością aplikacji. Analiza i rozwiązanie problemu pochłonęła nam dobre kilka dni. Debugowaliśmy, czytaliśmy dokumentację, analizowaliśmy logi. Nic nie mogliśmy znaleźć, do momentu, gdy nas oświeciło. Analizowaliśmy requesty i zauważyliśmy, że większość czasu żądania była na odczycie wartości z… cache. Problem był banalny. Zapychaliśmy cache’a generując za każdym razem uniwersalny klucz wartości. Chwilę wcześniej mergowaliśmy ogromnego PR, który pozmieniał w kodzie dużo – za dużo. Zmiany były w różnych częściach aplikacji – technicznych i biznesowych. To był nasz ogromny błąd.

Uznałem, że artykuł, który w sposób początkujący przedstawi temat cache pomoże innym. Mi też będzie punktem referencyjnym w przyszłości. W dzisiejszym artykule:

• Czym jest cache
• Cache lokalny vs rozproszony
• Algorytmy przechowujące dane
• Inwalidacja cache
• Monitorowanie cache

Czym jest cache

Cache w Javie to mechanizm przechowywania często używanych danych, w celu szybszego dostępu i poprawy wydajności aplikacji. Możemy zastosować go do operacji, które są czasochłonne lub kosztowne w wykonaniu. Dobrymi przykładami takich operacji są zapytania do bazy danych, requesty do API czy powtarzalne obliczenia matematyczne.

Załóżmy, że tworzymy aplikację pobierającą informacje o pogodzie. Informacje pobieramy z różnych lokalizacji, z zewnętrznego serwisu pogodowego za pomocą REST API. Pobierane dane zmieniają się co 3 godziny. Z naszej aplikacji dziennie korzysta około 50 000 osób, co przekłada się na średnio 2000 requestów na godzinę (upraszczamy, że ruch został rozłożony na całą dobę równomiernie). Użytkownicy pochodzą głównie z Polski i często pytają o te same lokalizacje. Aby uniknąć wywoływania zewnętrznego serwisu pogodowego wiele razy, możemy użyć mechanizmu cache. Przyspieszymy dostęp do informacji i unikniemy ciągłego zapytywania zewnętrznego API.

Cache lokalny vs rozproszony

Pamięć cache, możemy podzielić na dwa typy: lokalny i rozproszony. W tej sekcji postaram się opisać ich cechy, wady oraz zalety. Na końcu sekcji wrzuciłem też dwie tabele. Jedna porównująca cechy obydwu typów i druga z przykładami i rekomendacjami, który rodzaj wybrać w danej sytuacji.

Cache lokalny (In-memory cache)

In-memory cache to lokalny cache w procesie aplikacji, który przechowuje dane w pamięci RAM na jednym serwerze. Pozwala to na błyskawiczny dostęp do danych tam przechowywanych. Jest on najszybszy, ale ograniczony rozmiarem pamięci dostępnej w jednej instancji aplikacji. Jego główne cechy to:

• Lokalność: dane przechowywane są w pamięci RAM konkretnego procesu lub instancji aplikacji.
• Szybkość: dostęp do danych jest ekstremalnie szybki, ponieważ omijana jest komunikacja sieciowa i operacje na dysku.
• Prostota: może być implementowany za pomocą prostych struktur danych, np. ConcurrentHashMap, lub dedykowanych bibliotek, np. Caffeine.
• Brak współdzielenia: dane w cache są dostępne tylko dla jednego procesu lub instancji aplikacji (chyba że używana jest rozproszona implementacja in-memory, np. Hazelcast).

Zalety:

• Wysoka wydajność: zapewnia bardzo niski czas dostępu do danych, ponieważ przechowuje je w pamięci RAM. Odczyt danych z pamięci jest znacznie szybszy niż z dysku twardego czy bazy danych, co przyspiesza działanie aplikacji.
• Prosta implementacja: jest stosunkowo łatwa i nie wymaga skomplikowanej konfiguracji. Istnieje wiele gotowych rozwiązań, oferujących gotowe mechanizmy.

Wady:

• Ulotność danych: dane zostaną utracone w przypadku restartu serwera lub awarii aplikacji.
• Ograniczona pojemność: pojemność jest ograniczona przez dostępność pamięci RAM na serwerze. W przypadku dużych aplikacji lub intensywnego wykorzystania pamięci może to prowadzić do problemów z wydajnością lub brakiem miejsca na nowe dane (OutOfMemoryError).
• Trudności w skalowaniu: w architekturze rozproszonej każda instancja aplikacji ma swoją własną pamięć podręczną, co może prowadzić do problemów z synchronizacją danych między instancjami oraz zwiększonego ryzyka nieaktualnych informacji.

Cache rozproszony (Distributed cache)

Działa na wielu serwerach w klastrze, umożliwiając szybki dostęp do często używanych danych. Pamięć współdzielona jest między wieloma instancjami aplikacji i umożliwia obsługę dużych wolumenów danych oraz zapewnia wysoką dostępność danych. Jego główne cechy:

• Rozproszenie danych (eureka!): te same dane dostępne z różnych instancji aplikacji.
• Skalowalność: może być łatwo skalowany poprzez dodawanie nowych węzłów do klastra. To pozwala na zwiększenie pojemności cache i obsługę większej liczby żądań.
• Odporność na awarie: dzięki replikacji danych na różnych węzłach, nawet w przypadku awarii jednego z nich, dane pozostają dostępne.
• Partycjonowanie (sharding): każdy węzeł przechowuje tylko część danych, a aplikacja odwołuje się bezpośrednio do odpowiedniego serwera.

Zalety:

• Wysoka dostępność i odporność na awarie: dane mogą być replikowane na wielu węzłach, dzięki czemu awaria jednego serwera nie powoduje utraty danych.
• Szybkość i niskie opóźnienia: dane przechowywane są w pamięci RAM (z tym, że na wielu węzłach w porównaniu z lokalnym cache).
• Usprawnienie pracy mikroserwisów: w systemach mikroserwisowych cache rozproszony pozwala na szybką wymianę danych między usługami bez konieczności ciągłego odpytywania bazy danych.
• Obsługa dużych wolumenów danych: dzięki partycjonowaniu dane mogą być równomiernie rozłożone na węzłach, co pozwala na obsługę dużych zbiorów danych w rozproszonym środowisku.

Wady:

• Opóźnienia Sieciowe: cache działa na wielu serwerach, co oznacza, że każde zapytanie musi przejść przez sieć. Jeśli węzły są oddalone geograficznie, latencja wzrasta.
• Koszt Pamięci RAM: RAM jest znacznie droższy niż dysk, a cache rozproszony przechowuje dane w pamięci operacyjnej. Skalowanie dużych systemów wymaga serwerów z dużą ilością RAM-u.
• Nieścisłości w Danych (Data Inconsistency): dane na różnych węzłach mogą być przez chwilę niespójne. Możesz odczytać stare dane, zanim propagacja zmian się zakończy.
• Złożoność architektury: wprowadza dodatkową złożoność do architektury systemu. Wymaga planowania i zarządzania, aby zapewnić prawidłowe działanie i integrację z innymi komponentami systemu.
• Split-Brain: Jeśli węzły stracą komunikację między sobą, może dojść do stanu „split-brain”, gdzie różne węzły mają różne wersje danych. Część aplikacji może korzystać z nieaktualnych danych.

Rozproszony vs Lokalny

Cecha	Rozproszony Cache	Lokalny Cache
Lokalizacja danych	Dane są przechowywane na wielu instancjach.	Dane są przechowywane w pamięci RAM lokalnej instancji aplikacji.
Dostępność danych	Dane są współdzielone między wszystkimi instancjami aplikacji w klastrze.	Dane są dostępne tylko dla jednej instancji aplikacji.
Przykłady technologii	Redis, Memcached, Hazelcast, Infinispan, Apache Ignite, Ehcache (tryb rozproszony)	Caffeine, Guava, Ehcache (tryb lokalny), ConcurrentHashMap
Szybkość dostępu	Dostęp jest szybszy niż do bazy danych, ale wymaga komunikacji sieciowej.	Dostęp jest ekstremalnie szybki, ponieważ dane są przechowywane w pamięci lokalnej.
Skalowalność	Łatwo skalowalny dzięki rozproszonej architekturze – nowe węzły można dodawać w celu zwiększenia pojemności.	Skalowalność ograniczona do zasobów (RAM) jednej instancji aplikacji.
Niezawodność danych	Może obsługiwać replikację i trwałość danych.	Dane są ulotne – tracone w przypadku restartu aplikacji lub awarii instancji.
Złożoność zarządzania	Zazwyczaj wymaga dodatkowej konfiguracji.	Łatwe w zarządzaniu – wystarczy biblioteka lub struktura danych w aplikacji.
Przeznaczenie	Do współdzielenia danych między wieloma instancjami lub usługami w architekturze rozproszonej	Do lokalnego buforowania danych specyficznych dla jednej instancji aplikacji.
Czas życia danych (TTL)	Obsługuje globalne TTL dla danych, które są ważne niezależnie od instancji.	Dane wygasają tylko w kontekście jednej instancji aplikacji.
Koszty	Wymaga dodatkowych zasobów infrastruktury (np. serwery Redis, Memcached).	Niskie koszty – wykorzystuje lokalną pamięć aplikacji.
Odporność na awarie	Może być replikowany, co zwiększa odporność na awarie	Dane są tracone w przypadku awarii procesu aplikacji.

Kiedy wybrać który?

Algorytmy przechowujące dane

Wiemy już czym jest cache i jakie są jego typy. Teraz pora poznać jakie algorytmy są implementowane najczęściej. Warto poznać co się dzieje pod bebechami, w jaki sposób nasze dane są organizowane w cache. W gotowych rozwiązaniach mamy możliwość customizowania, znając skróty (np. LRU, LFU) oraz teoretyczne działanie algorytmu, jesteśmy w stanie lepiej go ustawić.

• Zastosowania i ograniczenia: Omówienie, kiedy i dlaczego warto stosować dany algorytm oraz ich potencjalne ograniczenia.

Najpopularniejsze algorytmy to:

• LRU (Least Recently Used)
• LFU (Least Frequently Used)
• FIFO (First In, First Out)
• ARC (Adaptive Replacement Cache)
• SLRU (Segmented LRU)
• 2Q (Two-Queue)

LRU (Least Recently Used)

Algorytm LRU usuwa najdawniej używane elementy z cache, aby zrobić miejsce dla nowych. Jest to jeden z najczęściej stosowanych algorytmów, ponieważ dobrze odzwierciedla rzeczywiste wzorce użycia danych. Warto go stosować gdy ważne są najświeższe dane.

Wyobraźmy sobie aplikację udostępniającą zdjęcia. Zdjęcia są przechowywane na dysku, a ich pobieranie zajmuje pewien czas. Aby przyspieszyć dostęp do często żądanych zdjęć, aplikacja może użyć cache LRU. Kiedy użytkownik żąda zdjęcia, aplikacja najpierw sprawdza, czy znajduje się ono w pamięci podręcznej. Jeśli tak, zdjęcie jest natychmiast zwracane. Jeśli zdjęcia nie ma w pamięci podręcznej, aplikacja pobiera go z dysku, zapisuje w pamięci podręcznej i zwraca użytkownikowi. Pamięć podręczna LRU ma ograniczoną pojemność, więc gdy jest pełna, algorytm usuwa najdawniej używane zdjęcie, aby zrobić miejsce dla nowego. Dzięki temu często żądane zdjęcia są szybko dostępne, co poprawia wydajność serwera i skraca czas ładowania strony dla użytkowników

LFU (Least Frequently Used)

Algorytm LFU usuwa elementy, które były najrzadziej używane w danym okresie czasu. Wymaga on śledzenia liczby odwołań do każdego elementu w cache, co może zwiększać złożoność implementacji i obciążenie pamięci. Warto go stosować gdy ważna jest częstotliwość użycia.

Wyobraź sobie, że tworzysz aplikację finansową, która pokazuje kursy walut w czasie rzeczywistym. Każdego dnia tysiące użytkowników sprawdza notowania, ale większość z nich interesuje się tylko kilkoma najpopularniejszymi walutami – np. USD, EUR i PLN. Zamiast za każdym razem pobierać dane z API, przechowujemy w pamięci najczęściej pobierane kursy walut, a rzadko używane usuwamy.

1⃣ Użytkownik pyta o kurs USD/PLN. Sprawdzamy, czy mamy go w LFU Cache.
2⃣ Im częściej dana waluta jest wyszukiwana, tym dłużej pozostaje w cache.
3⃣ Jeśli cache jest pełny, usuwamy najrzadziej pobierane waluty.

FIFO (First In, First Out)

Algorytm FIFO usuwa najstarsze elementy z cache’a w momencie, gdy osiągnięty zostaje jego maksymalny rozmiar. Jest to prosty algorytm, ale może nie być optymalny w przypadku, gdy starsze dane są nadal często używane.

Załóżmy, że budujemy serwer proxy, który buforuje strony internetowe, aby zmniejszyć liczbę żądań wysyłanych do serwera źródłowego. Kiedy użytkownik odwiedza stronę, jej zawartość jest zapisywana w pamięci podręcznej. Jeśli inny użytkownik zażąda tej samej strony, proxy zwróci ją z cache, zamiast pobierać ponownie z internetu.

Jednak cache ma ograniczoną pojemność, więc najstarsze strony muszą być usuwane, aby zrobić miejsce na nowe. FIFO dobrze sprawdza się w tym przypadku, ponieważ starsze strony są mniej prawdopodobne do ponownego użycia.

ARC (Adaptive Replacement Cache)

ARC to bardziej zaawansowany algorytm, który łączy cechy LRU i LFU. Dostosowuje się do zmieniających się wzorców użycia danych, starając się utrzymać równowagę między częstością a świeżością danych w cache’u. Algorytm opiera się na czterech listach, które służą do zarządzania pamięcią podręczną. Dwie główne listy, T1 i T2, odpowiadają za przechowywanie odpowiednio niedawno używanych oraz często używanych elementów. Dodatkowo istnieją dwie listy pomocnicze, B1 i B2, które przechowują referencje do elementów wcześniej usuniętych z T1 i T2, co pozwala na inteligentne dostosowanie algorytmu do zmieniających się wzorców dostępu do danych.

Załóżmy, że mamy system rekomendacji filmów w serwisie streamingowym. Filmy mogą być często oglądane przez różnych użytkowników (np. hity kinowe), ale niektóre treści mogą być oglądane tylko raz przez jednego użytkownika (np. premierowe odcinki seriali). ARC może być tu użyty do cache’owania najczęściej oglądanych filmów, jednocześnie dostosowując się do zmieniającego się trendu popularności. Jeśli dany film jest nagle często oglądany przez wielu użytkowników, ARC zwiększy swoją pamięć dla takich elementów (T2). Jeśli użytkownicy konsumują głównie nowe treści (np. nowy sezon serialu), ARC dostosuje się do tego, zwiększając T1 i usuwając mniej popularne starsze filmy.

SLRU (Segmented LRU)

SLRU to wariant klasycznego algorytmu LRU, który wprowadza podział pamięci podręcznej na dwa segmenty: ochronny i próbny. Ochronny przechowuje często używane elementy, które zostały uznane za „ważne”, próbny natomiast nowe elementy, które jeszcze nie zostały uznane za istotne. Nowo wczytane elementy trafiają najpierw do segmentu próbnego. Jeśli element zostanie ponownie użyty, jest przenoszony do segmentu ochronnego. Elementy z segmentu ochronnego mają pierwszeństwo przed usunięciem – jeśli pamięć cache jest pełna, elementy usuwane są w pierwszej kolejności z segmentu próbnego, co zwiększa szanse na zachowanie często używanych danych.

Weźmy realny przykład z e-commerce. Każdy użytkownik, odwiedzając sklep internetowy, otrzymuje sesję, która może być wykorzystywana wielokrotnie, np. podczas dodawania produktów do koszyka, ale w wielu przypadkach jest jednorazowa – użytkownik przegląda stronę i nigdy nie wraca. W takim scenariuszu nowo utworzone sesje trafiają najpierw do segmentu próbnego pamięci podręcznej. Jeśli użytkownik podejmuje kolejne działania, jego sesja zostaje przeniesiona do segmentu ochronnego, co oznacza, że uznano ją za wartościową. W momencie, gdy pamięć cache się zapełni, system usuwa w pierwszej kolejności elementy z segmentu próbnego, pozostawiając w cache sesje użytkowników aktywnie korzystających z platformy. Dzięki takiemu podejściu unika się przechowywania w cache sesji użytkowników, którzy odwiedzili stronę tylko raz i nie wykazali żadnej aktywności.

2Q (Two-Queue)

Algorytm 2Q to ulepszona wersja LRU, która lepiej radzi sobie z jednorazowymi dostępami do danych. Dzieli pamięć cache na dwie główne kolejki: A1 i Am. Nowe elementy trafiają najpierw do A1, która pełni funkcję filtra. Jeśli dany element zostanie użyty ponownie po usunięciu, przechodzi do Am, gdzie przechowywane są często wykorzystywane wpisy. Dzięki temu system unika sytuacji, w której jednorazowe żądania wypierają wartości bardziej istotne.

Wyobraź sobie aplikację internetową dla sklepu online, który obsługuje zapytania użytkowników o szczegóły produktów. Każde zapytanie pobiera dane z bazy, co może powodować duże obciążenie serwera. Standardowy mechanizm cache oparty na LRU miałby problem, gdyby użytkownicy jednorazowo przeglądali wiele różnych produktów – te mniej popularne mogłyby wypierać z cache’a często wyszukiwane artykuły.

Algorytm 2Q rozwiązuje ten problem poprzez wstępną kolejkę A1, do której trafiają nowo pobrane produkty. Jeśli dany produkt zostanie zapytany tylko raz, po krótkim czasie zostanie usunięty, nie wpływając na cache długoterminowy. Natomiast produkty często wyszukiwane zostaną przeniesione do kolejki Am, gdzie będą utrzymywane dłużej, co przyspieszy ich późniejsze ładowanie. Dzięki temu aplikacja efektywnie zarządza pamięcią cache, zmniejsza liczbę zapytań do bazy danych i poprawia czas odpowiedzi dla użytkowników.

Porównanie algorytmów

Inwalidacja cache

Inwalidacja cache to proces usuwania lub aktualizowania nieaktualnych danych w pamięci podręcznej. Jest kluczowa dla zapewnienia spójności danych i zapobiegania zwracaniu przestarzałych wartości. Istnieją różne strategie inwalidacji, zależnie od wymagań aplikacji.

Inwalidacja oparta na czasie (TTL – Time-To-Live) / TTI (Time-To-Idle)

TTL jest najprostsza metodą, w której każdy wpis w cache ma określony czas życia. Po upływie tego czasu zostaje automatycznie usunięty. TTI powoduje usunięcie wpisu z cache, jeśli nie był on używany przez określony czas. TTI i TTL można łączyć, np. ustawić TTL na 30 min i TTI na 10 min, aby zapewnić zarówno maksymalny czas życia, jak i usuwanie nieaktywnych danych.

Inwalidacja natychmiastowa (Explicit Invalidation)

Aplikacja ręcznie usuwa wpisy z cache, gdy dane ulegną zmianie. Gwarantuje to aktualność danych, ale wymaga dokładnego zarządzania cachem.

Inwalidacja oparta na polityce zastępowania (LRU/LFU)

LRU usuwa najdawniej używane wpisy, a LFU najrzadziej używane wpisy. Sprawdza się, gdy cache ma ograniczony rozmiar. Jego wadą jest, że może przetrzymywać nieistotne dane, które znalazły się w cache a mogłyby już z niego wylecieć.

Jaką strategię wybrać?

• Dane szybko się zmieniają? → TTL + TTI + Explict Invalidation.
• Masz ograniczoną pamięć cache? → LRU/LFU.
• Dane muszą być zawsze aktualne? → Explict Invalidation.

Monitorowanie cache

Monitorowanie cache to kluczowy proces, pomagający utrzymać wydajność, spójność danych i oszczędność zasobów. Aby efektywnie monitorować cache, należy zastanowić się nad metrykami.

Jakie metryki warto zbierać?

• Hit Ratio – określa, jak często dane są znajdowane w cache, zamiast być pobierane z bazy.
• *Miss Rate – pokazuje, ile zapytań nie znajduje danych w cache i musi iść do bazy. Jeśli zbyt wysoki, warto zwiększyć rozmiar cache lub poprawić strategię inwalidacji. Miss Rate i Hit Ratio wzajemnie sumują się do 100%, więc mierząc jeden, automatycznie otrzymujesz drugi.
• Eviction Rate (Wskaźnik usunięć) – Mierzy, ile obiektów zostało usuniętych z cache (z powodu przepełnienia, TTL lub inwalidacji). Zbyt wysoki wskaźnik oznacza, że cache jest za mały.
• Memory Usage (Zużycie pamięci) – ile RAM zajmuje cache.
• Latency (Opóźnienie) – ile trwa odczyt/zapis w cache.

Jak monitorować Cache w Javie?

W Javie istnieje kilka sposobów monitorowania cache. Dużo zależy od tego, jakiego typu aplikację rozwijamy/tworzymy. Jeżeli tworzysz aplikację w Spring Boot, możesz w prosty sposób dodać zależności do actuatora + micrometer’a i prometheusa.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

Następnie w application.properties (lub analogicznie yaml z odpowiednią strukturą) wystarczy włączyć metryki i możemy strzelać do API:

management.endpoints.web.exposure.include=*

curl 'http://localhost:8080/actuator/caches' -i -X GET

Teraz można przenieść te dane do Prometheusa, zrobić dashboardy na Grafanie, dodać alerty i mamy gotowy system monitorujący. Nie jest to temat na ten artykuł.

Natomiast jeżeli nie używamy Spring Boota, możemy użyć MBean’ów JMX’a. Jeżeli korzystasz z popularnego rozwiązania do cache’owania w Javie, to jest duża szansa, że to rozwiązanie daje możliwość udostępnienia danych przez JMX. Osobiście korzystając z tych metryk, używałem bezpośrednio DataDog’a, więc nie jestem w stanie powiedzieć czy integracja ze stackiem Prometheus + Grafana jest tu możliwa, ale zakładam, że tak.

Podsumowanie

Cache jest potężnym narzędziem, które może znacząco przyspieszyć działanie aplikacji. Poprzez inteligentne przechowywanie danych w pamięci podręcznej, możemy zmniejszyć czas dostępu do nich i zwiększyć wydajność. Warto zatem znać i rozważyć wykorzystanie cache’a.

Jeżeli chciałbyś rozwinąć którąś z sekcji, podzielić się swoją opinią czy doświadczeniami, to zachęcam do dyskusji w komentarzach.

Artykuł Cache w Javie. Trochę wiedzy pochodzi z serwisu bdabek.pl.

Cześć 

Na wstępie zaznaczę, że nie jest to pełna lista, czego warto unikać przy pracy z wyjątkami. Są to jednak przypadki, które zdarza mi się widzieć w kodzie produkcyjnym, a czasami bywa, że sam dokładam do tego jakąś cegiełkę (z czego nie jestem specjalnie dumny).

Jeżeli masz jakiś pattern do dodania, napisz w komentarzu. Zaktualizuję listę.

W dzisiejszym artykule:

• Zbyt szczegółowe informacje
• Przerzucanie wyżej
• Dziesiątki podtypów
• Uciszanie wyjątkowych sytuacji
• Finally z ostatecznym zdaniem

Zbyt szczegółowe informacje

Zdarzyło Ci kiedykolwiek się zobaczyć stack trace błędu aplikacji tam, gdzie nie powinno go być? A może sam napisałeś kod, który podobne bagienko wyrzucał na zewnątrz?

Jestem przekonany, że się z tym spotkałeś. Pamiętaj aby nie dawać końcowym użytkownikom zbyt szczegółowych informacji, gdy nie powinni mieć do niej dostępu. Co to znaczy nie powinni mieć dostępu?

Pisząc oprogramowanie, np. dla instytucji finansowej, na 100% nie chcesz zdradzać używanych technologii i frameworków. Nie jest jasne dlaczego wystąpił błąd (w teorii takie sytuacje przecież nie powinny się wydarzyć bo to wyjątki) i kto go spowodował. Być może ktoś właśnie przeprowadza atak i zbiera dodatkowe informacje. Ujawienie zbyt wielu szczegółów otwiera nowe wektory ataku – można wnioskować które wersje bibliotek są używane i szukać pod nie payload’ów.

Przerzucanie wyżej

Kolejnym często spotyknanym mechanizmem jest wyrzucanie wyjątków warstwę wyżej. Celowo użyłem słowa mechanizm, zamiast błąd. Ile razy zdarzyło Ci się widzieć jakiś Checked Exception (nie pasuje mi tu spolszczenie tego słowa), definiowany na poziomie metody w jakimś serwisie a następnie propagowanym w górę? A właściwie to wyżej i wyżej i tak aż do samego kontrolera.. który, też próbuje wyrzucić to warstwę wyżej.

class Controller {
  public Response serwis() throws Exception {
    return Response.of(new Service().metodaSerwisowa());
  }
}

class Service {
  public String metodaSerwisowa() throws Exception {
    return prywatnaMetodaSerwisowa();
  }

  private String prywatnaMetodaSerwisowa() throws Exception {
    // logika wyrzucająca Exception
    return "Nie istotne";
  }
}

Łap wyjątki jak najszybciej. Wacham się, żeby to napisać, bo wszystko zależy od kontekstu, ALE jeżeli nie wiesz jak obsłużyć ten wyjątek (nie jesteś pewny czy ktokolwiek powinien go łapać), zamień go na Runtime Exception. W przypadku błędu skończysz właściwie z tym samym.

Dziesiątki podtypów

Zdarzyło Ci się widzieć lub definiować specyficzne wyjątki dla poszczególnych case’ów tylko po to aby łatwiej móc zdiagnozować jego wystąpienie?

Jest mi głupio, bo sam w to brnąłem. Tworzyłem nowe wyspecjalizowane wyjątki, których nie miałem zamiaru obsługiwać. Definiujesz customowy wyjątek? Rób to tylko i wyłącznie w przypadku, gdy wiesz, że będziesz go obsługiwał!

Uciszanie wyjątkowych sytuacji

Co powiesz o takim kodzie? Zdarzyło Ci się widzieć lub napisać coś takiego?

public String doSmth() {
  try {
    businessMethodThatThrowsException();
  } catch(Exception e) {
    // TODO:
  }
}

Skoro już obsługujesz wyjątek, to zostaw po nim ślad! Unikaj łapania i wygłuszania wyjątków! Sama nazwa wyjątków mówi, że są to sytuacje wyjątkowe. Jeżeli już wydarzyła się ta wyjątkowa sytuacja, lepiej niech poleci jakakolwiek informacja na stdout. Dlaczego? Będziesz mieć więcej informacji o systemie z jakim pracujesz! Jeżeli będzie to bardzo uciążliwe, to ktoś się tym na pewno zajmie.

Finally z ostatecznym zdaniem

Java działa w taki sposób, że to blok finally ma ostateczne zdanie. Jeżeli kod wyrzuca wyjątek w bloku try, a następnie również w finally, to ostatecznie ten drugi będzie propagowany. Rozważ taki przykład, jak myślisz, co zostanie wyrzucone?

public String doSmth() {
  try {
    throw new IllegalArgumentException("try");
  } catch (RuntimeException e) {
    throw new IllegalStateException("catch", e);
  } catch (Exception e) {
    // nigdy się nie wykona
    System.out.println("oo?");
  }
  finally {
    throw new RuntimeException("finally");
  }
}

Jeżeli powiedziałeś RuntimeException, to masz rację. Spójrz, jaki jest tutaj problem. Straciłeś informację o prawdziwym problemie. Pamiętaj, blok finally ZAWSZE ma ostatnie zdanie!

Podsumowanie

Nie jest to może za obszerny artykuł, natomiast są to sytuacje, które zdarza nam się widzieć i czasami popełniać. Jeżeli masz jakieś inne patterny do dodania, to dziel się śmiało :).

Źródła:

• Victor Rentea – The Definitive Guide to Working with Exceptions in Java
• Presenting Exceptions to Users
• Exception Handling Guide in Java

Artykuł Wyjątki. Czego unikać? pochodzi z serwisu bdabek.pl.

Jeżeli chodzi o poświadczenie wiedzy w zakresie Javy, to dobrą metodą jest uzyskanie certyfikatu. Aby otrzymać certyfikat, trzeba zaliczyć egzamin na odpowiednim poziomie — obecnie jest to 65% poprawnych odpowiedzi. Każde podejście to koszt około 1050 złotych (245$). Czy jest to najlepsza forma? Zapewne nie. Szczególnie dlatego, że sam egzamin nie pokazuje tego jak myślimy, a jedynie sprawdza naszą znajomość języka i jego specyfikacji, ale o tym w dalszej części artykułu.

Osobiście mam przeświadczenie, że niewiele osób decyduje się na pozyskiwanie certyfikatów (szczególnie w świecie Javy). Wydaje mi się, że jednym z głównych powodów jest rozpowszechnione myślenie, że certyfikaty niczego nie dają. Dają czy nie dają? Do tego wrócimy jeszcze we wnioskach…

W artykule będę zamiennie używał słów certyfikat / egzamin. Oba terminy odnoszą się po prostu do podjęcia próby zaliczenia egzaminu, czy też jego konsekwencji — uzyskania certyfikatu.

W dzisiejszym artykule:

• Ścieżki certyfikatów – OCA, OCP. Co to?
• Przygotowania do egzaminu OCA
• Zapis na egzamin
• Przebieg egzaminu

Ścieżki certyfikatów – OCA, OCP. Co to?

Certyfikacja z Javy posiada kilka możliwych ścieżek. Wybór zależy od potrzeby — naszej lub naszych przełożonych. Nie zawsze jednak możemy ot, tak wybrać dowolną ścieżkę certyfikacyjną. Niektóre z egzaminów wymagają spełnienia pewnych warunków wstępnych. Informacje na temat warunków znajdziesz np. na platformie edukacyjnej Oracle’a lub na stronie konkretnego egzaminu (wpisz nazwę egzaminu — requirements).

Jaka jest różnica między OCA a OCP?

• OCA jest skrótem od Oracle Certified Associate. W świecie certyfikacji jest to egzamin identyfikujący się pod nazwą: 1Z0-808 – Java SE 8 Programmer I. Obecnie (lipiec, 2022) egzamin składa się z 70 pytań, trwa 150 minut, kosztuje 245$ i aby go zaliczyć, trzeba poprawnie odpowiedzieć na 65% pytań.
• OCP, to skrót od Oracle Certified Professional. Jego nazwa w systemie certyfikującym to 1Z0-809 – Java SE 8 Programmer II. Na lipiec 2022 egzamin posiada takie same parametry jak OCA, z wyjątkiem liczby pytań, która wynosi 85!

Zarówno OCA, jak i OCP są egzaminami sprawdzającymi naszą wiedzę w zakresie języka Java. Mają one jasno zdefiniowane bloki tematyczne, wokół których możemy się spodziewać pytań. Nie jest więc tak, że zapisując się na egzamin, musimy znać Javę od A do Z. Moim zdaniem egzaminy OCA oraz OCP są najbardziej wiarygodnym poświadczeniem wiedzy w zakresie znajomości języka.

Ścieżka certyfikacji z Javy prezentuje się w sposób pokazany na obrazku poniżej. Jest to zdjęcie z jednego z popularniejszych serwisów dających dostęp do zestawów testowych (oczywiście za odpowiednią opłatą).

Przygotowania do egzaminu OCA

Cały etap przygotowań podzieliłem na trzy sekcje: analiza, teoria oraz praktyka

Analiza

Na tym etapie nie wiedziałem jeszcze nic, o tym, jak wygląda ścieżka certyfikacyjna. Czym są poszczególne egzaminy, czego się spodziewać, od czego zacząć, jak i na który egzamin się zapisać.

Przed podejściem do egzaminu lepiej mieć wiedzę w tym zakresie. Pozwoli to prawidłowo zaplanować, co musimy powtórzyć, czego musimy się nauczyć, jak zapisać się na egzamin, co mieć ze sobą itp. Na całe szczęście nie trzeba wiedzieć aż tak dużo. Wybierając standardową drogę:

1. Musisz wiedzieć, czym jest OCA, a czym OCP
2. Jaki jest zakres zagadnień poszczególnych egzaminów
3. Z jakich materiałów teoretycznych będziesz korzystać (więcej o tym w sekcji Teoria)
4. Z jakich materiałów praktycznych będziesz korzystać (więcej o tym w sekcji Praktyka)
5. Jak zapisać się na egzamin
6. Jak przygotować się do egzaminu online (nie omawiam tego w tym artykule, ale jeżeli jesteś ciekawy/a, daj znać)

Jeżeli masz kogoś znajomego, kto przechodził podobną drogę, porozmawiaj z nim! W moim przypadku, kiedy podchodziłem do egzaminu, nie miałem nikogo, kto by przetarł przede mną drogę. Zatem, każdy z tych kroków musiałem eksplorować sam. Dzięki Bogu w Internecie jest ogrom informacji i znając język angielski (a podchodząc do egzaminu, powinieneś znać ten język) bez problemu znajdiesz odpowiedzi na większość pytań.

Teoria

Na tym etapie trzeba zapoznać się z materiałem obowiązującym na egzaminie. Może to być przeczytanie książki, która przygotowuje do konkretnego egzaminu lub kurs online. Ja zachęcam do wybrania książki! Jeżeli sami przeczytamy i przerobimy zadania, to więcej zostanie w głowie niż po obejrzeniu kursu.

Należy pamiętać, egzamin a programowanie na co dzień, to dwa różne światy. Egzamin zawiera pytania pułapki i sprawdzi Twoją znajomość języka oraz składni. Pokusiłbym się nawet o takie stwierdzenie: egzamin postawi Cię w roli kompilatora.

Natomiast bez obaw! Egzaminy są przeprowadzane od wielu lat i, pomimo że pytania się zmieniają, to struktura egzaminu NIE! I dlatego na przestrzeni lat powstało kilka dobrych materiałów do nauki. Z mojej strony polecę Ci książkę, z której sam korzystałem i jestem zadowolony: OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide: Exam 1Z0-808. Książka typowo pod egzamin. Autorzy dają wiele wskazówek odnośnie do samego egzaminu. Piszą, na co zwracać uwagę i jakich pytań pułapek można się spodziewać. Co więcej, dla każdego z rozdziałów (jest ich 6), przygotowany jest zestaw pytań, sprawdzający w praktyce przeczytaną wiedzę. Dla osoby z kilkuletnim doświadczeniem książka wchodzi lekką ręką

Inną, również polecaną przez wielu lekturą jest OCA Java SE 8 Programmer I Certification Guide by Mala Gupta. Nie czytałem, więc nie mogę z czystym sercem polecić, ale patrząc na recenzje, uważam, że będzie równie wartościowa.

Praktyka

Sekcja praktyczna, czyli rozwiązywanie zadań i przykładowych egzaminów próbnych.

Dzięki temu, że kupiłem wcześniej polecaną książkę (tą), miałem dostęp do strony z testami. Są tam trzy próbne testy (60 pytań każdy), dodatkowo są tam też testy dla każdego z poszczególnych podrozdziałów książki.

Jednak to nie wydawało mi się to wystarczające i bałem się podchodzić do egzaminu wartego 1050 zł bez większej praktyki. W fazie analizy znalazłem kilka polecanych źródeł z przykładowymi testami. Najpopularniejszymi serwisami z pytaniami są:

• Enthuware
• Whizlabs.

Oba są relatywnie tanie — cena około 10$ za 400-500 różnorodnych pytań. Ja zdecydowałem się na Whizlabs. Testy na Whizlabs są ok. Nie mam niestety porównania z Enthuware. Na pewno plusem Whizlabs jest to, że korzystamy z przeglądarki internetowej + do każdego pytania są krótkie wyjaśnienia, dlaczego powinniśmy wybrać daną odpowiedź a inne odrzucić. Choć przyznam, że wyjaśnienia te czasami bywają bezwartościowe. Podam przykład, spolszczając co nieco i dodając szczyptę ironii: odpowiedź A jest błędna, ponieważ nie można tak robić. Mało wyjaśniający tekst, bo bardziej mnie interesowało, dlaczego tak nie można. Całe szczęście takich bezsensownych odpowiedzi nie jest wiele :). Po przeczytaniu wcześniej polecanej książki i przerobieniu pytań na Whizlabs zaliczyłem egzamin na 95%, więc moim zdaniem były to wartościowe źródła.

Inne materiały, nad którymi się zastanawiałem, podaję poniżej. Jednak ze względu na ich cenę, postanowiłem, że wolę odpuścić.

• certification-questions.com
• certleader.com

Zapis na egzamin

TL;DR

Zapis na egzamin w styczniu 2021 w moim przypadku był uciążliwy. Pojawiło się kilka przeszkód, ale ostatecznie udało mi się zapisać… siedząc na słuchawce z konsultantem z UK (a po akcencie wnioskując to z Indii).

Znane mi opcje do zapisu były dwie:

1. kupuję voucher/egzamin na stronie Oracle, a następnie wykorzystuję w systemie certyfikującym (pearson vue)
2. kupuję egzamin bezpośrednio w systemie certyfikującym (pearson vue)

Pomyślałem, że skoro to egzamin Oracle’owy, to kupię egzamin ze strony Oracle’a. Problemy zaczęły się już przy uzupełnianiu profilu… pola walidujące (imię, nazwisko, adres itp.) to porażka. Masz wszystko uzupełnione, wciskasz ok i dostajesz błąd walidacji. Mało tego, pole walidujące numer telefonu posiada wejście na 10 cyfr (pomijając prefiks, który jest wykrywany automatycznie na podstawie wcześniej wprowadzonych pól) i jeżeli podamy mniej (a polskie numery są 9-cyfrowe), to co się dzieje? Oczywiście mamy błąd walidacji! Mocno mnie to zirytowało i aż napisałem do supportu Oracle’a, jak mam uzupełnić to dziadostwo. Rozwiązanie, jakie podali: proszę wprowadzić 0 (zero) jako pierwszą cyfrę.

Przeszliśmy już przez wszystkie pola walidujące, mamy nasz voucher i kierujemy się do płatności. Na ten moment (przypominam, styczeń 2021) są tam 4 metody płatności — najwygodniejsza to oczywiście płatność kartą i tylko taką byłem zainteresowany, więc nie mogę opisać swoich wrażeń z pozostałymi. Wybrałem płatność kartą, uzupełniłem dane karty i aby móc przejść do samego zakupu, trzeba było potwierdzić kartę (lub to, że jest się jej właścicielem, nie wiem). Ogólnie to przenosi mnie na stronę banku, loguję się, widzę płatność dla Oracle’a na 1 zł (!), potwierdzam płatność na telefonie. Strona banku reaguje, że wszystko się udało i za chwilę powrócę do dalszych zakupów i… BAAAM, wywaliło mnie na pustą kartę. W pasku URL widzę tylko dziwny adres jakiegoś API i w zasadzie tyle.

Nic nie mogę zrobić. Na karcie widzę obciążenie na złotówkę (wisiało tak przez około tydzień) i tyle. Spróbowałem powtórzyć proces jeszcze 3x na innych przeglądarkach (nawet na wspaniałym IE!). Na żadnej się nie udało. Ale taki mały tip, że w zależności od przeglądarki, pola walidacyjne działały lepiej (tam, gdzie obsługa flasha była włączona, tam działało to trochę lepiej). O łał… Trochę ponarzekałem, a dopiero przechodzimy do samego systemu certyfikującego — perason vue. Postaram się bardziej streszczać.

W tym przypadku, pola walidacyjne, wprowadzanie numeru telefonu, itp. było o niebo prostsze! Niestety, był ten sam problem z płatnością. Potwierdzasz płatność i dostajesz przekierowanie na pustą stronę. Byłem już zirytowany tym wszystkim i napisałem maila do supportu, jak mam się zapisać na ten egzamin, bo sam nie umiem. Powiedzieli, aby kontaktować się z ich obsługą, podali numer telefonu (numer w UK, bo nie mają wsparcia w Polsce) i godziny pracy. Dzwonię… Standardowa infolinia, automat coś gada i wybieram odpowiednie przyciski. Po kilku wciśnięciach i kolejnych kilku minutach oczekiwania w kolejce w końcu łączy mnie z jednym z konsultantów wspierających sekcje Oracle.

Udało mi się zapisać na ten egzamin za 5 telefonem. Ogólnie całe flow polega na tym, że podajesz swoje dane i mówisz, co chcesz, dlaczego nie możesz sam tego zrobić i oni wprowadzają wszystkie dane za Ciebie. Ale dobra… dlaczego dopiero za 5 razem?? Jeżeli coś im nie działało w systemie, to się rozłączali! Przykład: przeszedłem z gościem przez całe flow, doszliśmy do płatności. Gościu mi mówi, że system akurat im leży, żebym poczekał 4-5 minut i wtedy spróbujemy. Po 5 minutach odezwał się, że dalej nie działa i żebyśmy jeszcze chwilę poczekali. Czekam, czekam… cała rozmowa trwa już 20 minut i nagle słyszę BIP, gościu się rozłączył. A tylko przypomnę, że to rozmowa z numerem z UK, która nie jest specjalnie za tania…

Dobra rada dla każdego, kto musi dzwonić za granicę. Używajcie Skype’a, wychodzi o wiele taniej (lub za darmo, jak się w dobrą promocję trafi).

Przebieg egzaminu

Ten artykuł i tak wyszedł spory, więc w tej sekcji postaram się pisać krótko i zwięźle. Ja podchodziłem do egzaminu online, więc naturalnie ten proces będę opisywać.

Wszystkie przydatne informacje co do samego egzaminu można było znaleźć na tej stronie. Mnie ciekawił bardziej proces weryfikacji przed przystąpieniem do egzaminu i jak to przebiega. Na oficjalnych stronach nie mogłem nic znaleźć, ale jest YouTube :). Poniżej podsyłam video, które przedstawia, jak wygląda proces weryfikacji.

W kwesti samego egzaminu nie było tu nic nadzwyczajnego. Dostajesz pytania i je rozwiązujesz. Egzamin posiada różne typy odpowiedzi — jednokrotnego lub wielokrotnego wyboru. Jeżeli pytania są wielokrotnego wyboru, to w pytaniu jest jasno określona ilość poprawnych odpowiedzi (nie da się zaznaczyć większej ilości). Wszystkie pytania są zamknięte.

Kończąc egzamin, nasz wynik (procent poprawnych odpowiedzi), jest przedstawiony zaraz po zakończeniu. A więc wciskasz Finish i za 10 sekund wiesz, czy egzamin jest zaliczony, czy nie.

Podsumowanie

Egzamin zaliczyłem z wynikiem 95% – myślę, że to jest całkiem ok. Czy warto było wydawać pieniądze na egzamin? W moim przypadku przenosiło się to bezpośrednio na wynagrodzenie, więc dla mnie było warto. Oprócz tego bardzo często firmy oferują pokrycie kosztów, więc czemu by nie spróbować za pieniądze pracodawcy? Dodatkowo mam certyfikat, który dla ewentualnych, przyszłych klientów już coś mówi (co prawda samym OCA może lepiej się nie chwalić, ale lepszy rydz niż nic). Mogę też wpisać coś dodatkowego do CV (o ile potrzebuję). Oprócz kwestii biznesowych, przygotowanie do egzaminu pozwoliło powtórzyć i utrwalić podstawy.

Artykuł Certyfikacja z Javy. Egzamin OCA i Moje Wnioski pochodzi z serwisu bdabek.pl.

Cześć 

Nie będzie to artykuł, który poprowadzi Cię szczegółowo po dokumentacji API. Chciałbym Ci przedstawić główne idee dotyczące czasu oraz abyś zrozumiał jak używać czasu. Dziwnie to brzmi jak używać czasu, ale taka jest koncepcja. Wiele osób nie zastanawia się nad tym, walą LocalDateTime.now() i wszystko gra bo u mnie działa. Świadomi programiści tak nie robią. Na początku penetrują API, później zastanawiają się jakie mogą być konsekwencje ich wyborów a następnie podejmują decyzje. Najlepiej takie decyzje, które mogą być odwracalne.

W dzisiejszym artykule:

• API Dawniej i Dziś
• Moment a data wydarzenia
• Dobre zalecenia

API Dawniej i Dziś

Bez zbędnego gadania – API do zarządzania datą przed Javą 8 było słabe – klasy były mutowalne i niebezpieczne dla środowisk wielowątkowych (DateFormat).  Jako, że API zostało zaprojektowane już dawno temu (java.util.Date – JDK 1 / java.util.Calendar – JDK 1.1) i było w użyciu przez wiele lat to jego wady zostały zauważone i podkreślane przez innych. Dzięki temu powstawały rozwiązania poza JDK, które ułatwiały pracę z czasem. Najpopularniejszą biblioteką jaka powstała jest Joda-Time (jeżeli utrzymujesz projekt posiadający wersję Javy niższą niż 8 i potrzebujesz zarządzać czasem, rozważ użycie tej biblioteki).

Tak było kiedyś. Architekci Javy widząc problem i inspirując się API Joda-Time doszli do wniosku, że aktualne rozwiązanie trzeba zaorać. I tak oto powstało nowe API, znajdujące się w JDK w pakiecie java.time. Uwagi projektowe zamieszczone w dokumentacji najlepiej opisują czym kierowali się twórcy projektując nowe API. Z notatek technicznych można wskazać 3 główne cechy nowego API:

1. Niemutowalność – to była zmora dawnego API.
2. Domain Driven Design – tworzone API ma być oparte na zachowaniach domeny – szczególnie istotne jest odróżnienie przypadków biznesowych dla Daty i Czasu.
3. Separacja chronologii – umożliwienie pracy z kalendarzami innymi niż standardowe, np. japoński czy tajski.

Pomimo, że pakiet java.time, może być początkowo dosyć przerażający biorąc pod uwagę ilość klas jakie posiada, to nawet dla osoby z niedużym doświadczeniem nie będzie to ciężkie do ogarnięcia podstawowych przypadków. Podstawowe przypadki to jest jakieś 90% albo i więcej czasu naszej pracy (to już zależy jak trafisz). Do uzupełnienia pozostałych 10% będziesz musiał poczytać dokumentację, doczytać źródła w Internecie i popróbować samemu – nie jest to ciężkie, ale wymaga pracy.

Warto też dodać, że musisz rozumieć czym jest czas. Ale ten punkt powinieneś zrozumieć czytając kolejną sekcję.

A teraz krótki cytat z dokumentacji API:

This can seem like a lot of classes, but most applications can begin with just five date/time types.

• Instant – a timestamp
• LocalDate – a date without a time, or any reference to an offset or time-zone
• LocalTime – a time without a date, or any reference to an offset or time-zone
• LocalDateTime – combines date and time, but still without any offset or time-zone
• ZonedDateTime – a „full” date-time with time-zone and resolved offset from UTC/Greenwich

Instant is the closest equivalent class to java.util.Date. ZonedDateTime is the closest equivalent class to java.util.GregorianCalendar.

Moment a data wydarzenia

Długo miałem problem żeby zrozumieć jaka jest różnica między momentem wydarzenia a datą wydarzenia. Mój mózg nie chciał tego zwizualizować. Jeżeli też masz problem ze zrozumieniem różnicy pomiędzy tym zagadnieniem, to proszę Cię o skupienie się przez najbliższą minutę.

Wyobraź sobie, że są Letnie Igrzyska Olimpijskie. Ludzie z całego świata walczą o jakieś tam tytuły w jednym konkretnym miejscu – akurat najbliższe będą w Tokyo. Inni ludzie – również z całego świata – będą te Igrzyska oglądać w różnych miejscach na świecie. Niech program Igrzysk trwa codziennie, pomiędzy 11 rano a 23 wieczorem czasu lokalnego (Tokyo).

Jestem Polakiem i chcę wiedzieć o której mam włączyć telewizor żeby móc to obejrzeć. Patrzę w reklamy w TV (tak nawiasem, nie oglądam TV) i mówią mi, że program Igrzysk trwa między 4 rano (dla niektórych to jeszcze noc) a 16. I właśnie tym jest moment. Konkretny czas wydarzenia w danym momencie na całej kuli ziemskiej (albo i we wszechświecie).

Kiedy stosować? Jeżeli Twoja aplikacja ma obsługiwać ludzi z całego świata (albo nawet z kilku stref czasowych) i chcesz żeby jakieś wydarzenie (cokolwiek co ma jakąś datę czy czas) było w danym momencie dostępne dla wszystkich o tej samej porze to użyj klas wspierających moment.

A co z datą wydarzenia? Wydaje mi się, że tutaj nie ma aż tak wielkich problemów ze zrozumieniem. Data wydarzenia jest po prostu konkretnym punktem na osi czasu, np. urodziny babci 23 czerwca, start Igrzysk o godzinie 11, piłka z kolegami w piątek o 20. I teraz pytanie – czy jeżeli urodziny babci są 23 czerwca a ja jestem w Tokyo i przypomniałem sobie o nich o godzinie 20 to zdążę jeszcze złożyć życzenia? No i tu znów wchodzi w grę moment.

To czy będziesz wspierał strefę czasową czy nie, zależy od specyfikacji Twojej aplikacji. Warto jednak pamiętać, że nawet jeżeli nie decydujesz się ich wspierać to możesz wpaść w problemy. Większość państw ma coś takiego jak czas letni i czas zimowy, gdzie godzina na zegarku przeskakuje o godzinę w przód lub w tył. Jeżeli chcesz dowiedzieć się więcej na temat problemów w jakie możesz wpaść stosując wyłącznie klasy nie wspierające momentu, obejrzyj to krótkie wideo.

Apropo stref czasowych i dlaczego sam nie powinieneś podejmować się ich implementacji. Polecam świetny 10-minutowy filmik przy którym można się nawet uśmiechnąć The Problem with Time & Timezones – Computerphile.

Dobre zalecenia

Niech ta sekcja będzie częścią wspólnych doświadczeń – jeżeli masz jakąś radę, coś, co widzisz, że jest problematyczne przy zarządzaniu czasem to daj o tym znać w komentarzu. Ja z chęcią zedytuję post i dodam Twoją radę.

Jeden. Modeluj domenę przy użyciu klas LocalDate, LocalTime i LocalDateTime.

Cytat z dokumentacji

Where possible, applications should use LocalDate, LocalTime and LocalDateTime to better model the domain. For example, a birthday should be stored in a code LocalDate. Bear in mind that any use of a time-zone, such as 'Europe/Paris’, adds considerable complexity to a calculation. Many applications can be written only using LocalDate, LocalTime and Instant, with the time-zone added at the user interface (UI) layer.

—

Dwa. Data i czas powinny być wymieniane/przechowywane w formacie UTC. Źródła [1][2]

(Uwaga! Patrz również punkt 4)

Choć na pierwszy rzut oka można sobie pomyśleć, że gryzie się to z punktem pierwszym bo zaraz zaraz… będę używać np. LocalDateTime, który jest czasem lokalnym i jednocześnie czasu UTC? Tak

LocalDateTime nowInUTCTimeWithClock = LocalDateTime.now(Clock.systemUTC());
LocalDateTime nowInUTCTime = LocalDateTime.now(ZoneOffset.UTC);

—

Trzy. Nie polegaj na strefie czasowej serwera!

Unikaj czegoś takiego:

LocalDateTime.now();
LocalDateTime.now(Clock.systemDefaultZone());

Poleganie na domyślnej strefie czasowej może zaskoczyć – pamiętaj, że strefa czasowa serwera jest poza Twoją kontrolą jako programisty. Co jeżeli Twój program będzie hostowany na 2 lub 3 serwerach – każdy w innej strefie czasowej.

Możesz sobie powiedzieć, nie no – wiem, że jest tylko jedna instancja serwera i to w moim mieście. Ok… niech będzie. Ale co jeżeli tą instancją zarządza jakiś admin, któremu nagle przyjdzie do głowy, żeby zmienić strefę czasową na serwerze bo taki miał kapryś tego dnia. (Ignore Server Time Zone)

—

Cztery. UTC nie jest lekiem na wszystko!

Użytkownik Cepewka w komentarzach do tego posta słusznie zauważył że przechowywanie czasu jako UTC nie jest złotym środkiem. Istnieją sytuacje kiedy czas, przechowywany w taki sposób może nie być odpowiedni dla naszego przypadku biznesowego. Nie będę poruszać tych kwestii w tym poście ale chcę żeby każdy czytający był świadomy.

Zachęcam do przeczytania komentarzy użytkownika Cepewka (dzięki za poruszenie tej kwestii!). A jeżeli potrzebujesz więcej informacji to odsyłam do kilku linków:

• STORING UTC IS NOT A SILVER BULLET
• Is it always a good idea to store time in UTC or is this the case where storing in local time is better?
• Is there ever a good reason to store time not in UTC?

Podsumowanie

Zarządzanie czasem wydaje się łatwe ale nie jest proste. Lepiej spędź chwilę na rozmowach z klientem i podrąż temat jaki jest oczekiwany rezultat. Często okaże się, że plany długoterminowe biznesu są większe niż jest to przedstawiane na początku. Twórz takie API, które będzie łatwo przenaszalne pomiędzy różne serwery i na które strefa czasowa serwera nie wpływa. Mówi się, że czas leczy rany, w tym przypadku niekoniecznie . Może się okazać, że z czasem przyjdą zmiany a my będziemy zbierali żniwo naszej wcześniejszej implementacji. Życzę, żeby tak nie było.

Źródła:

• How to get the current date/time in Java
• Working with Time Zones in Java 8 | ZonedDateTime, ZoneId tutorial with examples
• Still using java.util.Date? Don’t!
• MySQL Datetime vs Timestamp column types – which one I should use?

Za tydzień

Porozmawiamy o architekturze warstwowej. Jest to architektura która pozwala na szybkie dostarczanie? A może zmora przez którą nie myślimy o tym co dostarczamy?

Artykuł Czas w Javie ⏱️. Dobrze używasz? pochodzi z serwisu bdabek.pl.