Dlaczego (nie) przepraszać się z Javą…

Kiedyś, w bardzo zamierzchłych czasach programowałem trochę w Javie. Takie tam proste aplikacje – w celach poznawczych. Było całkiem sympatycznie, nie zaprzeczę. Potem wziąłem się za .NET no i (delikatnie rzecz ujmując) bardziej mi się spodobał :) Niedawne okoliczności zmusiły mnie po latach, znów do użycia Javy.

Otóż pewnego słonecznego dnia moja cudowna Dziewczyna poprosiła mnie o napisanie dla niej słownika polsko-rosyjskiego na komórkę. Wszystko świetnie, poczułem się takim potrzebnym mężczyzną i w ogóle, ale… Przecież co do aplikacji na komórkę, to za bardzo nie ma wyboru w sprawie technologii – musiałem przypomnieć sobie Javę (a mój kochany .NET :(). Ściągnąłem więc wszystko, co deweloperowi potrzebne – JDK 6.0 + NetBeans 6.1 i przystąpiłem do pracy. Moje pierwsze spostrzeżenie – NetBeans, które uważa się za najlepsze IDE do Javy (i nie tylko) nie działa tak dobrze jak VS (od szybkości, aż po funkcjonalność). A może to kwestia przyzwyczajenia? W każdym razie na uwagę zasługuje fakt, iż NetBeans przygotował mi sam przykładową aplikację na komórki i co lepsze – pozwolił ją rozwijać na zasadzie przeciągania kontrolek z toolboksa (oczywiście do pewnego stopnia). Aplikacja taka kompilowała się bez problemu i odpalała na emulatorze komórki (bardzo fajna sprawa!). Na razie wszystko pięknie.. ale to już chyba koniec pozytywnych doznań. Intuicyjnie klepałem kod, do momentu aż się dało, potem pozostała dokumentacja i.. no cóż, przez wiele lat, niewiele się w tej kwestii zmieniło. Dokumentacja Javy jest rzeczowa, czasem aż za bardzo. Brakuje w niej przykładów i objaśnień. Większość rzeczy musiałem googlać. Jakoś to szło w każdym razie. Plik słownika był dosyć duży – 2.5 MB tekstu w UTF-ie. Powstał więc problem jak go przeszukiwać.. postanowiłem szukać linia po linii – buforowanie całości nie wchodziło w grę (komórki jednak nie mają takiej wielkiej pamięci). Na emulatorze wynik niezły – kila sekund i są wyniki. Postanowiłem więc zrobić test na komórce… wyników doczekałem się po kilku (!) minutach. Chciałem więc zmienić metodę przeszukiwania (nie szukać słowa jako substring tylko jako całego). I tutaj trafiłem na coś, co mnie prawdziwie zirytowało – w J2ME nie ma dużej ilości klas i metod, które są standardowo. Rozumiem, że pewnych być nie może, ale żeby robić cięcia w klasach i metodach służących do operacji na stringach? Przez to musiałem tworzyć własne, bądź stosować pewne sztuczki. Ale to jeszcze nie było najgorsze… Moja wytrzymałość przeżyła kryzys, gdy okazało się, że stringi „abakus” i „abakus” nie są równe! Porównywałem je wszystkimi metodami (nie, nie używając == ;)) – compareTo, equals – zawsze zwracały false. Czemu? Nie wiem. Wypisywałem te słowa na ekranie, robiłem wszystko co się dało, ale słowo wczytane z pliku tekstowego NIGDY nie było równe słowie wpisywanym w programie. Przypuszczam, że wynikało to z pewnych problemów z kodowaniem, jednak rozwiązania nie znalazłem Po walce z programem przez trzy nocne godziny – darowałem sobie. Zostało tak jak było. Przy okazji dodam, że debugowanie aplikacji mobilnych jest.. średnio przyjemne.
W późniejszym czasie dowiedziałem się, że wyszukiwanie słów można było przyśpieszyć dzieląc słownik na 40 mniejszych i buforując całe części.. Jednak ta informacja dotarła do mnie za późno. Problem z porównywaniem stringów jednak pozostał nierozwiązany.. i chyba nie chce go rozwiązywać.

W tym miejscu pragnę wyrazić swój żal, iż większość urządzeń mobilnych wyposażonych jest w Javę, a nie w .NET… Cóż, czasem widać trzeba się przeprosić z Javą, zawsze to przyjemniejsze niż przymus pisania sterowników w ASM-ie :)

A może ktoś zrobi port .NET-a w Javie?;)