January 11,2022

Oprogramowanie Java

By Weronika Skotnicka

Sun finalizuje uwolnienie kodu Javy

Sun Microsystems dostarcza coraz więcej szczegółów o tym, jak planuje uwolnić podstawową technologię Javy, wywiązując się z obietnicy, którą złożył w maju podczas konferencji JavaOne.

Według oświadczenia Pedera Ulandera, wiceprezesa do spraw marketingu oprogramowania, firma zamierza jeszcze w listopadzie uwolnić kod źródłowy zarówno Java Platform Standard Edition (Java SE) jak i Java Platform Micro Edition (Java ME).

Inicjatywa open-source w zakresie projektowania aplikacji serwerowych, oparta na trzecim elemencie rodziny Java - Java Platform Enterprise Edition (Java EE), jest już w toku realizacji od czerwca 2005 r. pod nazwą Project GlassFish.

Zobacz również:

Sun zamierza udostępnić społeczności open source trzy główne komponenty z Java SE i Java ME. W ramach Java SE tymi elementami są: Java Compiler, Java HELP i maszyna wirtualna Java HotSpot. W ramach Java ME są to: stos Connected Limited Device Configuration (CLDC), Connected Device Configuration (CBC) i Mobile Information Device Profile (MIDP) 2.1.

Chociaż Sun zamierza utrzymać markę 'Java', jest prawdopodobne, że prace społeczności open source wykonywane w oparciu o uwolnione wersje Java SE i Java ME będą znane poprzez nazwy projektów, tak jak np. Project GlassFish (Java EE).

Z chwilą uwolnienia kodu Java, ok. 70 proc. oprogramowania Suna będzie dostępne bezpłatnie. Według oświadczeń przedstawicieli Suna, firma nadal jest zdecydowana uwolnić w okresie 12 miesięcy pozostałą część swojego oprogramowania, obejmującą zestawy SOA i oprogramowanie zarządzania tożsamością.

Uwolnienie kodu źródłowego oprogramowania ma zachęcić szersze grono projektantów do eksperymentowania z tymi technologiami. Firma ma nadzieję, że kiedy użytkownicy zdecydują się na adoptowania oprogramowania Suna, to zechcą też zakupić w firmie usługi wspierające, a także szybciej zdecydują się na zakup sprzętu Suna, co ma przełożyć się na zwiększenie przychodów firmy.

Java po dziesiątce

Konferencja JavaOne 2005 jako impreza rocznicowa nie wypadła oszałamiająco, ale tych, dla których Java jest chlebem powszednim, utwierdziła w przekonaniu, że poświęcają swój czas właściwej technologii.

Dziesiąta, rocznicowa konferencja JavaOne nie przyniosła zasadniczych nowości w dziedzinie technologii Java ani wielkich premier produktowych. O ile jednak ubiegłoroczna impreza pozostawiła w głowach uczestników więcej pytań niż odpowiedzi, o tyle w tym roku można było odczuć, że Sun Microsystems powoli, ale jednak, krystalizuje swoją wizję przyszłości Javy. Niemniej, problemów i wyzwań, z którymi Java zarówno jako technologia, jak i środowisko deweloperskie musi się zmierzyć, nadal jest wiele.

Wśród zagadnień, które wciąż się ważą, jest nie tylko stopień otwartości Javy, rozumiany niekiedy skrajnie różnie, ale także przyszłość architektur komponentowych i narzędzi, kwestia kompatybilności implementacji technologii J2SE oraz J2EE, jak również kształtu Javy jako technologii integracyjnej. Znamienne jest, kontrastujące z wieloma wcześniejszymi imprezami JavaOne, odejście od wymieniania Microsoftu jako podstawowego zagrożenia dla Javy, który po raz pierwszy był oficjalnym uczestnikiem konferencji.

