Pytania w tym artykule pojawiły się podczas szkolenia Programowanie w języku Java realizowanego w dniach 29.08-02.09.2016r.
Patryk Czarnik
SENIOR JAVA DEVELOPER AND TRAINER
W naszej pracy mamy do czynienia z projektami w starszych wersjach Javy. Jakie są ograniczenia w Javie 1.6??
„W Javie 6 najbardziej dokuczliwy może być brak konstrukcji „try with resources”, czyli eleganckiego sposobu na skuteczne zamykanie plików i innych zasobów. Do Javy 6 porządne zamykanie plików, połączeń itp. wymagało użycia bloku finally i dosyć skomplikowanego zapisu, który prezentuję też na szkoleniu. Oczywiście w każdej wersji Javy pojawiały się nowe rzeczy w bibliotece („Java API”). W Javie 6 było to m.in. wsparcie dla webserwisów i niektóre technologie XML-owe, w Javie 7 dużą nowością było java.nio.file ułatwiające korzystanie z plików dyskowych. Java 8 wprowadza całą tę „funkcyjność”, ale to już dużo poważniejsza zmiana.”
A Java 1.4??
„W Javie 1.4 przede wszystkim zupełnie inaczej korzysta się z kolekcji. Nie ma mechanizmu „genericów”, a więc kolekcje mogą zawierać dowolne obiekty i sami musimy pilnować tego, czy umieszczamy w nich obiekty właściwych klas. Przy pobieraniu z kolekcji konieczne jest rzutowanie. W JAvie 1.4 nie ma też pętli for-each i dla tablic trzeba używać tradycyjnej pętli z licznikiem, a dla kolekcji – trzeba używać iteratorów: Iterator it = kolekcja.iterator(); while(it.hasNext()) { …”
Czy jest jeszcze sens używać JDBC skoro jest Hibernate / JPA?
„Odpowiedź subiektywna: nie jestem wielkim miłośnikiem nakładek i „”frejmłorków””, chociaż szczerze doceniam fakt, że Hibernate/JPA to naprawdę zaawansowana maszyneria, dzięki której można sprawniej tworzyć projekty; ma i inne zalety jak choćby niezależność od rodzaju bazy danych. Jednak zazwyczaj wolę widzieć co się dzieje w aplikacji, dlaczego działa, dlaczego nie działa.
Odpowiedź obiektywna: są sytuacje, gdy świadomie chcemy skorzystać z zaawansowanej możliwości konkretnej bazy danych (np. Oracla, który ma swoje rozszerzenia w temacie agregacji), której nie wspiera ogólny z założenia JPQL; chcemy mieć pełną kontrolę nad połączeniem i zmieniać jego ustawienia w trakcie sesji… w tego typu sytuacjach bezpośredni dostęp po JDBC może okazać się niezbędny.
Ostrzegam też, że naiwne korzystanie z możliwości JPA może prowadzić do pisania nieefektywnych aplikacji. Nie chodzi mi o to, że JPA jest niewydajne, bo narzut jest niewielki, tylko o to, że leniwy programista może użyć go niewłaściwie i np. zamiast filtrować bądź grupować po stronie bazy danych, wczyta wszystkie dane do pamięci Javy i dopiero będzie je przetwarzał – tak się nie robi!”
