Programowanie asynchroniczne - zupełnie nowa era

Programowanie asynchroniczne nie jest przyjemne. Każdy to wie. Nie dlatego że jest trudne bo można się wszystkiego nauczyć ale dlatego że kod jest nieczytelny jeżeli scenariusz wykracza poza 'Hello world'. Sam spędziłem lata pisząc rozwiązania bazowane na platformie Eclipse i moim najlepszym przyjacielem było 'asyncExec'. Jednak nawet pomimo tak przydatnych funkcji całość jest zwyczajnie nieczytelna. Pojawiło się jednak światło w tunelu - automatyczne przekształcanie kodu synchronicznego w asynchroniczny poprzez adnotacje dla kompilatora. Niestety nie jest to mechanizm dostępny w Javie ale i tak warto prezentację zobaczyć. To przyszłość każdego języka :)

Klasyczny program pisany jest imperatywnie. Komenda za komendą. Całość wywołuje się synchronicznie za pomocą jednego wątku. Jeżeli chcemy część pracy przekazać do innego wątku to musimy to jawnie napisać (stworzyć klasę anonimową np. Runnable, wywołać 'asyncExec' itp). Taki kod jednak szybko przestaje być czytelny. Trudno sobie wyobrazić czytelny kod z kilkoma zagnieżdżeniami. Nie wspominając już o obsłudze wyjątków czy wywołań zwrotnych itp. Szybko robi się z tego spagetti. Logika biznesowa w takim kodzie schodzi na plan dalszy a główne skrzypce gra tutaj aspekt techniczny kodu.

Czy to jedyna metoda? Wygląda na to że nie. Półtorej roku temu oglądałem materiały z PDC 2010 podczas których zapowiedziano iż MS pracuje nad wprowadzeniem obsługi asynchroniczności do jęzka C#. Temat wydał mi się diabelnie ciekawy ale zapomniałem o nim napisać. Wczoraj oglądając materiały z konferencji BUILD trafiłem na prezentację wersji finalnej która stała się podstawą nowego API Windows 8 (RuntimeRT).

O co chodzi? O to by programista mógł pisać zwyczajny kod wyglądający na synchroniczny ale kompilator potrafił przekształcić go w kod asynchroniczny bazowany na wywołaniach callback. Wygląda to niewiarygodnie. Można napisać metodę mającą 100 linii z czego np. 10 wywołań będzie wywołaniami asynchronicznymi. Kompilator rozbije taką metodą na serię metod zwrotnych. Nawet więcej można oznaczyć jakąś iterację że ma się wywołać równolegle a kolejna linijka kodu wykona się dopiero gdy przetworzone zostaną wszystkie elementy kolekcji. Całość sterowana dwoma prostymi słowami kluczowymi 'async' oraz 'await' umieszczanymi przy wywołaniu. To jest przyszłość jaką chciałbym kiedyś zobaczyć także w Javie.

Prezentację można zobaczyć na poniższym wideo. Poza wywołaniami asynchronicznymi architekt prezentuje jeszcze kilka innych ciekawych rozwiązań (np. pisanie programów które wywołują kompilator dodając nowe metody "w locie" które następnie ten kod wywołuje itp.). Całość jest imponująca



Mam nadzieję że Oracle znajdzie szybko porozumienie z Google i OpenJDK stanie się wspólną maszyną Javy wspieraną przez wszystkich producentów. Tak by język po kilku latach stagnacji znów rozwijał się tak szybko jak jeszcze 5 lat temu. Współpraca nad jedną wspólną maszyną wirtualną to konieczność by składnia języka dogoniła najnowsze trendy. Transformacja asynchroniczna w C# pokazuje że jeszcze sporo można zrobić na poziomie języka.

Prezentacja OSGi w JEE we Wrocławiu [Wrocław JUG]

Właśnie przeczytałem że jutro na Politechnice Wrocławskiej odbędzie się prezentacja "OSGI + J2EE". Została ona zorganizowana przez zespół R&D Eurobanku. Myślę że warto się na taką prezentację wybrać. W rozwinięciu przekleiłem informację ze strony JUG’a