Jak zawsze, konferencja JavaOne była okazją do zaprezentowania tego, co pichcą w swoich laboratoriach deweloperzy. Niektóre propozycje technologiczne wyglądają całkiem atrakcyjnie i ani chybi wejdą w najbliższym czasie do głównego nurtu Javy. Wśród nich wypada tu wymienić np. technologię mapowania relacyjno-obiektowego Hibernate 3.0, język programowania dla farm komputerów Groovy, czy też technologię integracyjną JBI.

Kod w akwarium

Jednym z wątków, które przeplatały się przez wszystkie sesje JavaOne 2005, były rozważania odnoszące się do otwarcia specyfikacji Java. Na przestrzeni ostatniego roku Sun wsłuchiwał się w głosy płynące ze środowiska. Reakcja firmy na nie, będąca wynikiem ścierania się interesów deweloperów i udziałowców, pozostawiła i jednych, i drugich w niedosycie. Kompromis nigdy nie jest w pełni zadowalający dla wszystkich, ale na pewno można mówić o postępie.

Wyrazem tego postępu jest fakt, że Sun nie sprzeciwia się certyfikacji na zgodność z J2EE serwerów aplikacji dostępnych na licencjach open source. Ubiegłoroczna certyfikacja serwera JBoss i trwająca certyfikacja serwera Geronimo (właśnie zakończyły się testy zgodności z J2EE 1.4) rozwijanego pod auspicjami The Apache Foundation przez deweloperów wywodzących się z JBoss świadczą, że Sun bierze open source poważnie.

Po części wskutek popularyzacji serwerów aplikacyjnych J2EE Sun skłonił się w końcu do otworzenia kodu swojego serwera aplikacji - Sun Java System Application Server 9 - w ramach projektu GlassFish. Oczywiście, GlassFish nie jest oparty na licencji GPL, lecz na licencji CDDL (Common Development and Distribution License), dzięki czemu Sun wciąż trzyma w ręku pewną kontrolę, ale możliwości deweloperów, np. w dziedzinie optymalizacji kodu i proponowania zmian, i tak wzrosły niepomiernie.

Sun wciąż pozostaje jednak sceptyczny jeśli chodzi o rozwój środowiska wykonawczego Java dla stacji roboczych w wersji open source. Komentując inicjatywę Harmony, czyli propozycję stworzenia pod auspicjami The Apache Foundation otwartej wersji J2SE w wywiadzie dla serwisu DevX, James Gosling powiedział. "Od środowiska open source trudno jest uzyskać jednoznaczne stwierdzenie, co tak naprawdę nie pasuje im w tym, co robimy".

Gosling nie po raz pierwszy wyraża zdziwienie żądaniami środowiska open source. "Jak możemy być jeszcze bardziej otwarci? Od pierwszego dnia [istnienia Javy - przyp. red.] kod Java był otwarty i szeroko dostępny. Stworzyliśmy też model nadzoru nad rozwojem Javy [Java Community Process - przyp. red.], który działa podobnie jak projekty open source" - powiedział w wywiadzie.

W odniesieniu do J2SE Gosling podniósł kwestię, która zwykle uchodzi uwagi osób zainteresowanych pełnym otwarciem środowiska wykonawczego, a mianowicie problem testowania kompatybilności, do czego Sun podchodzi bardzo rygorystycznie. "Nasze procedury obejmują - dosłownie - setki tysięcy programów testowych. To nie jest tak, że można sobie przepuścić plik przez kompilator" - mówił.

James Gosling powiedział też coś, co wydaje się esencją spojrzenia Suna na kwestie otwartości, a co sprowadza się do zachowania spójności i kompatybilności jako wartości najistotniejszych dla technologii Java. "Dostajemy po głowie od facetów, którzy myślą, że nie jesteśmy dostatecznie liberalni, ale z punktu widzenia klientów, na których najbardziej nam zależy, nasza daleko posunięta ostrożność wyraża ich głęboką troskę" - mówił Gosling.

