21 października 2011

NIO2 w Java 7 i OCPJP 6 PrepKit od uCertify

NIO2 w Java 7

Na dzisiejszy dzień zaplanowałem recenzję drugiego rozdziału nowej książki z Packt o Java 7. Kiedy jeszcze wczoraj, przed zaśnięciem, przeczytałem JDK 7 Adoption Guide, dzisiejszy rozdział wydał mi się lekko nudny, jakby bez życia. Ciągle ten sam schemat przedstawiania nowości z Java 7 w postaci krótkich przepisów użycia i wałkowanie typów (klasy, enum i interfejs) z pakietu java.nio.file zwanego NIO2:
W całym tym analizowaniu i podsumowywaniu udało mi się wręcz wyłapać błąd w oficjalnym dokumencie od Oracle - we wspomnianym "JDK 7 Adoption Guide" w sekcji IO and NIO, w którym napisano (drugie zdanie):

"The previous mechanism, built around the java.io.File class, is still available, but the new mechanism, built around the java.nio.Path and java.nio.Files classes, offers more robust file I/O and much greater functionality."

Potrafisz znaleźć błąd? Nie?! Odpowiedź jest powyżej (niewprost) oraz na samym końcu tego wpisu.

NIO2 robi wrażenie swoim bogactwem. Przeglądając Java SE 7 API moje oko przyciągnęły poniższe interfejsy:
Aż się chce za nie wszystkie zabrać i skomponować aplikację!

W książce działanie poszczególnych klas prezentuje się z pomocą System.out, np.
Path path = Paths.get("/ścieżka/do/pliku/który/nie/istnieje.txt");
System.out.println("Czy plik istnieje? " + Files.exists(path));  // zwróci false
Bardzo mi się to nie podoba, bo dopiero wynik pokazuje, jaki jest efekt danej metody. Zaproponowałem użycie assert, aby już czytając kod było wiadomo, do czego nim zmierzamy. Powyższy kod mógłby być zaprezentowany tak:
Path path = Paths.get("/ścieżka/do/pliku/który/nie/istnieje.txt");
assert !!!Files.exists(path) : "Plik nie może istnieć";
albo nawet tak:
Path path = Paths.get("/ścieżka/do/pliku/który/nie/istnieje.txt");
assert Files.exists(path) == false : "Plik nie może istnieć";
Które z powyższych odpowiadałoby Twoim gustom? Znasz może ciekawsze podejścia prezentowania wyniku kodu?

OCPJP 6 PrepKit od uCertify

I jakby na życzenie, dostałem propozycję recenzji zestawów do testowania od uCertify:

"In the recent past, uCertify has launched a number of new PrepKits that might be helpful for your readers. I want one more review from you since your review will also help us in improving our products.

Please visit http://www.ucertify.com/download.html for the complete list of PrepKits and let me know the name/code of the PrepKit you would like to review."


Czy powinienem odmówić takiej propozycji?! Nie, co to, to nie! Dlaczegóż nie połączyć przyjemnego z pożytecznym? I tak zabrałem się za 1Z0-851: OCP Java SE 6 Programmer. Niestety, nie jest to zestaw testów ze znajomości Java 7, ale dogłębna znajomość Java 6 nie przeszkadza wcale poznawać nowszych wydań. A może przy okazji, uwierzę w swoje umiejętności i sprawdzę się przy Oracle Certified Professional, Java SE 6 Programmer? Najbardziej zależy mi na utrwaleniu wiedzy z java.util.concurrent. Tutaj zauważam u siebie największe braki.

A skoro o nich, to okazało się, że jest ich znacznie więcej.

Jeszcze przed pójściem do łóżka, zabrałem się za test oceniający mój poziom.


Jak widać na załączonym obrazku, nie najlepiej poszło, tzn. oblałem. Moje ego do tej pory nie może się pozbierać. Jeśli tego byłoby mało, można sprawdzić, w jakim obszarze poszło mi najgorzej. Wystarczy przełączyć widok na Summary report i wszystko jasne.


Tam, gdzie poszukuję największych wzrostów wiedzy, tj. przy java.util.concurrent mam 100%, ale powiedzmy, że 1 pytanie z tej kategorii niewielu powaliłoby. Zaskoczony byłem niemało wynikiem OO Concepts. Teraz jednak potrafię to łatwo wytłumaczyć - po prostu nie wiedziałem, jak odpowiadać na tego typu pytanie, które związane było z przykładami klas, które dziedziczą (relacja "is-a") lub realizują więcej interfejsów (wciąż "is-a"), albo posiadają atrybuty odpowiednich typów (relacja "has-a"). Wychodzi, że umiejętność zdawania testów jest również umiejętnością, której należy się nauczyć. Nauczka na przyszłość.

Test zajął mi 30 minut, co przy 15 pytaniach, również nie należy do chwalebnych osiągnięć. Praktyka, praktyka i jeszcze raz praktyka, panie Jacku! Pora przyjrzeć się, co tam w TomEE piszczy i przygotować przykładzik, który pozwoliłby mi na zapamiętanie tych wszystkich zmian w Java 7.

(uaktualniono po uwadze Marcina Molaka) Do zapamiętania: Pakiet java.nio istnieje, ale w nim nie istnieją typy java.nio.Path oraz java.nio.Files, jak wzmiankuje się w JDK 7 Adoption Guide - IO and NIO.