--------------
Program prezentacji:
- Case study: System informatyczny z dużą liczbą rozwijanych jednocześnie obszarów
- Analiza potrzeby modularyzacji systemów informatycznych
- Przegląd i porównanie dostępnych technik modularyzacji w środowisku Java EE
- Wprowadzenie w kluczowe koncepcje OSGi
- Propozycja modelowej architektury łączącej zalety Java EE i OSGi
- Prezentacja praktycznego działania i architektury wielomodułowej platformy webowej

Politechnika Wrocławska (budynek B4)
Łukasiewicza 5
Sala 448

Zapisać można się poprzez stronę Wrocław JUG
--------------


Przy okazji jeżeli ktoś interesuje się tematem zachęcam do lektury książki "OSGi and Equinox". Czytałem ją rok temu i sporo mi wyjaśniła. Przy okazji jeżeli ktoś ma problemy z widocznoscią pakietów w trakcie integracji modułów to tutaj można znaleźć "niekonwencjonalne rozwiązanie":

http://deepdiveinto.blogspot.com/2010/06/jak-wamac-sie-do-obcego-bundla-w-osgi.html

Eclipse Demo Camp 2010 - Poznań

Niestety w tym roku nie udało mi się zorganizować trzeciej wrocławskiej edycji Eclipse Demo Camp. Do tej pory spotkania organizowałem dzięki pomocy firmy Sygnity. Firma jednak jakiś czas temu zakończyła rozwój projektów eclipsowych. Nie udało mi się znaleźć nowego sponsora więc tym razem trzeba było ze spotkania zrezygnować. Każdemu jednak kto czekał na wrocławską edycję polecam jutrzejsze spotkanie w Poznaniu!

Poznańska edycja Eclipse Demo Camp jest najstarsza w Polsce. Spotkania odbywają się dwa razy w roku od co najmniej 4 lat. Tym razem spotkanie odbędzie się w pubie Johnny Rocker. Spotkanie organizują w trójkę Natalia Klimasz i Krzysztof Daniel z IBM Eclipse Support Center oraz Adam Dudczak z Poznańskiej grupy JUG (Java User Group).

Plan spotkania wygląda następująco:
13.15 - Krzysztof Kaźmierczyk, IBM ESC, How to easy find Java memory problems using Eclipse using Memory Analyzing Tool
13.45 - Jacek Pospychala, Zend, Testowanie GUI w aplikacjach Eclipse RCP
14.15 - Krzysztof Daniel, IBM ESC, Server-Side Eclipse what it can do for you?
15.00 - Anna Ferster, Marek Kuzora & Filip Wiśniewski,Students PUT, Moduł rozszerzonych preferencji do Eclipse RCP
15.30 - Małgorzata Janczarska, IBM, Building web application on top of Eclipse
16.00 - Tomasz Zarna, IBM, Eclipse 3.7 Tips and tricks

Każdego zainteresowanego rozwojem środowiska Eclipse zapraszam w imieniu organizatorów. To będzie rewelacyjne spotkanie!

Wszystkie ważne informacje można znaleźć na oficjalnej stronie WIKI:
http://wiki.eclipse.org/Eclipse_DemoCamps_November_2010/Poznan

Jeżeli ktoś ma konto w serwisie Facebook można także dodać się do specjalnie utworzonego wydarzenia (dzięki temu wasi znajomi dowiedzą się o spotkaniu EDC Poznań). Nie jest to jednak równoznaczne z rejestracją. To tylko taki opcjonalny dodatek w ramach grupy 'eclipse.polska'

http://www.facebook.com/event.php?eid=155588817818747