Pożytki z harmonii

Mimo to projekt Harmony raczej wystartuje. Nadzór The Apache Foundation gwarantuje wysoką jakość finalnego produktu i prędzej czy później sukces w testowaniu. Skąd jednak wziął się sam pomysł? Dlaczego deweloperzy Java szukają alternatyw dla istniejącego środowiska J2SE?

"Istnieje wyraźna potrzeba stworzenia platformy wykonawczej J2SE dostępnej na zasadach open source, o czym świadczą inicjatywy dążące do stworzenia takich rozwiązań (np. Kaffe, Classpath itp. [wyczerpującą listę można znaleźć na - przyp. red.]). Powstały także projekty oferujące alternatywne podejścia do wykonywania bajtkodu Java (GCJ i IKVM [odnoszące się do kompilacji bajtkodu do kodu maszynowego - przyp. red.]). Inicjatywy te są różnorodne, co jest zdrowe, ale napotykają bariery uniemożliwiające im osiągnięcie większego potencjału" - napisał na liście dyskusyjnej The Apache Foundation w maju br. Geir Magnusson Jr., jeden ze sponsorów projektu.

Kwestia open source jest dla powodzenia Harmony sprawą, jak się wydaje, wtórną. Celem projektu jest bowiem, jak pisze Geir Magnusson Jr., "stworzenie modularnego środowiska J2SE, obejmującego zarówno maszynę wirtualną, jak i bibliotekę klas, pozwalającego na swobodę implementacji i innowacje w dziedzinie komponentów". Harmony wyraża więc przede wszystkim potrzebę stworzenia jednego, uniwersalnego środowiska wykonawczego, którego poszczególne elementy można by wymieniać w zależności od potrzeb.

Te potrzeby to np. łatwość tworzenia wydajnych implementacji dla różnych platform sprzętowych i systemowych, bez potrzeby dokonywania poważniejszych zmian w kodzie. Przykładowo, implementacja czasu rzeczywistego dla aplikacji działających, dajmy na to, w samochodach będzie wyglądać zupełnie inaczej, niż implementacja biurkowa czy implementacja przeznaczona dla kart inteligentnych.

W każdym z tych przypadków inaczej może przebiegać kompilacja do bajtkodu (o ile nie skończy się na kompilacji do kodu maszynowego), zarządzanie wątkami, wykorzystanie odwołań do protokołów komunikacyjnych itp. Modularność pozwoli zachować elastyczność pod względem wykorzystania zasobów, oczekiwanej wydajności, poziomu niezawodności, bezpieczeństwa itp., bez zmian w samym kodzie.

W kontekście Harmony ujawnia się także jedna z ważniejszych kwestii dotyczących współczesnej informatyki, a mianowicie szybkość i łatwość tworzenia oprogramowania dziedzinowego przy użyciu specjalizowanych języków. Sukces platformy .Net Microsoftu, na której bez problemu może współpracować wiele różnych języków programowania, to po części dowód na twierdzenie, że nawet elastyczny język (C#) nie zaspokaja wszystkich potrzeb ani też nie nadaje się dla wszystkich poziomów umiejętności programistycznych.

Podobnie jak C#, Java oferuje programiście bardzo wiele, ale od jej powstania minęło dziesięć lat i zakres zastosowań maszyn wirtualnych poszerzył się znacznie. Nie oznacza to jednak, że "stare" języki z dnia na dzień wyjdą z użycia. Modularność Harmony odnosi się więc także do faktu, że ma ona umożliwiać uruchamianie bajtkodu, który powstał na skutek kompilacji języka innego niż Java.

Takie rozwiązania już istnieją, np. JPython albo NetRexx (dla platformy IBM zSeries). W świetle prac nad językami specyficznymi dla konkretnych branż, które trwają w ramach Eclipse, rozwój środowiska wykonawczego Java w tym kierunku wydaje się bardzo pożądany.