Ambitny pasikonik

Grasshopper 2.0 to ambitne narzędzie do konwersji kodu .Net na bajtkod Java. Daleko mu jednak do doskonałości - wersja beta nadaje się jedynie do prostych testów.

Grasshopper 2.0 to ambitne narzędzie do konwersji kodu .Net na bajtkod Java. Daleko mu jednak do doskonałości - wersja beta nadaje się jedynie do prostych testów.

MainSoft zaprezentował wersję beta swojego narzędzia Visual MainWin for J2EE v2, znanego pod kodową nazwą Grasshopper 2.0. Służy ono do migracji rozwiązań pomiędzy .Net a Javą, a dokładniej konwersji MSIL na bajtkod Java (z pewnymi ograniczeniami). Narzędzie generuje standardowe pakiety WAR gotowe do przeniesienia na serwer J2EE. Dodatkowo rozwiązanie zawiera implementację często używanych komponentów .Net, m.in. podzbiór ADO .Net itp.

Grasshopper wykonuje operacje analogiczne do tych, które wykonuje Microsoft J# Binary Converter Tool, tyle że odwrotne (rozwiązanie Microsoft tłumaczy bajtkod Javy na MSIL). Obecna implementacja w wersji beta wykorzystuje ciekawy projekt o nazwie Cecil, będący niejako "produktem ubocznym" projektu Mono (implementacja środowiska wykonawczego .Net dla platform Linux).

Co w praktyce może Cecil? Pozwala m.in. wczytać pakiet .Net, przejrzeć lub zmodyfikować typy, a następnie ponownie zapisać wynik na dysku. W odróżnieniu od standardowej biblioteki refleksji, Cecil uwidacznia poszczególne funkcje bajtkodu. Może np. "przejrzeć" poszczególne metody i podmienić ciąg instrukcji, które je definiują.

Nadzieja na mniej pracy

Cecil może też analizować pakiet bez jego wczytywania do środowiska .Net (wczytanie wymusza analizę typów oraz weryfikację). W ten sposób parsowane mogą być nawet nieweryfikowalne pakiety. W ramach Grasshopper Cecil został rozbudowany, by można było za jego pomocą generować bajtkod Java. Część operacji jest przekładana na odpowiednie typy Javy (np. System.Object na java.lang.Object). Inne struktury (typu "pudełkowanie" czy delegowanie itp.) są w pewien sposób emulowane, natomiast ostatecznie powstaje czysty kod Java.

Założenie MainSoft jest oczywiste: programista pracuje nadal na Visual Studio, używa możliwości, jakie daje mu .Net , a specjalny kompilator pozwala generować kod, który działa na pojemniku serwletów (Tomcat) czy też pełnym serwerze J2EE. Problemy jak zwykle tkwią w szczegółach oraz w tym, że na razie jest to beta nadająca się raczej do sprawdzenia, czy wybrane struktury będą poprawnie przeniesione do świata Javy, a nie do wydajnej pracy nad realnym projektem.

Grasshopper wymaga, by do Visual Studio 2005 doinstalować komponent, który pozwala tworzyć projekty Web w podobnym stylu co w Visual Studio 2003 (w 2005 jest to praktycznie folder na dysku). Wynika to stąd, że trzeba w specjalny sposób na serwer J2EE wgrać plik WAR zawierający poszczególne komponenty (i deskryptory) opisujące związki pomiędzy poszczególnymi elementami.

Całe rozwiązanie MainSoft i rozszerzenie IDE Visual Studio .Net jest zintegrowane z serwerem Tomcat, który trzeba uruchomić lokalnie. Niestety, jeśli ten proces się zawiesi (lub zostanie zatrzymany), cały projekt w IDE zachowuje się "dziwnie", tzn. nie można nawet zapisać pliku itp. Być może to "schorzenie" wersji beta, a może jednak nie wszystko zostało dobrze przemyślane.

Raczej bez automatu

MainSoft pozwala uruchomił proste aplikacje .NET w Środowisku Tomcat, a nawet na serwerach J2EE

MainSoft pozwala uruchomił proste aplikacje .NET w Środowisku Tomcat, a nawet na serwerach J2EE

Niestety na drobnych niedociągnięciach trudności się nie kończą. Dalsze problemy wynikają z faktu, że środowiska .Net i Java dosyć istotnie różnią się w założeniach. Na przykład kolekcje oparte na typach ogólnych na platformie .Net działają szybko, zaś po uruchomieniu w środowisku Tomcat są tłumaczone na rzutowanie do typu object - co musi działać wolniej. Także refleksja i dynamiczne wczytywanie typów funkcjonują trochę inaczej, co powoduje, że niektóre fragmenty kodu trzeba pisać w inny sposób, uwzględniając specyfikę rozwiązania MainSoft.

Obecnie nie działa jeszcze mechanizm śledzenia aplikacji, ale w wersji ostatecznej to raczej się zmieni. Natomiast wciąż nie wiadomo, czy będzie można podczas śledzenia zmieniać kod (w stylu Edit & Continue). MainSoft współpracuje z projektem QEMU - LIW (Linux In Windows). Pozwala on uruchomić kopię Linuxa w Windows bez konieczności używania zewnętrznych maszyn wirtualnych. Rozwiązanie to przypomina trochę mechanizm Services For Unix z Windows 2003 R2. W ten sposób można łatwiej testować rozwiązanie pod Tomcatem i Apache.