Miałem okazję być na kilku wcześniejszych poznańskich spotkaniach i zawsze było rewelacyjnie (raz była nawet mata do Dance Dance Revolution!). Zawsze starałem się tak zaplanować swoje delegacje do poznańskiego oddziału PB Polsoft by po pracy móc być także na EDC (spotkania były wieczorami w ciągu tygodnia więc można było na nie jechać tylko z pracy). Żałuję że niestety nie będę mógł tym razem przyjechać (anulowałem więc prezentację XText). Mam nadzieję że następnym razem uda mi się lepiej zaplanować swój czas tak by nie kolidowały mi dwie ważne sprawy.

Mam także nadzieję że uda mi się zorganizować trzecie wrocławskie EDC w czerwcu. Wszystko jednak zależy od tego czy znajdzie się jakaś firma rozwijająca projekty w technologiach eclipsowych która chciałaby całość sponsorować. Biorąc pod uwagę że coraz więcej firm stara się wejść w technologię EclipseEquinox/OSGI to mam nadzieję że uda się coś znaleźć. W końcu takie spotkania to idealny sposób by znaleźć pracowników znających od lat OSGI w praktyce - to możliwe tylko w EclipseRCP :)

Narzędzia z Instantiations dostępne za darmo

Instantiations to jedna z legend świata Eclipse. Przez lata zajmowali się doskonaleniem swojego pakietu narzędzi do wizualnego tworzenia formularzy w SWT/Swing/GWT. Dzięki jakości swoich produktów firma potrafiła przez lata utrzymać się na trudnym rynku zdominowanym przez darmowe alternatywy (kiepski VisualEditor oraz dobry Netbeans Matisse). Miesiąc temu firma została przejęta przez Google. Głównym celem był edytor GWT.

Osobiście nigdy nie miałem okazji by coś poważniejszego zaprogramować z użyciem pakietu Instantiations. GUI które budowaliśmy było zbyt złożone by można było je "wyklikać" i jednoczenie nie było go za dużo. Budowanie narzędzi deweloperskich znacznie różni się od budowania aplikacji z milionem względnie prostych i przewidywalnych formularzy. Jednak jedna funkcja bardzo mnie interesowała. Mianowicie możliwość tworzenia skryptów na potrzeby regresji GUI. Szczególnie kusiło mnie nagrywanie edytorów graficznych opartych na GEF/GMF.

Oprogramowanie testów regresji dla edytora graficznego jest niezmiernie trudne. Trudno tu polegać na samych testach jednostkowych gdy 95% kodu jest wygenerowana automatycznie i zawiera dosyć zagmatwaną logikę. Nie ma co ukrywać ale kod generowany przez GMF nie należy do najprzyjemniejszych i z czasem przekształca się w bliżej nieokreśloną masę wymieszanych metod własnych i automatycznych. Utrzymanie całości graniczy z cudem szczególnie gdy robi się coś nie do końca standardowego (jak przykładowo rozbicie edytora na na kilka współpracujących/opcjonalnych modułów OSGi).

Niestety nigdy nie znalazłem czasu na dokładne testy tych narzędzi. Także cena była zaporowa. Nadzieją okazał się otwarty projekt SWTBot który pojawił się jakieś dwa lata temu. Przyznam że bardzo mi się spodobał ze względu na swoją prostotę jednak brak w nim było obsługi edytorów graficznych (dodane zostały raptem kilka miesięcy temu w wersji 'alpha').

Być może jednak warto wrócić do tematu. Dziś Google ogłosiło na swoim blogu że pełny pakiet narzędzi zostaje udostępniony całkowicie za darmo :)

GWT Designer
Zestaw narzędzi dla GWT

CodePro AnalytiX
Zautomatyzowany system analizy kodu

WindowBuilder Pro
Narzędzia do budowania GUI w SWT/Swing/XWT/GWT

WindowTester Pro
Testy regresji w GUI



Co cieszy zapowiedziano także mocną integrację z wcześniejszymi pluginami Google. Możliwe więc że za kilka miesięcy pojawi się naprawdę dopracowany zestaw narzędzi do pracy z GWT. Bez wątpienia zwiększy to jeszcze bardziej popularność tej technologii. Więcej informacji można znaleźć na blogu Google GWT

