"Teoretic inseamna ca ar trebui sa mearga cu cititorul de ecran, iar daca ar fi vreun utilizator interesat de un programel in Java pe Linux, mai mult ca sigur ca s-ar descurca sa urmeze tot felul de pasi, altfel ar fi utilizator de Windows sau Mac.".
Teoretic, ca bine zici.

Intr-adevar, daca exista Java Access Bridge si pentru Linux, inseamna ca el face programele care folosesc SWING accesibile, atat doar ca si Orca trebuie sa poata colabora cu Java Access Bridge.
Nu e problema ca un utilizator de Linux nu s-ar descurca, insa la fel cum era cazul instalarii Java Access Bridge sub Windows in trecut, lua destul timp si dadea batai de cap.
"Am citit aici niste pasi pentru a avea JAB pe Linux, nu stiud aca sunt cei care ar putea duce la ceva bun.".
Gasisem si eu acea pagina, insa am trecut peste ea fiindca am vazut ca vorbea despre Java 6, or eu tocmai instalasem Java 7, asta mai ales ca din ultimele versiuni de Java s-au introdus niste modificari in ceea ce priveste modul de instalare al Java Access Bridge. Asta sub Windows, dar ma gandeam ca poate ca o fi ceva asemanator si sub Linux.
Totusi, se pare ca nu prea exista nici o legatura intre Java pentru Windows, Mac si Linux. Pentru Mac nu e nevoie deloc de JAB. Sub Windows JAB se instaleaza automat, iar sub Linux se pare ca trebuie instalat manual.
De fapt, o problema generala pentru Linux este faptul ca nu prea suporta cu draga inima programele proprietar cum este cazul Oracle Java, asa ca pentru a le instala este aproape intotdeauna suficient de complicat pentru a te face sa vrei sa instalezi o alta versiune, care e cu sursa deschisa.
Pentru publicul larg in general asta nu e o problema, dar pentru orbi poate fi, fiindca creatorii de programe open source sunt extraordinari, insa in general lor nu prea le pasa de problemele orbilor, ci merg pe principiul "daca nu iti place, fa tu imbunatatirile de care ai nevoie, fiindca codul este liber".
"Oricum am lua-o, faptul de a avea un singur fisier care acelasi sa ruleze un program pe toate cele 3 sisteme de operare, inseamna foarte mult.".
Evident, acesta este principalul avantaj al unei masini virtuale ca JVM, si de aceea a fost copiat si de altii, ca in cazul DotNet. Mare pacat ca Microsoft nu este deloc interesat ca DotNet sa poata fi folosit si pe alte platforme decat Windows.
JVM este si super optimizat si poate fi folosit de multe alte limbaje in afara de Java.
"Pana la urma se pare ca merge binisor, nu la fel de vioi la apasarea unui tab ca un program in C++ cu Windows API, dar suficient daca e un calculator cat de cat din zilele noastre.".
Java este intr-adevar un elefant care consuma multe resurse, insa faptul ca interfata nu este atat de responsiva se datoreaza bibliotecii SWING, nu limbajului Java.
Daca folosesti SWT in loc de SWING, interfata este mai responsiva iar pentru utilizatorii de tastatura este mult mai placut de lucrat.
Pentru cele 3 sisteme de operare cred ca distributia programelor care folosesc SWT nu este cu mult mai complicata, fiindca trebuie doar sa adaugi in kitul programului biblioteca respectiva, care in cazul Windows este un fisier .dll.
Dar e drept, asta are dezavantajul ca trebuie sa creezi cate un kit de instalare pentru fiecare sistem de operare in parte.
"Si ca tot s-a reluat subiectul, am facut si un mic test din care am dedus ca intr-adevar, la simple operatii matematice Java este de aproximativ 1,5 ori mai lent ca C++."
Java foloseste o multime de optimizari ca sa ruleze cat de rapid posibil, insa din acest motiv consuma foarte multe resurse si cand nu este nevoie.
Din acest motiv nu este relevanta o comparatie cu C doar in ceea ce priveste viteza, fiindca ar trebui comparata de exemplu si memoria consumata pentru a face acelasi lucru.
Mai demult am discutat cu cineva despre viteza unor limbaje de programare si am facut niste teste cu generarea unui sir Fibonacci, ca o metoda clasica de testare.
In C a iesit foarte rapid, evident. In Java a iesit daca mai tin bine minte mai rapid decat in C. Am facut si un test in Perl dar a iesit extrem de lent. Atunci am apelat in script si modulul Memoize si cu doar vre-o doua linii de cod adaugate in plus, programul in Perl a iesit super rapid, mult mai rapid decat cel in C si cel in Java.
Doar ca asta nu inseamna ca Perl este mai rapid decat C, fiindca doar e facut in C, la fel ca Java.
Atat doar ca modulul Memoize facea niste optimizari care il facea sa ruleze mult mai rapid, dar bineinteles, programul consuma mai multa memorie.
In acel exemplu asta nu conta, fiindca programul termina de rulat in mai putin de o secunda indiferent pentru ce numar Fibonacci se faceau calculele, dar in cazul programelor reale, conteaza si memoria.
Java foloseste anumite optimizari just in time, in mod implicit, asa ca optimizeaza multe calcule, in timp ce in alte limbaje, inclusiv C, acele optimizari trebuie facute manual.
Dezavantajul este ca ele trebuie facute manual, dar avantajul este ca daca de cele mai multe ori nu este nevoie de astfel de optimizari, programele in limbajele respective nici nu consuma degeaba atat de multe resurse.
In cazul modulului Memoize optimizarile constau in evitarea unor calcule care s-au mai facut o data, si salvarea rezultatelor calculelor intermediare in memorie, si apelarea lor directa cand trebuie facute din nou aceleasi operatii in loc sa se mai faca inca o data. Probabil ca astfel de optimizari foloseste si Java si din acest motiv pare ca este atat de rapid.
In ceea ce priveste diferentele de viteza intre diferite metode de randomizare, trebuie tinut cont si de cat de aleatore sunt de fapt rezultatele.
Nu ma pricep la domeniul randomizarii, dar mi-a parut destul de ciudat cand am inteles ca unele numere aleatore nu sunt suficient de aleatoare,, si ca din acest motiv pot aparea probleme. Cine stie, probabil ca generarea unor numere cu adevarat aleatore ia mai mult timp...