Do świata w pełni obiektowego, czyli przesiadka na Javę

Swoją naukę programowania zaczynałem od PHP. Byłbym w stanie napisać prostego CMS'a, jakby mi się chciało napisać jakiś szablon do tego. Później szkoła zmusiła mnie do nauki Pascala. Strata czasu, ale poznałem prawdziwe trudności programowania: deklarowanie zmiennych razem z typami, sztywne tablice. Później był C++ i C. Początkowo bardziej C++, później jednak zacząłem używać Standardowej Biblioteki C (jest o wiele szybsza i daje większą władzę). Teraz jednak przesiadłem się (oczywiście nie całkowicie) na Javę.

Poniższy artykuł można potraktować jako poradnik do Javy dla programistów C++.

Środowisko

Za środowisko programistyczne wybrałem NetBeans, aktualna wersja 6.9. Muszę przyznać, że to dość łatwe i wygodne środowisko. Zastąpiło miejsce Code::Blocks'a dla małych projekcików C++ (tzn. teraz on mi służy za edytor, a terminal za kompilator, tak jak dotąd), a dla dużych C++owych projektów nadal QtCreator (ze względu na Designera, oraz qmake, który działa też z moimi innymi platformami, czyli S60 i Windows Mobile). Do samego środowiska nie mam prawie żadnych zastrzeżeń. Nie da się powiększyć czcionki za pomocą CTRL+rolka myszy. Niewielka wada. Drugą wadą jest długie wczytywanie listy metod klas.

Ale za to NetBeans sam poprawia niektóre błędy, sam wyszukuje brakujących "nagłówków" (tak to nazwać?). Szczególnie przydatne dla początkującego. W każdym razie nie szukajcie innego środowiska na początek.

Pisanie w Javie zacząłem od razu od troszkę większego projektu niż Hello World, czy konsolowego kalkulatora, a mianowicie klon gry Blocks Out - starego przestrzennego Tetrisa. Zdecydowałem się na taki projekt, bo znam już OpenGL'a, a w Javie można użyć biblioteki JOGL, która jest "bindem" OpenGLa do Javy, a nie znam jeszcze GUI oferowanego przez Javę (co prawda jest projekt QtJambi - Qt dla Javy, ale trochę zbyt ciężki).

Wrażenia

Składnia języka

Wcześniej z Javą miałem styczność tylko w szkole, ale sam szablon aplikacji jest generowany, wystarczyło tylko funkcję main uzupełnić i zadanie zrobione. Ten projekt wymagał trochę więcej niż uzupełnienie jednej funkcji, co niczym prawie nie różni się od C++. Pierwsze spostrzeżenia odnośnie składni:

1. [0] Jeden plik .java powinien posiadać co najwyżej jedną klasę. Tu nie było aż tak trudno: Qt też tego wymagało. Nawet i lepiej: jest czytelniej. 2. [+] KLAMRY!! Jak w C++. Próbowałem pisać w Pythonie, gdzie nie ma ani słów kluczowych jak w Pascalu, ani klamer jak w C i powiem że może i wygląda estetycznie, to pisze się (przynajmniej mi, kwesta przyzwyczajenia może) niewygodnie. Klamry to zdecydowanie zaleta. 3. [+] Pętle, warunki, przełączniki, typy, niemal wszystko tak samo jak w C++ 4. [+] Nie jest wymagane deklarowanie wszystkiego w klasie po kolei: może być najpierw metoda wykorzystująca jakąś zmienną (np. w linii 20), a deklaracja tej zmiennej dalej (np. w linii 70). Niestety brak możliwości predefinicji, jak w C++, ale można zakomentować, żeby kompilator na nią nie patrzył [0] 5. [+] Nie trzeba do przesady dbać o hermetyczność (fajnie że po 2 latach programowania dowiedziałem się jak to się fachowo nazywa:) ). Jeżeli coś ma być publiczne, to PRZED deklaracją pisze się public, a jeśli nie ma być publiczna, to się nie pisze. 6. [-] Destruktory!! GDZIE ONE SĄ! To pewnie przyzwyczajenia i nawyki, ale strasznie mi brakuje klasycznych destruktorów - metod, które się wykonują przy usuwaniu obiektu. Trzeba się męczyć z metodą finalize(), przy której NetBeans ciągle się czepia, ale wystarczy posłusznie kliknąć na ostrzeżenia i wybrać te opcje, żeby sam naprawił. 7. [0] Garbage Collector - Zaleta? Wada? Dla kogoś, kto tak długo pisał w C++ raczej wada. W C++ programista jest "Panem Życia i Śmierci" każdego obiektu, każdej zmiennej. W Javie panuje względny chaos - programista tworzy, nic nie usuwa. Lata za nim taki GC i sprząta po nim to, czemu przypisze wartość null. Ma to jednak zaletę: nic nie będzie w pamięci nieużywane [+]. Wolałbym jednak ręcznie uruchomić destruktor. 8. [0] Słowa kluczowe się trochę różnią od tych stosowanych w C++. Przykładowo static jest funkcja, ale nie zmienna. Zmienna jest final. Trochę dokuczliwe. 9. [0] Na poziomie składni to nie robi różnicy: słowo kluczowe import, zamiast include. 10. [0] Typ boolean zamiast bool. W Javie 7-znakowy boolean wypada on trochę dziwnie wśród 3-znakowych intów, 4-znakowych floatów. Nie można sobie nawet przemianować jak w C++ przez typedef, lub #define. 11. [-] Brak preprocesora - nie można sobie zdefiniować jakiejś procedurki. A szkoda :( 12. [0] Wszystko jest referencją - czasem zaleta, czasem wada. Samoistnie występująca liczba tworzy nowy obiekt typu int. 13. [-] Surowość wobec rzutowania - Java nie pozwoli na nieumyślne rzutowanie Double do Float z powodu utraty precyzji. 14. [--] Brak władzy absolutnej. Podwójny minus. tab+n nie oznacza tab[n], co nieco komplikuje sprawę z OpenGL'em. Obiekt tab jest obiektem tablicy (właściwie to jej referencją), a nie wskaźnikiem do pierwszego elementu 15. [-] Funkcja main() wewnątrz klasy. Trochę niezbyt wygodne, tym bardziej że jak na razie to tam mam tylko utworzenie nowego obiektu. 16. [+] Dużo gotowych rozwiązań (takich jak String)

