Platforma Java a technologie .Net

.Net to środowisko, w którym mogą działać aplikacje pisane w dowolnym języku. W świecie Javy natomiast istnieje jeden uniwersalny język, który został tak rozbudowany, by sprostać każdemu zadaniu. Pozornie środowiska programistyczne skłóconych firm: Microsoftu i Sun Microsystems dzieli wszystko. Gdy jednak bliżej się im przyjrzeć, Java i .Net mają wiele cech wspólnych.

.Net to środowisko, w którym mogą działać aplikacje pisane w dowolnym języku. W świecie Javy natomiast istnieje jeden uniwersalny język, który został tak rozbudowany, by sprostać każdemu zadaniu. Pozornie środowiska programistyczne skłóconych firm: Microsoftu i Sun Microsystems dzieli wszystko. Gdy jednak bliżej się im przyjrzeć, Java i .Net mają wiele cech wspólnych.

Porównanie podstawowych elementów platform Java i .NetWspółczesne, złożone systemy informatyczne powstają niemal zawsze w architekturze rozproszonej. Podział aplikacji na warstwy: prezentacyjną, logiki biznesowej i serwera bazy danych stał się na tyle powszechny, że trudno dzisiaj sobie wyobrazić skomplikowane rozwiązanie monolitycznie. Architektura rozproszona sprawia, że bardzo ważne jest zapewnienie właściwych mechanizmów współpracy poszczególnych warstw. Co więcej, czasami warstwa biznesowa jest na tyle rozbudowana, że nie wystarczy jeden serwer aplikacyjny, konieczne jest stosowanie wielu oddzielnych serwerów. Współpraca w warstwie serwera aplikacyjnego wymaga dobrze zdefiniowanego modelu komponentów (obiektów).

Chcąc bardziej efektywnie realizować operacje w warstwie środkowej, programista ma do wyboru trzy mechanizmy: standard CORBA, który obecnie już traci znaczenie, przenośną technologię Java (zwłaszcza J2EE), a także Microsoft.Net (następcę architektury Windows DNA). Przyglądając się bliżej strukturze .Net i Javy (patrz tabelka), można odnieść wrażenie, że ogólna architektura obu rozwiązań konkurencyjnych jest bardzo podobna. Przedstawimy główne cechy obu technologii.

Interpretacja

Oba systemy - Java i .Net - są oparte na maszynie wirtualnej. Microsoft, który pracę nad .Net zaczął znacznie później niż Sun, nie chciał powtórzyć rozwiązania stosowanego przez konkurenta. Kod w Javie jest interpretowany. W przypadku .Net pakiet jest kompilowany podczas instalacji, a dopiero potem uruchamiany. W trakcie kompilacji następuje weryfikacja, czy dany kod może działać w zadanych warunkach.

Technologia .Net pozwala, by administrator (w zależności od podpisów cyfrowych zawartych w pakiecie i uprawnień użytkownika) określił, jakie czynności kod może wykonywać. W przypadku Javy, która ma nieco uboższy model polis uprawnień, weryfikacja następuje często w trakcie interpretowania kodu.

W .Net są dostępne trzy wersje kompilatora. Pierwsza optymalizuje kod pod względem prędkości, druga minimalizuje zużycie pamięci. Obie są oparte na tym samym motorze co kompilator Visual C++. Trzeci typ kom- pilatora - EconoJIT - został zaprojektowany z myślą o urządzeniach przenośnych i prawie nie optymalizuje kodu, ale tworzy tylko na podstawie MSIL listę wywołań funkcji .Net Framework.

W przypadku Javy na komputerach klienckich działa zwykle maszyna wirtualna typu HotSpot, która także kompiluje kod. Jednak w przypadku serwerów aplikacyjnych czasami nadal jest konieczna interpretacja. Należy jednak pamiętać, że z powodu specyfiki niektórych mechanizmów klas w Javie pewne fragmenty kodu zawsze mu- szą być interpretowane. Dynamiczne wczytywanie klas plików czy wręcz generowanie ich w czasie działania aplikacji zwykle nie wykorzystuje mechanizmów kompilatora JIT (Just In Time). Większość debuggerów Javy wymaga, by była wyłączona kompilacja JIT, czyli tak naprawdę program jest testowany z użyciem innej maszyny wirtualnej niż ta, która ma działać w wersji ostatecznej.

W przypadku .Net interpretera po prostu nie ma. Kod jest zawsze kompilowany przed uruchomieniem, a dzięki "mocnym nazwom" może być przechowywany w pamięci cache do późniejszego wykorzystania.

Oba środowiska są wyposażone w automatyczny "odśmiecacz". Jest to uniwersalny mechanizm, który nadzoruje alokacje pamięci i zapewnia, że dany obszar zostanie zwrócony do puli, gdy tylko przestanie być wykorzystywany. Jednak nawet w przypadku stosowania automatycznego "odśmiecacza" może się zdarzyć, że pamięć zostanie zablokowana np. w przypadku aplikacji wielowątkowych, z dzieloną pamięcią.

Zarówno Java, jak i .Net zapewniają mechanizm odwoływania się do "niebezpiecznego" kodu, poza maszyną wirtualną. Sun opracował JNI (Java Invocation API), które pozwala współpracować kodowi Javy z kodem rodzimym (native) dla danej platformy. JNI jest standardową biblioteką klas, definiującą interfejs wywoływania kodu. Możliwa jest współpraca w obu kierunkach - zarówno program w Javie może dokonać wywołania kodu API systemu operacyjnego, jak i system operacyjny może wywoływać odpowiedni mechanizm w Javie (np. utworzyć klasę i wywołać jej metodę).