Sun szacuje, że programowaniem w Javie zajmuje się ok. 3 mln osób. Z roku na rok ich przybywa, ale do pełni szczęścia jest jeszcze daleko. Ambitny cel postawiony przez Suna to przekonanie 10 mln programistów.

O ile poprzednie edycje konferencji JavaOne były poświęcone głównie nowym możliwościom platformy, o tyle tym razem za priorytet uznano uproszczenie pracy z Javą. Sun uznał, że to jeden z warunków koniecznych, aby ku Javie zwrócili się tzw. developerzy korporacyjni. Równocześnie firma dostrzegła, że wygodne narzędzia to nie tylko IDE z kreatorami generującymi tasiemcowy kod, ale także biblioteki i takie cechy języka, które sprawią, iż kod będzie krótki i czytelny.

Lista zadań do wykonania

Wyzwaniem dla Suna będzie stworzenie spójnego "systemu Java" - zamiast dostępnych obecnie de facto oddzielnych zestawów API - J2SE, J2EE, J2ME i JavaCard API. Integracja miałaby ułatwić programistom pisanie różnego typu aplikacji tak, aby przyzwyczajenia zaczerpnięte z J2SE można było wykorzystać, programując np. JavaCard. Na razie, zamiast jednej Javy, mamy do czynienia z czterema.

Ważnym elementem prac nad uproszczeniem Javy będzie zapewnienie zgodności ze standardami. Przed rokiem powstał pakiet do weryfikacji zgodności kodu serwerowego ze standardem J2EE. Obecnie przedstawiciele firm produkujących telefony komórkowe (Motorola, Nokia, Siemens, Sony Ericsson) pracują nad testami, które zapewnią zgodność oprogramowania na wszystkich urządzeniach przenośnych wykorzystujących J2ME. W ten sposób nie będzie konieczne testowanie oprogramowania na wielu różnych platformach, co bardzo ułatwi życie programistom.

Nowy tygrys

Wiele emocji wzbudziły prezentacje i plotki dotyczące następnej wersji Javy - 1.5. Nadano jej roboczą nazwę Tiger. W rzeczywistości nie będzie to zwykła, po prostu kolejna wersja pakietu programistycznego JDK czy środowisk uruchomieniowych J2SE i J2EE. Tiger ma mieć wiele nowych elementów, które tak naprawdę przekształcają Javę.

Zmiany wprowadzone w wersji 1.5 dotkną "jądra" Javy - języka programowania. Będzie to pierwsza przeprowadzona na tak dużą skalę aktualizacja od 1995 r. Specyfikacja Tiger ma się pojawić w 2004 r. Prawdopodobnie na początku 2005 r. będzie już wersja następna 1.5.1, nazwana Dragon-fly (poza nazwą roboczą na konferencji nie zostały przedstawione szczegóły tej edycji).

Co prawda przedstawiciele Suna zaprzeczają, jakoby Tiger w jakimkolwiek stopniu był wzorowany na .Net, ale trudno oprzeć się wrażeniu, że inżynierowie zajmujący się Javą nie spoglądają od czasu do czasu w kierunku Microsoftu, np. w .Net rozbudowano mechanizmy związane z metadanymi, składnią i atrybutami, dokładnie w tym samym kierunku zmierza Sun, czego potwierdzeniem są proponowane zmiany w Javie 1.5.

Dzięki atrybutom zostanie uproszczone dalsze rozszerzanie języka oraz określanie ról poszczególnych klas i metod. Na razie nie jest planowane dodanie składni językowej do wspierania właściwości klas. W zestawie narzędzi JDK 1.5 mają być dostępne wzorce. Pozwoli to na parametryzowanie wybranym typem danych dowolnej klasy (tak jak w C++). Może się okazać, że Java z czasem będzie wypierać Fortran jako język przeznaczony do obliczeń numerycznych.

Mechanizmy związane z atrybutami przyniosą korzyści zwłaszcza po serwerowej stronie Javy. W specyfikacji Enterprise Java Beans 3.0 atrybuty mają być wykorzystywane do opisu komponentów. Programista, zamiast ręcznie pisać deskryptory opisujące zasady wgrywania komponentów na serwer aplikacyjny, będzie dodawał odpowiednie atrybuty - podczas kompilacji właściwy deskryptor zostanie wygenerowany.

W nowej Javie nie będzie konieczności stosowania wielu wzorców nazw. Obecnie w Javie (w EJB i nie tylko) stosuje się zwyczajowo przyjęte zasady nazywania składników (dzięki temu np. pary funkcji set/get były traktowane przez IDE jako właściwość). W J2EE 1.5 i JDK 1.5 funkcjonalność ta ma być realizowana przy użyciu atrybutów, które określą znaczenie funkcji. W środowisku J2EE obiekt EJB będzie dowolną klasą z przypisanym atrybutem seryjności i transakcyjności. Dzięki temu praca programisty będzie znacznie prostsza, a jednocześnie środowiska IDE staną się łatwiejsze w użyciu. Warto dodać, że analogiczne mechanizmy są stosowane w .Net Microsoft - tam też atrybut określa transakcyjność obiektu COM+.

Co ciekawe, Sun sceptycznie odnosi się do pomysłów związanych z automatycznym przenoszeniem stanu komponentów J2EE pomiędzy węzłami klastra. Zdaniem Marka Hapnera z Suna jest to rozwiązanie niebezpieczne, komplikujące nadmiernie i tak już rozbudowaną specyfikację J2EE. Warto dodać, że kilka serwerów aplikacyjnych dostarczanych przez niezależne firmy oferuje taką funkcjonalność.

Nie planowane są duże zmiany w standardach opisujących zapisywanie tzw. sesyjnych komponentów EJB. Sun liczy bowiem na standardy związane z usługami Web, przeznaczonymi do tworzenia schematów procesów biznesowych - "sesja" takiej operacji biznesowej będzie w pewnym sensie poza samym obiektem i w konsekwencji może się zmniejszyć obciążenie serwera aplikacyjnego.