Web3D

Java nie jest przeznaczona wyłącznie do zastosowań internetowych – z powodzeniem można w tym języku tworzyć aplikacje lokalne. Jednak ze względu na swoja strukturę oraz założenia które przyświecały jej twórcom, doskonale nadaje się do wykorzystania w sieci. Kod źródłowy programów napisanych w Javie jest kompilowany do uniwersalnego formatu – poleceń dla maszyny wirtualnej. Tak skompilowany program jest następnie wykonywany przez interpreter Javy. Dopiero interpreter przekłada polecenia maszyny wirtualnej na instrukcje niskiego poziomu, charakterystyczne dla danej platformy, na której uruchamiana jest aplikacja. Główną zaletą takiego rozwiązania jest fakt, że raz napisany kod jest przenośny. Program, może być uruchamiany na dowolnej platformie, pod warunkiem, że istnieje dla niej interpreter Javy. Założenie takie jest szczególnie istotne, jeśli wziąć pod uwagę aplikacje osadzone na stronach internetowych, które mogą być przecież oglądane pod różnymi systemami operacyjnymi, na sprzęcie o rozmaitych architekturach.

O ile Java wywodzi się z potrzeby tworzenia małych aplikacji webowych (link), a jej związek z internetem i zastosowaniami sieciowymi był od początku pielęgnowany, to wykorzystanie języka do tworzenia trójwymiarowej grafiki było traktowane marginalnie. Java posiada wydajny komponent Canvas, który umożliwia generowania obrazów 2D, jednak klasy służące do kompleksowej obsługi obiektów 3D nigdy nie weszły do podstawowej dystrybucji. Interfejs programistyczny Java 3D rozwijany jest jako niezależny projekt pod opieka Sun. Co za tym idzie, wymaga on pobrania przed pierwszym użyciem. Podejście takie, a także prawie dwuletnia przerwa w pracy nad projektem (link), sprawiły, że na rynku pojawiły się inne konkurencyjne biblioteki – zarówno wyspecjalizowane, jak i bardziej uniwersalne.

Wszystkie rozwiązania które zostaną zaprezentowane korzystają naturalnie z dobrodziejstw, ale również podlegają ograniczeniom narzuconym przez Javę. Są to zatem technologie obiektowe, zazwyczaj wysokiego poziomu – pozwalające się skupić na logice aplikacji, a nie na niuansach związanych ze sprzętem i sposobem wyświetlania na nim obrazów. W teorii, wszystkie aplikacje, napisane z dodatkiem jednego z wybranych API, powinny być uruchamiane na każdym sprzęcie wyposażonym w wirtualna maszynę Javy w odpowiedniej wersji. Przedstawione biblioteki wspierają wersje środowiska, przeznaczona na urządzenia stacjonarne (Java Standard Edition). Urządzenia mobilne korzystają z Java ME (Micro Edition), która posiada osobne API do generowania grafiki 3D.

Pomimo tak ogromnych możliwości i bogatej oferty rozwiązań pomagających w dostarczeniu interaktywnej, trójwymiarowej grafiki, Java nie jest powszechnie wykorzystywaną technologią na stronach WWW. Pomijając kilka rozległych projektów takich jak Minecraft (link), Nord (link), czy Tribal Trouble (link), które równie dobrze mogłyby być niezależnymi od przeglądarki programami (i jako takie mogą być uruchomione), Javę na komercyjnych stronach internetowych spotyka się sporadycznie. Może to wynikać z kilku powodów.

Po pierwsze, załadowanie apletu zajmuje dużo czasu, szczególnie przy pierwszym uruchomieniu wirtualnej maszyny Java oraz kiedy występuje konieczność doładowania zewnętrznych bibliotek. Okres oczekiwania na uruchomienie apletu znacznie zmalał, w porównaniu do starszych wersji, wciąż jednak może trwać do kilkudziesięciu sekund.

Innym czynnikiem który może odstraszać autorów od publikacji swoich realizacji przy pomocy Javy, jest niska penetracja rynku. Według różnych badań, Wirtualna Maszyna Javy jest obecna na 65% (link) do 75% (link) komputerów stacjonarnych mających dostęp do internetu. To bardzo dużo w porównaniu do rozszerzeń, które użytkownik musi samodzielnie instalować, jednak zbyt mało dla twórców, którzy chcą używać Javy na przykład do umieszczania ozdobnych elementów nawigacyjnych lub reklam na stronie.

Istnieją również pewne uprzedzenia na temat Javy, które nie koniecznie są prawdziwe w odniesieniu do najnowszych wersji, ale były niebezpodstawne w początkach istnienia oprogramowania i zostały utrwalone w obiegowej opinii. Można tu wymienić bardzo niską stabilność i wydajność aplikacji, bardzo długi czas ładowania, a także brak kompatybilności między maszynami wirtualnymi wydawanymi przez różnych producentów, w szczególności problemy ze środowiskiem oferowanym przez Microsoft (link). Nie bez znaczenia, przede wszystkim w przypadku początkujących użytkowników, były niepokojące komunikaty towarzyszące uruchamianiu apletu.

Poza projektami które są na bieżąco rozwijane i szeroko wykorzystywane, w internecie można natrafić na ślady inicjatyw, które zostały zaniechane – co nie oznacza koniecznie, że nie nadają się do użytku Do grupy tej można zaliczyć Espresso3D (link) – wydajny engine z obsługa dźwięku i wykrywaniem kolizji, a także jView (link), służące do wizualizacji i działające jako aplikacja lokalna.

Osobną grupę stanowią rozwiązania, zapewniające dostęp niskiego poziomu, które ograniczają się do dwóch popularnych projektów: JOGL oraz LWJGL. W przeciwieństwie do opisanych poprzednio silników, które oferowały wyższy poziom uporządkowania danych (graf sceny), ta grupa daje programiście interfejs do bezpośredniej pracy z API OpenGL – zachowując w mniejszym lub większym stopniu jego struktury danych oraz poszczególne funkcje i sposoby działania. Zarówno JOGL, jak i LWJGL nie posiadają narzędzi ukierunkowanych na poszczególne typy aplikacji – są natomiast dobra bazą do tworzenia wysokopoziomowych engine’ów.

Oba API oprócz grafiki 3D, wspierają również interfejs OpenAL odpowiedzialny za obsługę dźwięku przestrzennego. Prostota LWJGL jest atrakcyjną cechą tego rozwiązania, podczas gdy JOGL wydaje się mieć odrobinę bardziej rozbudowaną warstwę abstrakcji. Oba jednak są zasadniczo bibliotekami pozwalającymi na komunikację między Javą, a OpenGL o podobnej wydajności oraz stopniu skomplikowania.