Prezentacja Eclipse Virgo (SpringSource dmServer)

Dziś o godzinie 17.00 odbędzie się prezentacja projektu Eclipse Virgo (dawniej znanego jako SpringSource dmServer). Prezentację poprowadzą jego liderzy: Glyn Normington oraz Steve Powell. Prezentacja odbędzie się na platformie Eclipse Live więc każdy będzie mógł uzyskać odpowiedzi na własne pytania.

Rejestracja możliwa jest pod tym adresem:
http://live.eclipse.org/node/937

Więcej informacji o projekcie Eclipse Virgo możecie znaleźć na stronie projektu:
http://www.eclipse.org/virgo/

Jako programista środowiska Eclipse od wielu lat mam możliwość pracy w środowisku OSGi. Nic tak nie porządkuje kodu jak przemyślana modularyzacja z wymuszonymi jednokierunkowymi zależnościami pomiędzy modułami + usługi/rozszerzenia. Bez wątpienia jestem wielkim fanem tej technologi :) Dlatego bardzo cieszy mnie jej ekspansja także na platformę JEE/J2EE. Mam nadzieję że znajdę trochę czasu by wrzucić na bloga jakiś dłuższy wpis o usługach, modularyzacji i tematach pokrewnych. Jak w każdej technologii także w OSGi jest kilka kruczków które dobrze znać (np. upublicznić pakiet prywatny z zewnętrznej biblioteki)

Jeżeli ktoś z was jest zainteresowany powiadomieniami o kolejnych prezentacjach, wykładach, spotkaniach zapraszamy do oficjalnej grupy 'Eclipse Polska na Facebooku'



---------------------------------
Aktualizacja
Link do nagranej prezentacji:



[OSLO] Quadrant idzie w odstawkę

Jakieś półtorej roku temu pisałem na blogu o projekcie Oslo. Rewelacyjnie zapowiadających się narzędziach do tworzenia języków specyficznych dla problemu. Projekt składał się z kilku elementów. Narzędzi do definicji modelu języka i jego testów w czasie rzeczywistym, bazy danych przechowującej instancje modeli zgodne z gramatyką oraz edytor Quadrant.

Pierwszy element w bezpośredni sposób odpowiadał funkcjonalności projektu xText który mnie osobiście od dawna pasjonuje. Byłem pod wielkim wrażeniem faktu iż całość pracowała w czasie rzeczywistym. W jednym edytorze można było definiować/modyfikować model gramatyki i w tym samym czasie go testować na przykładowych danych. W przypadku projektu xText na dzień dzisiejszy wciąż konieczna jest generacja kodu i uruchomienie kolejnej instancji Eclipse. Oczywiście możliwe byłoby rozszerzenie środowiska xText w taki sposób by całość nie wymagała restartu poprzez wykorzystanie dynamiki mechanizmów OSGi/Equinox, jednak aktualnie nie jest to zaimplementowane (budowałem tego typu mechanizmy i nie jest to takie trudne jak się wydaje :)

Drugim elementem była baza instancji. Mniej więcej odpowiadała ona środowisku Eclipse CDO.

Trzeci element 'Quadrant' był dla mnie jednak niezrozumiały. Był to edytor który w sposób graficzny pozwalał budować i łączyć zapytania do bazy instancji. Przyznam że nie do końca potrafiłem sobie wyobrazić jego produkcyjne zastosowanie. Z doświadczenia wiem że jeżeli ktoś chce dostarczyć narzędzia dla osób o profilu 'nieinformatycznym' (jak np. analityk o profilu 'telekomunikacja' a nie 'informatyka') to narzędzia te MUSZĄ BYĆ PROSTE. Domena rozwiązywanego problemu musi zostać tak okrojona/dopasowana by możliwe było stworzenie naprawdę prostych narzędzi operujących w zadanej (zrozumiałej) przestrzeni. Po ci więc Microsoft tworzył uniwersalny edytor zapytań?