System rozszerzeń klas i interfejsów

W C++ są tylko klasy. W Javie są jeszcze interfejsy. W różnice się jeszcze nie zagłębiałem, ale Java oferuje standardowo kilka interfejsów, takie jak obsługa zdarzeń klawiatury (keyPressed, keyRelease, keyTyped), myszy, timery itd.

Zarządzanie projektem

Zarządzanie projektem w Javie przy pomocy NetBeansa okazało się być wyjątkowo łatwe! Do mojego projektu musiałem użyć biblioteki JOGL, aby móc korzystać z grafiki 3D. Pierwszym problemem było: jak dodać te pliki .jar jako biblioteki do projektu... Wystarczyło kliknąć prawym na "Libraries" w drzewie Projects i wybrać "Add JAR/Folder" i dodać te pliki. Po zbudowaniu projektu do folderu z .jarem trzeba jeszcze dodać DLLki dla Windowsa, oraz .so i aktywator dla Linuksa.

Po dodaniu odpowiednich bibliotek mogłem się dać do roboty. System import okazał się być bardzo wygodny, wygodniejszy od include'ów. Poza tym: pliki .java dzieli się w tzw. paczki. Jeden plik zawiera max jedną klasę, paczka może mieć kilka plików, a każdy z tych plików automatycznie importuje klasy z "sąsiednich" plików. Każdy powinien się zacząć od słowa kluczowego package i nazwy paczki, do której należy. NetBeans zajmie się resztą (przeniesie, po naciśnięciu na ostrzeżenie i wybraniu "Move class to correct folder"). Niestety brak zmiennych globalnych. Trochę męczące. Zatem podsumowanie:

[++] Genialny system zarządzania projektem - dzielenie w paczki, importowanie [-] Brak zmiennych globalnych [0] Nie kopiuje automatycznie bibliotek [0] Pliki o rozszerzeniu .jar to jednocześnie pliki końcowe (jak .exe), oraz jak nieskonsolidowane biblioteki (.a, .lib) z wbudowanymi nagłówkami (.h) [+] "obiekt" super - tzn. obiekt klasy, którą rozszerza aktualna klasa. Nie wiem jak to nazwać: wywołuje jakby metodę rodzica klasy. Musi być jako pierwsza w metodzie.

Podsumowanie

Przejście z C++ do Javy aż takie trudne nie jest. Wystarczy przyzwyczaić się do nowych reguł. Stworzenie konsolowej aplikacji nie powinno stanowić problemu dla piszącego w C, gdyż jest funkcja printf, będąca w System.out (a zatem: System.out.printf(String, ...);), która działa identycznie jak ta z C

TerDimTris

A teraz odnośnie mojego projektu: Aplikacja wykonana w Javie, powinna działać na Windowsie i Unixach bez problemu. Używa shaderów GLSL, które nie są moim dziełem (trochę je tylko zmodyfikowałem). Zamierzam ją skończyć, jednak po dwóch dniach jest już w miarę grywalna. Nazwę wziąłem ze skrótów z j. łacińskiego: Ter - trój, Dim - wymiar, Tris - to akurat z teTris'a. Gra z pozoru łatwa - bo te same klocki co w 2d (na razie), a 3 wymiary, ale im więcej, tym trudniej się połapać (ułatwię to, bo na razie jeszcze nie zbija się rzędów) i jest trudniejsza.

Najwięcej kłopotów miałem z rzucanymi wyjątkami z nieznanych powodów i systemem kolizji (bardzo drobny błąd kosztował mnie kilka godzin szukania problemu).

Download (użytkownicy Linuksa powinni skopiować pliki .so do folderów z bilbiotekami do Javy, u mnie na ubu działa bez problemu, ale nie pamiętam gdzie to konkretnie skopiowałem, Użytkownicy Maca powinni poszukać na stronie JOGLa najnowszych bibliotek)

Sterowanie: *Strzałki - poruszanie klockiem *Numpad 1/3, 4/6, 2/8 - obracanie klockiem we wszystkich 3 wymiarach *Spacja - przyspieszenie opadania *r - wyłączenie "bujania się" kamery

Wymagania (na oko, razem z Maszyną): *64 MB RAM *500 MHz *Grafika 64 MB z Shader Model 1.0 (DX 9) *JRE

Oryginalny wpis, oraz inne na moim blogu