Cześć,
To i ja dodam swoje trzy grosze...
Warto pamiętać, że Sun jest tylko jedną z setek firm wspierających
Java. Zresztą od dawna (od początku ???) udział Sun'a w rozwoju Java
Enterprise Edition nie jest zbyt znaczący (ktoś pamięta wstrzymanie
rozwoju EJB na 6 lat ?). Na fali frustracji JCP (zwłaszcza działania
JCP przed 3-4 laty) liczący się dostawcy zaczęli nawet uzgadniać wiele
specyfikacji poza Sun'em - czasem między sobą (przykład: CommonJ w
wykonaniu BEA i IBM), czasem w ramach innych konsorcjów (przykład:
OSGi), czasem w ramach projektów open-source (przykład: Spring).
Zatem, nawet jeśli idą trudne czasy dla Sun'a (czego nie życzę), to ma
to znikomy wpływ na samą technologię. Inni wielcy będą "ciągnąć" (tak
jak to zresztą robią) dalej ten wózek - IBM, Oracle, Google, Red Hat,
w dużym stopniu także SAP. Nie zapominałbym także o takich gigantach
jak Nokia, czy Ericsson. Java ma duże wsparcie ze strony Intel'a.
Kluczowi są jednak inni ważni odbiorcy - klienci (firmy
telekomunikacyjne, banki, firmy ubezpieczeniowe, administracja
publiczba, itd). Sorry, ale .NET w rozwiązaniach korporacyjnych jest
nieobecny (bywa Windows i MS SQL, ale to nie jest ten sam poziom co
Java Enterprise. Pomijam z oczywistych względów Office i Exchange).
Dla tych odbiorców (tj. dla klientów) ważna (najważniejsza ?) jest
możliwość wyboru pomiędzy wieloma dostawcami i ewentualnej stosunkowo
łatwej ich zmiany. Wybierając .NET wybiera się między Microsoft a ???
Odpowiadając Michałowi:
Ad 1. C# jest bardzo bogatym językiem i może to jest jego największa
wada. Poza tym język programowania to tylko część sposobu na
rozwiązywanie problemów za pomocą technologii. Nie przyrównywałbym
Java do F#, bo Java nie ma ambicji, aby stać się jezykiem funkcyjnym
(choćby z powodu konieczności zachowania wstecznej zgodności). Jeśli
już przyrównywać, to Scala do F#. Myślę jednak, że dobrze zdajesz
sobie sprawę, że na upowszechnienie się programowania funkcyjnego do
poziomu języków deklaratywnych przyjdzie nam poczekać jeszcze z 15
lat. Urok Java (technologii, nie języka) polega tym jednak, że i
Scala, i Java, i JRuby, i Groovie działa na JVM, którą mogę uruchomić
na setkach platform sprzętowych i OS. Co mi pozostaje przymierzając
się do C#, czy F#, czy szerzej .NET ? Windows. No comments.
Ad 2.
Postęp jaki wniósł Spring jest niedoprzecenienia. Nie polega jednak na
tym, że autorzy Spring'a wymyślili coś nowego, ale na UPOWSZECHNIENIU
takich technik i wzorców, jak Dependency Injection (które z kolei
ułatwia testowanie, którego wzrost znaczenia jest w ciągu paru
ostatnich lat jest bardzo dostrzegalny), MVC, czy Aspect Oriented
Programming. Śmiem także twierdzić, że OSGi nie przebiłoby się do
obecnej pozycji "gorącej technologii przyszłości", gdyby nie projekt
Spring-DM rozwijany przez SpringSource, BEA i Oracle. Siła nośności
Spring Framework jest po prostu dzisiaj ogromna...
Ad 3
OSGi nie zostało wymyślone po to, aby móc uruchamiać wiele aplikacji w
ramach JVM. Tym zagadnieniem zajmuje się technologia zwana Java
Isolation (m.in. tutaj http://jcp.org/en/jsr/detail?id=121). OSGi ma
pomóc w kilku zagadnieniach:
- jak zwiększyć dynamiczność aplikacji Java, m.in. poprzez możliwość
uruchamiania modułów i usług bez restartu JVM (łatwo się mówi, ale
pociąga to za sobą cały bagaż problemów do rozwiązania - zależności,
wersjonowanie, security, ...). W zasadzie też powinienem napisać
"aplikacji JVM" zamiast "aplikacji Java", bo od pewnego czasu widać
bardzo dynamiczny rozwój wielu języków działających "na
JVM" (najbardziej popularne i przyszłościowe wymieniłem wcześniej). Po
prostu technologia Java to wszystko, co działa na JVM (czyli PHP na
JVM także).
- jak wzbogacić model ładowania klas (classloading) w JVM. Ten model,
który opisuje specyfikacja JVM wymaga już po prostu unowocześnienia
(znowu łatwo się mówi, ale takie zagadnienia jak zależności i
wersjonowanie są tutaj wyjątkowo trudne do kompleksowego rozwiązania,
zachowując przy tym zgodność wstecz). Bez takiego wsparcia jakie daje
OSGi trudno jest np. zapewnić równoczesne działanie w JVM wielu
wersji tych samych klas (oraz odpowiednich wersji klas, których te
klasy wymagają, itd.).
- jak wzbogacić modularyzację aplikacji na JVM - obok tego co jest w
tej chwili (klasy, pakiety), dodać także bundle, a przede wszystkim -
kluczowe w OSGi - usługi. Dzięki usługom można znacznie rozluźnić
zależności między komponentami i dodać tym zależnościom więcej
dynamizmu. Nacisk (orientacja) na usługi wymaga jednak poradzenia
sobie z paroma nowymi zagadnieniami - rejestrem usług,
wersjonowaniem, zależnościami, itd. Po paru dziesiątkach lat, myślę,
że większość z nas zdaje sobie sprawę, że zależności (dependencies)
to jest największa przeszkoda we wprowadzaniu zmian w oprogramowaniu.
Trzeba sobie jakoś z tym problemem radzić i w tym takie techniki jak
DI i technologie jak Spring, OSGi, czy Maven mają pomagać.
- ustandaryzować określone, często wykorzystywane usługi (ich
interfejsy), takie jak Log, czy HTTP. Tutaj OSGi ma dosyć podobny
pomysł jak J2SE/JSE i J2EE/JEE. Deweloper ma pewność, że będzie mógł
skorzystać z określonych usług na dowolnej platformie, zgodnej z daną
wersją OSGi.
Jak widzisz, w tym sensie OSGi w Enterprise ma wielki sens, bo jest
pomysłem na jeszcze lepszą modularyzację takich aplikacji i jeszcze
większy ich dynamizm. Na razie najwięcej pożytku OSGi da deweloperom
różnego rodzaju kontenerów aplikacyjnych (serwerów aplikacyjnych),
którzy dosłownie łamią sobie zęby m.in. na classloading'u
(wersjonowanie klas, widoczność klas, zależności). Z czasem (za rok ?
dwa ?) z zalet OSGi skorzystają (i to bez eksperymentowania, z jakim w
zasadzie wciąż mamy do czynienia dzisiaj) także deweloperzy i
administratorzy aplikacji enterprise: bezpieczna podmiana modułów
aplikacji na nową wersję, bezpieczne współistnienie wielu wersji
aplikacji i wielu wersji modułów, itp. Niektórzy dostawcy serwerów
aplikacyjnych oferują w tym zakresie pewne rozwiązania już dzisiaj,
ale wydaje się, że w znacznie bardziej kompleksowy sposób będzie to
możliwe po małżeństwie JEE i OSGi (a przy tym będzie to standardowy
sposób, bo za OSGi stoi wielu tuzów Java - od pewnego czasu nawet
Sun). Nie ma co jednak ukrywać, że to małżeństwo - choć pewne - to
jest pieśnią przyszłości (dwa ? trzy lata ?)...
Ad 6
Jakoś nie słyszałem o specjalnych narzekaniach linuksiarzy na Java
(setki tysięcy instalacji aplikacji serwerowych w Java na Linux też o
tym nie świadczą). Myślę, że ten model bindingów nie pasuje do Java,
bo przynajmniej w serwerowej Java raczej nie stosuje się podejścia
"jedna JVM w OS, wiele korzystających z niej aplikacji". Jest to
raczej "każdej aplikacja ma wbudowany własny JVM". Najłatwiej wtedy
zapanować nad aplikacją od strony utrzymaniowej (także większość
dostawców technologii certyfikuje od strony wsparcia technicznego
konkretne typy i wersje JVM).
Inna sprawa, że serwerowym rozwiązaniom na JVM system operacyjny jest
eeee... niepotrzebny i wręcz przeszkadza. Aplikacje serwerowe Java
(przyjmijmy J2EE/JEE) powinny korzystać w 100% z tego co im daje JVM.
Typowa serwerowa JVM potrzebuje od systemu operacyjnego TYLKO dostępu
do I/O (sieć i dyski), bo sama JVM zarządza pamięcią i dostępem do
procesorów (zarządzaniem wątkami). Optymistycznie mówiąc, jest to
jakieś 0.5 procent tego co ma w sobie system operacyjny. Reszta jest
w zasadzie hmm... nieużywana. Wystarczy zatem do JVM (a raczej pod
JVM) dodać niewielką warstwę obsługującą I/O (i parę innych
pomniejszych funkcjonalności) i można uruchamiać JVM bez OS
(bezpośrednio na sprzęcie - bare metal). Oczywiście, dzisiaj
najprościej to zrobić wykorzystując wirtualizację (czyli uruchomienie
JVM następuje na "wirtualnym" sprzęcie - hypervisor, np. Xen, czy
VMware), bo ściągamy sobie z głowy tonę problemów związanych ze
sterownikami, itd. Jeszcze w BEA (teraz w Oracle) taka warstwa
została zrobiona (ma ok. 150 tys. linii kodu, ok. 2MB, bo zostały
dołożone narzędzia diagnostyczne - np. SSH i klient Syslog - oraz
trochę ciekawych optymalizacji). Fajnie to wygląda, bo zaraz po
bootowaniu maszyny (wirtualnej) pojawia się Java (zamiast ładowania
OS). A przy tym nie były wymagane ŻADNE modyfikacje po stronie JVM, a
tym bardziej działających na niej aplikacji (w tym tak złożonych jak
serwer aplikacyjny JEE).
W każdym razie zmierzam do tego, że spekulując może nie jest nam już
potrzebny system operacyjny ? Albo: JVM pełni rolę systemu
operacyjnego dla aplikacji. Zwłaszcza, że takie sprawy jak GC (w tym
determinizm Java) oraz masę optymalizacji znacznie łatwiej
zaimplementować w JVM, gdy wiemy, że OS "nie namiesza". Absolutnie
jest to droga do poszukiwania jeszcze większej wydajności aplikacji
na JVM.
Ad 7
Nie nazywałbym closures "pierdołami" (zwłaszcza jeśli przywołałeś F#),
bo gdy wreszcie trafią do Java będzie to chyba najistotniejsze
rozszerzenie Java od jej początków. Jeśli chce się z nich korzystać w
JVM teraz, to warto zwrócić się w stronę takich języków jak Ruby (i
jego implementacji na JVM - JRuby), Scala czy Groovie. Korzystający ze
Spring'a mają tutaj nawet "bezpieczniejszą" ścieżkę, bo można
zdecydować o implementacji wybranych komponentów (bean'ów) w
najbardziej do tego dopasowanym języku, nie naruszając przy tym
"konstrukcji" reszty aplikacji.
Co do programowania równoległego, STM (zakładam, że chodziło Ci o
Software Transactional Memory - http://en.wikipedia.org/wiki/Software_transactional_memory),
to takie prace także są mocno prowadzone. Największe benefity Java 5
i 6, to właśnie znacznie lepsze wbudowane kolekcje współbieżne.
Spodziewałbym się także, że STM największą popularność zdobędzie
właśnie na JVM (zresztą, strzelam, że nie będzie to Software TM, ale
raczej hybrydowe Software+Hardware TM - czy wspominałem, że Intel
jest jedną z firm mocno zaangażowanych w Java ?). Zauważ także, że
wielu twórców rozwijających języki dynamiczne i funkcjonalne (np.
JRuby i Scala) specjalnie orientuje się na JVM, bo DOKŁADNIE dzięki
temu mogą skorzystać z mechanizmów obsługi wątków, zrównoleglania,
itd. jakie daje im JVM (o wysokim poziomie przenośności nie wspomnę).
Wielkim plusem Java jest to, że są setki implementacji JVM,
budowanych pod różnym kątem (klienckie, serwerowe, dla określonych
platform, open source, itd) i właśnie obsługą specyficznych
funkcjonalności (np. obsługą Transactional Memory) ich autorzy chcą
się wyróżnić. Można oczywiście także czekać, aż jedyny dostawca CLR
zaimplementuje (znowu jako jedyny) takie funkcjonalności, z których w
dodatku będzie można skorzystać na tylko JEDNEJ platformie...
Powtórzę zatem za wieloma osobami, że największy wkład Java leży nie w
języku, ale w maszynie wirtualnej.
Reasumując: przyszłość Java wygląda bardziej różowo niż wielu innych
technologii, q.e.d. :-)
Pozdrawiam,
Waldek Kot
PS
Witaj Michale w klubie PDP ("piszących długie posty") :-)