Zgodność, trudna sprawa

Zgłaszana przez różne gremia potrzeba elastyczności przy wdrażaniu aplikacji Java jest odbiciem faktu, że środowisko deweloperów Java nie miało dotychczas zbyt wielkiego wyboru. Elastyczność polegała i nadal polega na tym, że w zależności od planowanego charakteru, skali i stopnia skomplikowania aplikacji wybierało się odpowiedni serwer aplikacyjny, niosący różnorodne udogodnienia w określonych scenariuszach wdrożeniowych. Oczywistą konsekwencją wykorzystania "rozszerzeń" jest trudność przeniesienia aplikacji z jednej platformy J2EE do innej - pomimo teoretycznej przenośności.

Kwestie kompatybilności były na JavaOne podnoszone wielokrotnie, ale w tym roku, jak się wydaje, tematowi nadana została wyższa niż dotychczas ranga. Kompatybilność była wprost tematem kilku referatów, z których wynikało, że przenośność jest, zgodnie ze zdrowym rozsądkiem, zależna w największym stopniu od planowania jej na etapie projektowania aplikacji, a nie późniejszych wysiłków.

W trakcie dyskusji z udziałem przedstawicieli Sun Microsystems i Microsoftu pojawiła się kwestia wciąż bardzo słabej kompatybilności między środowiskami Java i .Net. Deweloperzy obecni na sesji głośno wyrażali zadowolenie, że do współpracy w ogóle doszło, jednocześnie narzekali jednak, że ponad rok od ogłoszenia współpracy tandem Sun-Microsoft nie zaoferował im w sumie nic konkretnego.

Odpowiadając na zarzuty, obecny na sesji Doug Purdy, kierujący programem rozwoju technologii Indigo w Microsofcie, stwierdził: "Dziewięćdziesiąt dziewięć procent problemów z kompatybilnością ma związek z XML Schema", czemu przytaknęła Marina Fisher, architekt systemowy Suna, a pośrednio także Mark Nottingam, starszy technolog Bea Systems. Sun i Microsoft zamierzają w tej sprawie wystąpić do IETF i W3C.

Podczas dyskusji Doug Purdy określił kompatybilność jako zdolność do wysłania wiadomości, walidacji zawartych w niej danych i podjęcia przetwarzania na ich podstawie. Na głosy z audytorium, że to nie wystarczy, i że w praktyce potrzebna jest zdolność aplikacji do wykrycia źródeł problemów w komunikacji, jeśli takie wystąpią, Dino Chiesa, jeden z menedżerów odpowiedzialnych za rozwój .Net odpowiedział: "W ramach jednego projektu technologia powinna być możliwie homogeniczna, by unikać niepotrzebnej komplikacji. Integracja i koncepcje takie jak SOA mają sens pomiędzy projektami".

Podczas dyskusji panelowej na temat kompatybilności Javy i .Net paneliści podkreślali rolę specyfikacji WS-Security. Głosy z sali zdecydowanie jednak wskazywały na preferowanie SSL, jako specyfikacji istniejącej, działającej i sprawdzonej - w przeciwieństwie do WS-Security, która jest na etapie projektowania i wciąż ewoluuje. Do tego okazało się, że w prostych rozwiązaniach zabezpieczenie komunikacji typu punkt-punkt w zupełności wystarczy.

W trakcie dyskusji pojawiły się pytania, czy Microsoft rozważa przystąpienie do Java Community Process, czym, jak okazało się, jest zainteresowany Oracle. "Nie mamy tego w planach" - odpowiedział reprezentujący Microsoft Dino Chiesa.

Narzędziowa odnowa

Podczas JavaOne 2005 Sun na każdym kroku podkreślał możliwości tkwiące w środowisku IDE Net-Beans 4.1, dostępnym wciąż jeszcze w wersji beta. Jeśli chodzi o funkcjonalność, wygodę użycia, a zwłaszcza wydajność kodu interfejsów graficznych, NetBeans 4.1 stanowi zupełnie nową jakość. Inżynierowie projektu NetBeans postawili sobie chyba za punkt honoru usunięcie problemów, które w przeszłości przyczyniły się do popularności Eclipse. Na marginesie warto zauważyć, że ostatnie wersje Eclipse nie powalają wydajnością.

Nie można nie zauważyć, że choć zainteresowanie NetBeans ostatnio istotnie wzrosło, siła przyciągania Eclipse jest obecnie bardzo wielka i podnoszone niegdyś kwestie wydajności mają obecnie charakter drugorzędny. Atrakcyjność Eclipse jako uniwersalnego środowiska IDE jest tak duża, że przystąpili do niej w tym roku dwaj dotychczasowi malkontenci: Borland i BEA Systems. Stawia to Suna w iście donkiszotowskiej sytuacji - przynajmniej w ujęciu marketingowym. W rzeczywistości bowiem z NetBeans nie jest bowiem tak źle.

Sun postawił sobie za cel uczynienie z NetBeans najlepszego środowiska do tworzenia aplikacji zgodnych z J2EE i w dużej mierze wprowadził ten zamiar w życie. Zawarte w NetBeans 4.1 ułatwienia, m.in. ukrywanie szczegółów implementacyjnych w "widokach logicznych", dodawanie źródeł danych i innych elementów projektu, jak np. serwery, metodą przeciągnij i upuść itp., automatyczne "zwijanie" kodu, wsparcie dla refaktoringu kodu, obsługa ANT i wiele innych, pomniejszych.

Sun przedstawił na JavaOne także JavaStudio Creator 2.0 - pakiet do szybkiej budowy aplikacji WWW, który trafi na rynek jesienią. Nowy pakiet obsługuje JavaServer Faces i portlety, pozwala na interaktywne, graficzne projektowanie interfejsów aplikacji. Co więcej, nowy Java Studio Creator obsługuje AJAX, czyli Asynchronous JavaScript And XML. Aplikacje AJAX działają prawie tak interaktywnie, jak zwykłe aplikacje desktop.