ant - blog

Funkcje rekurencyjne to funkcje, które wywołują same siebie. Nie są one szczególnie popularne w Javie, za to stanowią bardzo ważny element języków funkcyjnych, takich jak Scala czy Clojure. W wielu językach funkcyjnych nie ma wręcz nawet zwykłej pętli for czy while, tylko trzeba korzystać właśnie z rekurencji. W tym artykule zobaczymy jakie konsekwencje ma stosowanie funkcji rekurencyjnych w kodzie Javy i Scali.

Dobiegła końca nasza mini-ankietka pt. "Z której nowej konstrukcji w Javie 7 cieszysz się najbardziej?". Jej wyniki są po części, przynajmniej dla mnie, dość zaskakujące. Mniej więcej tyle samo osób uważa, że wszystkie zmiany wprowadzone w Javie 7 są żenujące, co że wszystkie są pozytywne. Faktem jest, że Java 7 w warstwie językowej to zaledwie trochę lukru składniowego. Przyjemnego, pomocnego, ale nie jest to żadna fundamentalna zmiana na miarę np. domknięć, modułów czy funkcji. Czyżby 1/4 biorących udział w głosowaniu oddając głos na "żenującą" opcję zamanifestowała w tej sposób chęć wprowadzenia do Javy bardziej radykalnych zmian? Jeśli tak to jakich?

Gdyby nowości w Javie 7 ograniczyły się jedynie do drobnych zmian w składni języka czułbym się zawiedziony. Na szczęście jest w siódemce więcej rzeczy, które cieszą. Do takich należą m.in. zmiany i optymalizacje w samej maszynie wirtualnej. Są one o tyle istotnie, że ich beneficjentami nie jest tylko Java, ale też wszystkie inne języki, które kompilują się do bytecode'u (Scala, Clojure, Gosu, Fantom, Groovy, JRuby, Jython, nadchodzące Kotlin i Ceylon i wiele innych, które ciężko już nawet spamiętać). Zobaczmy, co nowego kryje się w HotSpocie.

Pewnie wielu z was uzna, że to odgrzewany kotlet, ale dopiero dzisiaj trafiłem na prezentację sprzed lat: Advanced Topics in Programming Languages: Java Puzzlers. Wciągnęła mnie bardzo - lubię takie łamigłówki! Niestety muszę przyznać, że dałem się podejść jak dziecko! Na osiem zagadek, tylko w trzech przypadkach udzieliłem poprawnej odpowiedzi, w jednym przypadku poprawnie zidentyfikowałem problem, ale i tak udzieliłem złej odpowiedzi sugerując się jakimś nieważnym szczegółem. W czterech przypadkach szczęka mi opadała coraz niżej...

Kończąc cykl (cz. 1, cz. 2) o implementacji try-with-resources w Scali przedstawię uogólnioną wersję funkcji withResources obługującą dowolną (prawie) liczbę zasobów. Niestety nie jest ona szczególnie piękna składniowo i raczej bym jej nie polecał do ogólnego stosowania, ponieważ zawiera element, który trzeba duplikować przy każdym jej użyciu (ang. boilerplate code), czego do tej pory starałem się unikać - skutecznie. Poniższą implementację traktuję raczej jako akademickie rozważanie, bo i tak w praktyce (przynajmniej mojej) rzadko spotkałem się z potrzebą otwierania więcej niż 2 zasobów na raz. Do rzeczy.

W poprzednim odcinku przedstawiłem prostą implementację konstrukcji try-with-resouce w Scali. Umożliwiała ona automatyczne zamykanie tylko jednego zasobu na raz, co oczywiście sprawia, że jej zastosowanie jest ograniczone tylko do prostych przypadków. W części drugiej tej, jak by na to nie spojrzeć "Trylogii o try-resource w Scali", przedstawię implementację obsługującą dwa zasoby. Można to było zrobić na kilka sposobów, ostatecznie po kilku próbach skończyło się na rozwiązaniu koncepcyjnie najprostszym, żeby nie powiedzieć prymitywnym, czyli zapisaniu wprost dwóch zagnieżdzonych bloków try/catch/finally. Tak, mało to spektakularne, ale efekt jest zadowalający.

Jedną z nowości w Javie 7 jest podrasowana konstrukcja try/catch umożliwiająca automatyczne zamykanie zasobów, o ile tylko implementują nowy interfejs AutoCloseable i zostały zadeklarowane w nawiasie tuż po słowie kluczowym try. Pozwala to w nakomitej ilości przypadków wyeliminować bloki finally sprowadzające się tylko do wywoływania metody close() na otwartych zasobach. Kod napisany z użyciem try-with-resource jest z prostszy i pozostawia mało miejsca na popełnianie błędów związanych z wyciekającymi zasobami. Jednym słowiem - miodzio! Mnie natomiast zainteresowało, jak można by zaimplementować taką funkcjonalność w Scali. Sprawa wydawała się prosta, ale muszę przyznać, że dość długo zajęło mi opracowanie wersji, która w miarę mnie satysfakcjonuje.

