niedziela, 1 marca 2015

improved exceptions

Tym razem, tematem wziętym pod lupę, będzie łapanie wyjątków, a mianowicie usprawnienia które zostały w tym temacie wprowadzone wraz z nadejściem Javy 7.
Zmiany te nie są jakąś rewolucją, są raczej krokiem ku ewolucji.

Tak więc, pierwszym usprawnieniem jest możliwość łapania więcej niż jednego typu wyjątku w pojedynczym bloku catch.
Prezentuje się to tak: Wcześniej oczywiście, wymagało by to dwóch bloków catch Tak więc, wszystkie typy które zamierzamy łapać, są oddzielone |
Ważne że w momencie w którym nasz blok catch łapie więcej niż jeden typ wyjątku, parametr który jest przekazywany do bloku, zostanie oznaczony jako final, tak więc nie będzie możliwe przypisanie mu innej wartości(nowego obiektu wyjątku) - w przypadku w którym jednak spróbujemy to zrobić, zostaniemy poinformowani że: multi-catch parameter ex may not be assigned


Kolejnym usprawnieniem - w sumie pierwszym, możliwość łapania kilku wyjątków w jednym bloku catch jest raczej nowym ficzerem - tak wiec kolejnym usprawnieniem związanym z wyjątkami, jest możliwość lepszego precyzowania wyjątków które mogą zostać wyrzucone, mianowicie: Widzimy że nasza metoda może wyrzucić Exception, ale tak naprawdę moglibyśmy sprecyzować bardziej, jakie wyjątki zostaną wyrzucone, przecież widać wyraźnie że możliwe są dwie sytuacje: FirstException albo SecondException - Jednak do Javy 7, nie było to możliwe(ponieważ blok catch przyjmuje i wyrzuca Exception), teraz jednak kompilator może faktycznie determinować jakie wyjątki zostaną wyrzucone na podstawie bloku kodu wewnątrz try, tak więc w pełni poprawnym będzie napisanie:
Tak więc miłego łapania wyjątków.

sobota, 14 lutego 2015

Lepiej późno ... niż później.

Jakoś nigdy nie przyglądałem się zmianą wprowadzonym w Javie 7, 8'semka była gwiazdą :) Ale zmiany wprowadzone za pośrednictwem Project Coin były na tyle ciekawe że warto o nich wspomnieć.


Binary Literals.


Od Javy 7 typy integralne(integral types - byte, short, int, i long) mogą być reprezentowane za pomocą liczb binarnych, używając prefixu 0b albo 0B. 
A wcześniej ? wcześniej byliśmy zmuszeni do parsowania, co lubi generować problemy w postaci błędów. Tak więc kiedyś:
teraz: nic specjalnego, jednak Project Coin polega właśnie na dodawaniu takich małych, przyjemnych zmian, co zawsze jest dobre.


try-with-resources


Spring stworzył jdbc-template żeby ułatwić nam pracę z uciążliwym kodem który jest, upierdliwy - pff, wyjątki nam każą jakieś łapać...

Podobnie jest w przypadku ulepszonej konstrukcji try - umawiamy się, że implementując interface java.lang.AutoCloseable( java.io.Closeable implementuje AutoCloseable) pozwalamy javie na zamknięcia jakiegoś obiektu(wywołania na nim .close()). Ale do rzeczy, napiszmy skomplikowany program który podejmie się zadania ... odczytania pierwszej linii z pliku.
Po staremu(a raczej, normalnie): Teoretycznie wszystko fajnie, jednak ten blok finally i if uwiera trochę.
Po napisaniu tego kawałka kodu, sprawdziliśmy w dokumentacji co tam sobie BufferedReader implementuje - okazuje się że implementuje ów magiczny interface Closeable, tak więc możemy skorzystać z try-with-resources (resource'em jest tutaj obiekt na którym operujemy).
Więc po nowemu i lepszemu: W tym przypadku, kiedy coś pójdzie nie tak, metoda close() zostanie wywołana automatycznie. Dodatkowo, jeżeli deklarujemy więcej obiektów w taki sposób jak wyżej, kolejność zamykania tych obiektów jest zgodna z kolejnością ich tworzenia.

Przyjrzyjmy się jeszcze jednemu przykładowi: Tworzymy obiekt klasy ObjectInputStream, a ten przyjmuje w konstruktorze obiekt klasy FileInputStream - załóżmy że plik nie zostanie poprawnie otworzony, ObjectInputStream nie zostanie skonstruowany więc FileInputStream nie zostanie zamknięty. Tak, trochę naciągane, ale nie ja to wymyśliłem (odsyłam tutaj). W takim razie jak może być lepiej ? pozwólmy tym obiektom stworzyć się osobno:

 

switch i Stringi.


A więc, nadszedł ten dzień, w którym java.lang.String może pojawiać się w wyrażeniach konstrukcji switch. Obiekty te porównywane są przy pomocy metody .equals(), dodatkowo bytecode który jest generowany za pomocą tej konstrukcji(switcha) jest generalnie wydajniejszy niż w przypadku łańcuszka if'ów i else'ów, tak więc, używajmy :)

Przykładzik:

wszystko ?


