Po co nam Java? Czyli o tym, co znaczy słowo enterprise, o JVM i o muCommanderze

“Po co nam ta Java?”, “Ale po co ją stosować, jak w Ruby on Rails mogę to samo zrobić szybciej (czytaj: być bardziej wydajnym)?” – takie pytania koledzy stawiają mi coraz częściej. Odpowiadanie na nie nie jest zadaniem prostym. Przekonanie osoby negatywnie nastawionej, że Java może spokojnie, nie wadząc nikomu żyć w informatycznym ekosystemie – baaaa – nawet uzupełniać go, graniczy z cudem.

Oczywiście nie jestem w stanie dać pełnej odpowiedzi na pytanie “Po co nam Java?”. Nawet do tego nie pretenduję. Poruszę tylko trzy zagadnienia, które będą świadczyć, że jednak po coś nam ta Java jest potrzebna:

• zastosowania typu enterprise,
• przenośność platformy Javy (ang. cross-platform), o której się często zapomina (na przykładzie muCommandera),
• maszyna wirtualna Javy, czyli JVM.

Enterprise

Zacznijmy od magicznego słowa enterprise, z którym jest najwięcej problemu. Problemem jest zdefiniowanie, co oznacza aplikacja typu enterprise. Mało kto potrafi w ogóle powiedzieć, co to jest. Mówi się, że są to duże aplikacje, poważne, dla banków lub EAI itd. “No dobra, ale nadal co to znaczy? Przecież w Ruby on Rails też można takie aplikacje tworzyć.” – dostaniemy od razu odpowiedź. Zacznę więc od zdefiniowania terminu aplikacji enterprise (a tak na prawdę systemu rozproszonego), który po raz pierwszy na zajęciach na MIMUW-ie przedstawił mi Jacek Sroka. Otóż problemy, z jakimi się takiego typu aplikacje zmagają to:

• zdalne wywoływanie metod (ang. Remote Method Invocation),
• wielowątkowość (ang. Threading),
• współpraca z bazami danych i systemami spadkowymi (ang. Back-end integration),
• transakcje,
• równoważenie obciążenia (ang. Load balancing),
• płynne przejmowanie zadań od komponentów, które uległy awarii (ang. Transparent failover),
• czy stan serwera, który uległ awarii jest replikowany na inne serwery (ang. Clustering),
• uaktualnienia działającego systemu (ang. Dynamic redeployment),
• prowadzenie dziennika i audyt (ang. Logging and auditing),
• monitorowanie i administrowanie działającym systemem (ang. System management),
• luźne sprzężenie przy pomocy komunikatów (ang. Message-oriented middleware),
• tworzenie/niszczenie komponentów w zależności od obciążenia (ang. Component life cycle),
• pule zasobów (ang. Resource pooling),
• kontrola bezpieczeństwa na poziomie operacji (ang. Security),
• pamięć podręczna (and. Caching),
• …

(Wszystkie powyższe punkty pochodzą z notatek z wykładu Jacka Sroki)

Tym wszystkim zajmują się aplikacje typu enterprise. Czasem w sieci można znaleźć różne artykuły, o tym, że największe serwisy światowe nie są napisane w Javie. Wszystko to jednak statystyka i umiejętne posługiwanie się odpowiednimi przykładami. Pozostaje mi tylko powiedzieć, że nie jest to prawda. Java stoi za takimi serwisami jak Gmail, eBay, Google AdWords, FeedBurner, część Amazon, a z naszego polskiego podwórka to chociażby gazeta.pl, merlin.pl.

Przenośność platformy Javy

Nie zapominajmy o sztandarowym sloganie “Write once, run anywhere”, czyli program napisany w Javie będzie działał tak samo w różnych systemach operacyjnych (MacOS, Linux, Solaris, Windows). Ostatnio o tym sobie przypomniałem, kiedy szukałem menadżera plików dla MacOS podobnego do Total Commander (Windows) i Midnight Commander (konsola *nixowa). Wpadłem na program muCommander, czyli to czego szukałem i jeszcze napisany w Javie. Zobacz screenshot poniżej:

To jest właśnie cudowny przykład zastosowania Javy. Program działa tak samo na wszystkich platformach, a do tego obsługuje FTP, SFTP, SMB, NFS, standardowo obsługuje pliki ZIP, TAR, GZip, ISO/NRG. Jest super i jest całkowicie darmowy .

Poza tym dobrych aplikacji desktopowych napisanych w Javie jest więcej. Azureus. JAlbum. LimeWire. BlogBridge. O J2ME nie będę wspominał. Macie jeszcze jakieś dobre przykłady?

Maszyna wirtualna Javy, czyli JVM

Bodajże najważniejszym elementem platformy Java jest maszyna wirtualna, czyli JVM (ang. Java Virtual Machine). Pomimo swojej nazwy JVM nie jest w ogóle związana z językiem Java. Jest jedną z najbardziej zaawansowanych maszyn wirtualnych (obok CLR), a technologia HotSpot obala mit powolności całej platformy, który to strasznie i niesprawiedliwie za Javą się ciągnię. Koncepcja maszyny wirtualnej pewnie już nas nigdy nie opuści w przeciwieństwie do języka. Widać już pierwsze jaskółki:

• Sun otwarcie wspiera projekt JRuby (zatrudnienie dwóch czołowych programistów w 2006 r., praca nad bardzo dobrą wtyczką do Ruby’iego i Ruby on Rails dla NetBeans, wdrażanie aplikacji RoR na Glassfishu),
• pojawia się coraz więcej języków dynamicznych na JVM (Groovy, Jython),
• JVM zostanie wzbogacony o instrukcję invokedynamic w Javie 7 (JSR 292), która dramatycznie przyspieszy języki dynamiczne na JVM,
• powstają także setki innych języków na JVM, a najciekawszym z nich wydaje się Scala.

Widać, że nie ma co bez sensu kruszyć kopii między Ruby on Rails a Javą i tylko czerpać z obydwu rzeczy to, co najlepsze. Trzeba po prostu wybierać najlepsze narzędzia do wykonania pracy.

A Wam? Po co jest Java?