Kolekcje w bibliotece standardowej Scali można podzielić z grubsza na dwie grupy: modyfikowalne (ang. mutable) i niezmienne (ang. immutable). Modyfikowalne to takie, których stan można dowolnie zmieniać, a niezmienne to takie, które raz utworzone zawsze mają dokładnie taką samą zawartość. Główną zaletą kolekcji niezmiennych jest to, że można ich używać w środowisku wielowątkowym bez żadnej synchronizacji (służą tylko do odczytu). Główną ich wadą natomiast jest to, że nie jest tak łatwo je aktualizować (aktualizacja polega na utworzeniu nowej kolekcji, która zawiera starą kolekcję powiększoną/pomniejszoną o dodatkowe/zbędne elementy). Wady tej nie mają kolekcje modyfikowalne, no ale nie mają też wspomnianej zalety dotyczącej wielowątkowości. Postanowiłem sprawdzić, jaki jest koszt niezmienności.

Zapraszam do obejrzenia mojego kolejnego screencastu, tym razem poświęconego nie tyle IDE, co platformie Eclipse RCP. Jest to pierwszy odcinek z serii The Eclipse RCP Quickies, w której będę przedstawiał różne ciekawe (moim zdaniem) aspekty tegoż narzędzia. Pierwszy odcinek dotyczy tworzenia niestandardowego układu perspektyw. Zapraszam do oglądania!

Screencast trwa 8 minut (14MB) - wymaga QuickTime.

Po wtorkowym spotkaniu warszawskiego JUGu ucięliśmy sobie z Michałem i Jackiem krótką pogawędkę, w trakcie której doszliśmy do wniosku, że przydałby się plugin do Eclipse, który umożliwiałby łatwe dzielenie się szablonami kodu w naszym IDE. W krótkim czasie powstała pierwsza testowa implementacja takiego dodatku. Krótkie demo można zobaczyć klikając w poniższy obrazek:

W piątek zakończyła się kolejna edycja konferencji DEVOXX, największego bodaj europejskiego wydarzenia w świecie Javy. Ja tam byłem, w sesjach uczestniczyłem, belgijskie piwo piłem i takie oto obserwacje poczyniłem...

Dzień pierwszy

Keynotes

Pierwsze plenarne spotkanie (bite dwie sale kinowe po 900 osób każda), dotyczyło spraw ogólnych - Javy jako takiej i wyzwań przed nią stojących, Javy EE w wersji 6 i Glassfish v3 oraz nowych narzędzi firmy Adobe związanych z platformą Flex.

Od jakiegoś czasu zastanawiam się nad problemem zarządzania wdrożeniami i utrzymaniem dużych systemów, nazwijmy je WebDwaZerowymi. Chodzi mi konkretnie o rozproszoną architekturę serwisową, w której na cały system składa się kilkanaście i więcej komponentów uruchamianych na kilkudziesięciu i więcej serwerach (nie wspominając już o takich kolosach jak np. flickr, facebook czy nasza-klasa, gdzie liczby maszyn liczy się w setkach, tysiącach i więcej).

Całkiem niedawno mój kolega Piotr Czajkowski wpadł na pomysł stworzenia ciekawego rozszerzenia wyszukiwarki Allegro. Polega on na tym, aby możliwe było wpisanie dwóch przedmiotów i wyszukanie takich sprzedawców, którzy w swojej ofercie mają obydwa (czyli można zaoszczędzić na kosztach przesyłki). Ponieważ pomysł mi się spodobał zaimplementowałem coś takiego (alleszukacz.pl) w oparciu o Allegro WebAPI przy użyciu Jetty, Axisa, Spring Framework i JavaScriptu.

W trakcie tworzenia aplikacji opartej na platformie Eclipse RCP uznałem, że dobrze by było skorzystać z biblioteki Joda Time (dla niewtajemniczonych: jest to biblioteka, która zastępuje, poprawia i uzupełnia możliwości klas Date, Calendar i pokrewnych). Postępując zgodnie z duchem OSGi chciałem dołączyć ją jako osobny plugin do mojej platformy uruchomieniowej. Długo się nie zastanawiając udałem sie na stronę OSGi Bundle Repository i zapolowałem na interesującą mnie wersję.