Pytania w tym artykule pojawiły się podczas szkolenia Programowanie w języku Java realizowanego w dniach 29.08-02.09.2016r.
SENIOR JAVA DEVELOPER AND TRAINER
"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."
"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()) { ..."
"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!"