Chociaż MainSoft podkreśla zgodność Grasshoppera ze specyfikacją .Net 2.0, środowisko to wykorzystuje de facto mechanizmy analogiczne jak w .Net 1.1. Przykładowo, utworzenie komponentów dostępu do danych metodą "przeciągnij i upuść" powoduje, że pewne elementy generowane przez projektanta Visual Studio .Net 2005 nie są kompilowane przez Grasshoppera. Dokumentacja zawiera jednak czytelny opis kroków, jakie trzeba podjąć, aby napisać warstwę dostępową .Net, wydajnie działającą po przeniesieniu do świata J2EE, np. używając Java Data Source.

Produkt MainSoft intensywnie wykorzystuje biblioteki Mono. Z uwagi na model rozwoju tej wersji .Net (nowe elementy pisane są na podstawie dokumentacji Microsoft) nie ma tam pełnej implementacji .Net Framework 2.0. Brakuje m.in. komponentów COM+, nie da się także skorzystać np. z Web Service Enhancement 3.0 (biblioteki realizującej standardy WS-Security, WS-Attachment (DIME). Przenieść takiej usługi Web nie można, mimo że większość stosów Javy także implementuje stosowne standardy.

Trochę inaczej działają profile niż w ASP .Net 2.0. Pojawiają się także problemy przy wykorzystaniu bibliotek firm trzecich - nie działają np. komponenty DevExpress AspXGrid. Wiadomo, że poprzednia wersja Grasshoppera umożliwiała przenoszenie kontrolek ASP .Net firmy Infragistics. Czy tak samo będzie w wersji 2.0, nie wiadomo.

Narzędzie nie do wszystkiego

Na pewno nie można tego narzędzia traktować jako automatu, który na wejściu przyjmuje kod .Net, a na wyjściu produkuje pakiety WAR uruchamiane na J2EE. Co prawda MainSoft twierdzi, że można przenieść pewne przyzwyczajenia (w domyśle: przyniesie to oszczędności związane ze szkoleniem programisty), jednak prawda jest taka, że pisząc z uwzględnieniem Grasshoppera, programista musi znać nie tylko .Net, ale też biegle poruszać się w Javie. Na pewno dostaje do dyspozycji całkiem wygodne IDE (choć w świecie Javy Eclipse jest chyba standardem "de facto").

Grasshopper ma jednak również inne, ciekawe zastosowanie: pozwala w bardzo "ładny" sposób odwołać się z poziomu aplikacji do bibliotek Javy. Analogicznie jak w Visual Studio .Net można dodać referencję do pakietu (assembly) czy usługi Web, można też dodać referencję do kodu Javy. W ten sposób z poziomu aplikacji mamy dostępne dość naturalnie rozwiązania już napisane w Javie. Można więc wykorzystać działający kod serwerowy EJB i komunikować się z nim za pośrednictwem warstwy prezentacyjnej w ASP .Net, co wcale nie jest w praktyce rzadkie. Warto dodać, że nie jest to jedyne rozwiązanie pozwalające na "niskopoziomową" integrację kodu .Net i Java (patrz ramka).

<hr>Nie tylko Grasshopper

Architektura rozwiązania JNBridgePro

Architektura rozwiązania JNBridgePro

Produktem o podobnym profilu co Grasshopper jest JNBridgePro firmy JNBridge. "Opakowuje" on pakiet .Net w taki sposób, by można się było odwoływać ze świata Java i odwrotnie. Nad Grasshopperem ma tę przewagę, że nie wymaga praktycznie żadnych zmian w kodzie. Co więcej, opakowywane mogą być skompilowane pliki. JNBridgePro pozwala także, by komponenty Java i .Net komunikowały się poprzez współdzieloną pamięć w ramach jednego procesu na tym samym serwerze. Komunikacja odbywa się przez lokalne gniazdka sieciowe, co pozwala na dosyć szybką wymianę informacji. W przypadku komunikacji pomiędzy serwerami fizycznymi, JNBridgePro pozwala stosować protokół binarny przypominający nieco .Net Remoting.

Warstwa proxy obudowująca pakiety zapewnia, że przekazywane są wyjątki, informacje o stanie obiektów (dla automatycznych "odśmiecaczy" pamięci), wykonuje konwersję typów itp. Specjalne IDE pozwala ponadto wybrać, jakie typy z danego środowiska mają być udostępnione. Proces generowania jest automatyczny i z punktu 2 środowiska praktycznie nie ma istotnej różnicy, czy jest to kod własny, czy napisany w "obcej" technologii. Trochę problemów może pojawić się w przypadku zdalnych obiektów - co jednak zawsze jest nieuniknione.

Także Borland posiada w swoim portfolio produkt Janeva (działający z .Net 1.x). Ten pakiet integruje trzy światy - Java, .Net oraz Corba. W związku z planowaną od prawie roku przez Borland sprzedażą działu rozwijającego narzędzia developerskie nie wiadomo jednak, jakie będą dalsze losy tego narzędzia.