Quadrant nie był prosty. Wyglądał na narzędzie do obsługi którego konieczne będzie specjalistyczne przeszkolenie, a nawet znajomość modelu gramatyki. Trudno mi sobie wyobrazić by klient operujący w narzędziach schodził na poziom modelu który często jest nie do końca zrozumiały nawet dla osób z IT o odmiennej specjalizacji. Sam model także nie ma wartości sam w sobie. To tylko zapis wiedzy którą dopiero później należy zinterpretować w coś wartościowego dla klienta (generacja lub silnik interpretujący)

Dodatkowo całość kojarzyła mi się trochę z filmem 'Raport mniejszości'. Specyfika graficzna edytora powodowała że ewentualny zapytanie zbudowane w ten sposób musiałoby być wyświetlane na ekranie wielkości ściany lub przynajmniej 50 cali. Całkowicie niezrozumiały element.

Parę miesięcy później pojawiła się informacja o zdefiniowaniu przeznaczenia projektu Oslo. Został on przypisany jako element oferty bazodanowej. To było spore zaskoczenie. Trochę szkoda ponieważ edytor oraz baza mogły mieć zdecydowanie szersze pole działania podobnie jak xText. Wyjaśniało jednak istnienie złożonego modułu do budowy zapytań. Przyznam że po tym ustaleniu kierunku dalszego rozwoju straciłem zainteresowanie tematyką OSLO.

Dziś natrafiłem na informację o zakończeniu prac nad modułem 'Quadrant'. Pozostałe elementy pozostają bez zmian. Niestety dalej całość targetowana jest tylko na bazy danych. Szkoda. Gdyby Microsoft pracował bardziej na kształt Eclipse Community bez wątpienia projekt Oslo mógłby więcej zmienić w tematyce DSL. Ich zespół mógłby dalej pracować nad rozszerzeniem projektu dla baz danych jednak zakładam że sporo osób z zewnątrz wykorzystywałoby go inaczej. Jako podstawę rozwiązań DSL jak dziś się to robi z EMF/xText.

Otwartość na deweloperów z zewnątrz to podstawa w tego typu projektach rozwojowych. Wystarczy sobie przypomnieć początki środowiska Eclipse. Przed wersją 3.0 sporo osób 'hakowało' SDK wycinając samego Equinoxa jako podstawę rozszerzalnych aplikacji serwerowych lub wczesne RCP. Dzięki temu ktoś zauważył że warto stworzyć koncepcję RCP, później RT itp. Otwartość na nowe 'niestandardowe' pomysły to moim zdaniem coś o czym zawsze powinno się pamiętać

'Eclipse w Polsce' w serwisie Facebook

Właśnie wróciłem z Krakowa w którym odbyła się kolejna edycja spotkania Eclipse Demo Camp. Podczas spotkania pojawiło się kilka fajnych tematów miałem także okazję po raz kolejny nakłaniać słuchaczy do wypróbowania środowiska XText. Samo spotkanie opisze jednak w kolejnym wpisie jak sobie wszystko poukładam w głowie. Teraz czas na Facebooka :)

W ciągu ostatnich 4 lat wspólnie z wami zorganizowaliśmy sporo spotkań z cyklu EDC. Celem tych spotkań było nie tylko nakłonienie ludzi by wypróbowali technologie z rodziny Eclipse ale przede wszystkim chęć zbudowania polskiej społeczności związanej z tym tematem. Coś jak JUG’i które od wielu lat grupują pasjonatów języka Java. We Wrocławiu zorganizowaliśmy dwa takie spotkania i zauważyłem że nie do końca wszystko działa tak jak planowałem.

Ludzie zapisywali się na spotkania, przychodzili, dyskutowali (często do nocy jak podczas 'EDC 2009 Wrocław' które trwało prawie 7h!)... Sukces? Nie do końca. Po pierwsze nie udało mi się kontaktów z EDC utrzymać na dłużej, po drugie na kolejnym spotkaniu nie kojarzyłem osób które były na poprzednim. Po prostu za bardzo byłem zajęty organizacją całości, przygotowywaniem kawy i herbaty by móc kogokolwiek zapamiętać (nie zawsze miałem czas by nawet spokojnie posłuchać prezentacji)

Postanowiliśmy to zmienić. Po dyskusji podczas EDC z Szymonem i Tomkiem zdecydowaliśmy się utworzyć 'społecznościową stronę' w serwisie Facebook: http://www.facebook.com/eclipse.polska.

Chcemy by strona ta była miejscem w którym każdy będzie mógł się dowiedzieć co ciekawego dzieje się w polskiej społeczności Eclipse. Zapisać się na kolejne EDC oraz inne spotkania/wykłady na których będzie poruszana ta tematyka. Każdy kto dołączy do społeczności będzie mógł wrzucać na tablicę ważne informacje dotyczące platformy (zdjęcia, wideo, linki etc). Możliwa będzie także dyskusja na różne tematy za pomocą forum dysksyjnego Facebooka (choć fajnie byłoby także dodać jako zakładkę istniejące forum - wie może ktoś jak to zrobić?)

No i na koniec najważniejsze czyli tagowanie zdjęć. Chcemy zachęcić wszystkich którzy uczestniczyli w spotkaniach EDC w ciągu ostatnich kilku lat by oznaczyli się na archiwalnych zdjęciach. Pozwoli nam to dowiedzieć się kto uczestniczył w spotkaniach i jakoś wspólnie stworzyć solidne podstawy społeczności Eclipse w Polsce. Nie znaleźliśmy zdjęć ze wszystkich spotkań (część galerii jest pusta) ale postaramy się to uzupełnić. Jeżeli ktoś ma takie zdjęcia prosiłbym o kontakt na 'deepdiveinto' na gmail.

Wszystkich zainteresowanych rozwojem środowiska Eclipse serdecznie zapraszamy :)


Eclipse Demo Camp 2010 - Kraków

Już jutro odbędzie się kolejne spotkanie z cyklu Eclipse Demo Camp. W imieniu organizatorów zapraszam każdego zainteresowanego technologiami związanymi ze środowiskiem Eclipse.

Prezentacje będą bardzo krótkie ponieważ główny nacisk położony będzie na dyskusje tematyczne. Każdy zainteresowany będzie miał więc możliwość uzyskania odpowiedzi na swoje pytania związane z technologiami Eclipse. Ja z mojej strony obiecuję odpowiadać na wszystkie pytania dotyczące technologii związanych z modelowaniem, językami specjalizowanymi (nie tylko na temat xText)

http://wiki.eclipse.org/Eclipse_DemoCamps_Helios_2010/Krakow

11.00 - 11.30New and Noteworthy in Eclipse Helios, Platform Workspace Team
11.30 - 11.45Eclipse 4.0 and e4, Tomasz Żarna, Platform Workspace Team
12.15 - 12.30OSGI in the cloud, Krzysztof Daniel, IBM Eclipse Support Center
12.30 - 12.45Cloud computing
13.30 - 13.45BIRT - Raporty w Eclipsie, Łukasz Pobereźnik, IBM
13.45 - 14.00XText, Grzegorz Białek
14.30 - 14.45Eclipse Communication Framework, Paweł Pogorzelski, Platform Workspace Team
14.45 - 15.00GWT development using Eclipse, Szymon Brandys, Platform Workspace Team

ARText - prezentacja możliwości xText

Na blogu Svena Efftinge'a pojawiła się niedawno fajna prezentacja możliwości frameworku xText w wykonaniu BMW. Zaprezentowane jest środowisko ARText dla platformy AUTOSAR która od kilku lat jest standardem w przemyśle motoryzacyjnym. Oprócz możliwości biblioteki pokazuje o ile prostsze jest konfigurowanie systemu z użyciem specjalizowanego języka zamiast złożonego XML'a.

Jak "włamać się" do obcego bundla w OSGi

Przeglądając swojego bloga zauważyłem że od dłuższego czasu nie pojawiały się na nim tematy stricte techniczne. Spowodowane to było między innymi małą ilością czasu. Dobrze byłoby to zmienić by blog zachował swój pierwotny charakter. Ponieważ ostatnie kilka lat spędziłem pracując nad rozwojem technologii Eclipse postanowiłem zacząć od tej tematyki.

Temat dzisiejszy to integracja oprogramowania w modelu OSGi. Oczywiście nie będę tutaj opisywał mechanizmu ponieważ jest to bezcelowe. Istnieje setka tutoriali która wyjaśnia co i jak działa. Tutoriale te jednak zazwyczaj kończą się na prostych przykładach a z perspektywy pracy nad projektami modularnymi wiem że to zdecydowanie za mało. To co w 90% jest błogosławieństwem, to w 10% jest problemem. Jednym z takich tematów jest mechanizm ukrywania API.

Ukrywanie klas jest kluczowym aspektem opracowania dobrego API które będzie współpracowało przez lata z produktami rozwijanymi przez inne firmy. Dostawcy bibliotek określają które elementy kodu są publiczne a które prywatne. Co jednak gdy tworzymy zaawansowaną integrację systemów wykraczającą poza publiczne API? To ryzykowna sprawa jednak w realnych projektach czasami nieunikniona. W OSGi klasy z pakietów prywatnych są dla nas niedostępne... do czasu :)

Przykładowym scenariuszem może być próba integracji własnych narzędzi z edytorem JBoss Drools IDE którą robiłem kilka lat temu. Biblioteka ta praktycznie wszystkie pakiety miała prywatne. Między innymi pakiet w którym znajduje się klasa edytora którą byłem zainteresowany jako potencjalnym komponentem w multi-edytorze. Jak się do niej dostać? Istnieją dwie metody: "studencka" i poprawna.

Studencka polega na modyfikacji biblioteki i jak się każdy domyśla nie jest to najlepsze rozwiązanie (nawet jeżeli pozwala na to licencja). Zmodyfikowana biblioteka trafia na nasze serwery więc na nas spoczywa odpowiedzialność za jej dalsze uaktualnienia, zgłoszenia błędów etc. Znacznie podnosi to koszty utrzymania takiego rozwiązania. Dodatkowo coraz więcej bibliotek jest podpisanych certyfikatami by wykluczyć nieautoryzowane modyfikacje.

Jak więc poprawnie zaimplementować modyfikacje pliku Manifest.MF tak by nie modyfikować samego bundla? Odpowiedzią jest mechanizm 'fragments' platformy OSGi. Zazwyczaj służy on do dodawania plików z tłumaczeniami, bibliotek dla różnych systemów itp. Tym razem użyjemy go do naszego "włamania" i upublicznienia prywatnych pakietów.

By całość zademonstrować przygotowałem następujący przykład. Firma 'Private Library Company' dostarczyła nam bundla w którym między innymi znajduje się klasa potrafiąca zwrócić nam cały świat :) Niestety klasa znajduje się w pakiecie wewnętrznym który nie jest udostępniony w manifeście.


Nasza firma 'Client Plugin Company' przygotowuje aplikację dostaczającą usługę której zadaniem jest pozdrowienie całego świata. Musimy więc dostać się do klasy która potrafi zwrócić nam 'świat'. Posiadamy oczywiście zależność na bibliotekę jednak nie jest to wystarczające. Kod nie będzie działał ponieważ klasa 'World' nie jest widoczna.


By to zmienić musimy przygotować odpowiednie rozszerzenie dla posiadanej biblioteki. Wykorzystamy w tym przypadku mechanizm fragmentów bundli. Z założenia mechanizm ten nie może modyfikować elementów, dostarczać nowego API jednak do naszego "włamania" nadaje się jak najbardziej. Tworzymy projekt fragmentu rozszerzający bundle biblioteki, możemy go nazwać 'privatelibrary.customization'. Następnie tworzymy w nim ścieżkę identyczną z tą którą chcemy upublicznić i zakładamy w niej pustą klasę np. o nazwie 'PackagePublisher'. Po utworzeniu klasy pojawia nam się możliwość upublicznienia jej pakietu w manifeście fragmentu. Platforma OSGi by obsłużyć naszą publiczną klasę dodaje 'regułę publiczności' dla wybranego pakietu dla nadrzędnej biblioteki.

Tym samym w projekcie klienckim uzyskujemy dostęp do interesującej nas klasy prywatnej 'World'. By całość działała nasz dodatek musi być dostępny dla platformy. Jeżeli go usuniemy całość ponownie przestanie się kompilować a jeżeli element będzie niedostępny w ramach runtime pojawi się wyjątek ClassNotFound przy próbie odwołania się do klasy świata. Oczywiście nasza klasa 'PackagePublisher' którą upubliczniliśmy w tym pakiecie nie jest publicznie dostępna. Nie zezwala na to kontrakt mechanizmu fragmentów. Poniżej zrzut z poprawnie zdefiniowanego manifestu.



Mam nadzieję że całość nie jest zbyt zagmatwana. Starałem się zrobić na tyle długi wstęp by całość wyjaśnić łącznie ze scenariuszem kiedy takie obejścia stosujemy. Oczywiście nie nakłaniam nikogo do odwoływania się do klas prywatnych w zewnętrznych bibliotekach. Takie sytuacje nigdy nie powinny być rutyną. Jeżeli jednak jest to koniczne z punktu widzenia biznesu warto wiedzieć jak to zrobić poprawnie. Gotowy projekt dostępny jest pod adresem:

http://sites.google.com/site/deepdiveinto/Home/PrivatePackage.zip?attredirects=0&d=1

Obrazek z wróżką pochodzi z prezentacji: OSGi Best and Worst Practices
Jak zawsze zachęcam także każdego do wypróbowania dodatku Facebook Like Plus

OSGI and Equinox

Właśnie dostałem długo oczekiwaną przesyłkę. Książka miała pojawić się jeszcze w ubiegłym roku ale w końcu jest :)

Autorem książki jest lider projektu Eclipse Equinox. To chyba najlepsza reklama dla każdego zajmującego się tematyką OSGi/Eclipse. Pełną recenzję możecie znaleźć w tutaj:



OSGi and Equinox: Creating Highly Modular Java Systems

Eclipse Demo Camp we Wrocławiu (edycja druga)

Już za kilka dni odbędzie się druga wrocławska edycja Eclipse Demo Camp.



Interesujesz się środowiskiem Eclipse? Chciałbyś się dowiedzieć jak wykorzystać Eclipse nie tylko do programowania w Javie? Zapraszamy na spotkanie użytkowników i deweloperów środowiska Eclipse.

Eclipse DemoCamp Wrocław 2009!

  • Jacek Pospychała, JavaScript, AJAX w Eclipse

  • Jacek Laskowski, Enterprise JavaBeans (EJB) na OSGi

  • Krzysztof Kowalczyk, Transformacje Model-Model i Model-Text z wykorzystaniem technologii Eclipse

  • Grzegorz Białek, Tworzenie narzędzi w środowisku Eclipse (podstawy i nie tylko)


Rejestracja możliwa jest pod adresem:
http://oiola.com/e/496-druga-wroclawska-edycja-eclipse-demo-camp/


Więcej informacji o prezentacjach oraz prowadzących można znaleźć pod adresem: http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Wroclaw

Spotkanie odbędzie się w sobotę 21 listopada 2009 w budynku firmy Sygnity (ul. Strzegomska 140. Sponsorem głównym została forma PB Polsoft




Zdjęcia oraz podsumowanie pierwszej wrocławskiej edycji Eclipse Demo Camp można znaleźć tutaj tu: http://deepdiveinto.blogspot.com/2008/11/pierwsza-edycja-eclipse-democamp-we.html