nie, nie wszystko, cała lista nowych rzeczy, znajduje się tutaj. Kilka z nich to np: informacja o to tym że jakaś klasa zaimplementowała interface AutoCloseable i pozwala na autoclosa(w przypadku JDBC). Są też jeszcze dwie rzeczy o których jeszcze coś się pojawi, mianowicie:
- poprawione łapanie wyjątków.
- ulepszone API odpowiadające za obsługę plików (NIO.2)

piątek, 3 października 2014

JPA w Spring

Dla Hibernate głównym interfacem na którym wywołujemy np: metodę getCurrentSession() jest interface Session, dla JPA jest to EntityManager."Odpowiednikiem" Hibernatowego SessionFactory jest EntityManagerFactory. W Springu, są dostępne dwie fabryki dla EntityManager'a:   

  •    LocalContainerEntityManagerFactoryBean
  •    LocalEntityManagerFactoryBean

Czym się różnią ? różnią się bebechami, mianowicie tym jak EntityManager jest tworzony, pierwszy zwraca EntityManagera który jest zarządzany przez kontener aplikacji, drugi zaś - zwraca EntityManagera który jest zarządzany przez aplikacje. Dla nas jednak - to co dzieje się pod spodem, jest totalnie bez znaczenia.

Skonfigurujmy sobie obie fabryki: 

LocalEntityManager:

Czym jest persistenceUnitName ? jest nazwą persistence unit(nie wiem jak to po polsku można przetłumaczyć) który znajduje się w persistence descriptorze(w folderze META-INF), o co chodzi z tym całym plikiem, można dowiedzieć się np: tutaj Jeżeli nie chce nam się bawić w tworzenie descriptora, zainteresuj się czytelniku drugim sposobem pobierania EntityManager'a.

LocalContainerEntityManager

Tutaj, EntityManagerFactory jest tworzony używając informacji zapewnionych przez kontener, w naszym przypadku jest to Spring, dzięki temu wszystkie informacje mogą być zawarte w contexcie aplikacji(application-context.xml).
Oto i nasz LocalContainerEntityManagerFactoryBean: oraz JpaVendorAdapter: Jeżeli Spring zaatakuje Was błędami w stylu: Failed to determine Hibernate PersistenceProvider należy dodać do pom.xml, zależność dla:

Hibernate w Spring'u

Hibernate

Głównym interfacem który pozwala nam na komunikacje między Hibernatem i Javą jest hibernatowy Session- udostępnia nam np: takie metody jak save(), get(), flush() . Także pierwszą rzeczą którą będziemy musieli zrobić to pobranie referencji do obiektu org.hibernate.session - Dostaniemy ją prosząc o to hibernatowy interface SessionFactory - a ten ostatecznie zdobędziemy poprzez jedną z springowych fabryk.

Dla Spring 3 - będą to np:

 - AnnotationSessionFactoryBean
 - LocalSessionFactoryBean

Główna różnicą między tymi fabrykami jest fakt, że AnnotationSessionFactoryBean przyjmuje parametr "packagesToScan" któremu podajemy(jak nazwa wskazuje) package z naszymi Encjami - oznaczonymi przy pomocy adnotacji(@Entity) - wszystkie te encje zostaną zeskanowane :)  LocalSessionFactoryBean przyjmie po prostu mappingResources z wypisanymi klasami.

Prosta konfiguracja bean'a LocalSessionFactoryBean
Oraz prosta konfiguracja dla AnnotationSessionFactoryBean

No i oczywiście, potrzebujemy jeszcze referencji do jakiegoś dataSource, może to być np: BasicDataSource od apacha, do pom.xml wystarczy dodać dependency dla: oraz dataSource:

Dla Spring 4:

W spring4 sprawa jest trochę postrza - podczas tworzenia LocalSessionFactoryBean możemy podać ... packagesToScan. Reszta jest analogiczna.

poniedziałek, 29 września 2014

print("Hello Spring Framework")

Uruchomiłem sobie repo na Github'ie na którym znajdują się proste przykłady niektórych Springowych ficzerów - robiłem to raczej z myślą o sobie, jednak gdyby ktoś chciał zobaczyć jak szybko coś skonfigurować(np: proste AOP) to zapraszam SpringShowCase

Jeżeli chciałbyś dodać coś od siebie, zrób forka i strzelaj pull-requestami :)


Cheers :)

wtorek, 7 stycznia 2014

Android Services[na javastart.pl]

Zapraszam do przeczytania kolejnego artykułu na temat Androida, tym razem przyjrzymy się bardzo wartościowemu komponentowi tego systemu jakim jest serwis.
Więcej o tym tutaj: javastart.pl

Pobieranie elementu listy w Java Server Faces

W pewnym sensie, ten post to raczej notatka, aczkolwiek może się komuś kiedyś przydać, więc postanowiłem opublikować :)
Problem był dość trywialny, jednak na początku przygód z nowymi technologiami to chyba one najbardziej dają się we znaki.
Do rzeczy, mamy managed bean'a oraz widok jako facelets, w bean'ie mam prostą liste natomiast z faceletu zamierzam wyświetlić np: pierw element tej listy. pytanie jak ? normalnie :)  Więc mój bean: mój facelet: