Miért nem szeretem a Java-t?

A Java megjelenésekor forradalmi úttörő volt, aki mellett szépen-lassan elment a világ, így mára egy elavult őskövület lett, amit nem igazán szeretnek sokan. Köztük én sem szeretem. Ebben az írásomban C# programozóként fejtem ki a véleményemet arról, hogy mi is rossz a Java-ban.

A hardcore java4ever programozóktól annyit kérnék, hogy tartsátok tiszteletben azt, hogy ez egy vélemény. Ezzel nem kell egyetérteni. Viszont a kommentek között kerüljük a személyeskedést.

Igyekszem összefogó képet adni a Java problémáiról és nem csak annyit írni, hogy sz*r az egész, de ez egy több szintű probléma, mondhatjuk, hogy a páciens több sebből vérzik.

A nyelv

A Java nyelv legnagyobb problémája, hogy a megalkotása óta csiga tempóban fejlődött, nem igen voltak radikális újítások. Persze a megfontoltság is jó, azonban nem egy olyan világban élünk, ami lassan halad előre. Így szegény Java nyelv leginkább egy kőbaltához hasonlít az űrkorszakban. Persze egy kőbaltával is meg lehet sok mindent építeni, csak éppen nem a leghatékonyabb eszköz például űrhajó építésre. De hogy ne csak a levegőbe beszéljek:

  • Nincsenek property-k
    Ez egy súlyos nyelvi tervezési hiba. Az Object Pascal ezt már 1993-ban tudta. A Java meg 1998-ban jött ki. Azóta eltelt 17 év. Miért nem lehetett ezt implementálni?
  • Nincs operátor átdefiniálás
    Szintén súlyos hiba szerintem. Persze lehet az operátor átdefiniálást rosszul is használni, de lehetett volna egy arany középutat választani, mint C# esetén
  • Szálak
    Kb 10 éve minden arról szól, hogy több szálon fusson, meg több mag támogatása. Erre itt van a szerencsétlen Java a szálkezelésével, ami a 1990-es években ragadt. Ha egy-két szálat kell kezelned, akkor még tűrhető, de mondjuk 20-30 esetén már frusztráló az egész. Erre kellett volna valami nyelvi kiegészítést behozni.
  • Nincsenek bővítő metódusok
    A bővítő metódusok (Extension methoods) a C# egyik legjobb tulajdonsága. Persze ezt is lehet rosszul használni, de mennyivel kényelmesebb egy függvényt megírni bővítésképpen, mint egy osztályt örököltetni és kiegészíteni a szükséges statikus függvénnyel. És akkor feltételeztem azt, hogy tudod örököltetni az osztályt, de ha nem, akkor bizony szívás.
  • Lambda kifejezések
    A Linq-hoz képest a Java Lambda kifejezései igencsak limitáltak finoman fogalmazva. Szóval ami C# esetén elintézhető 1 sorban, az Java esetén több sor lesz. Ez rontja a  kód átláthatóságát, és az is biztos, hogy nem lesz annyira gyors, mint az egy soros optimalizált művelet.
  • Konzolról beolvasás
    Komolyan melyik idióta tervező felejtette el egyszerűen implementálni a konzolról beolvasás műveletet? Persze sokkal, de sokkal logikusabb ezt megvalósítani:

    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    br.readLine();

A futtatókörnyezet

  • Biztonságilag egy vicc
    Undorító hogy kb hetente frissíteni kell a legújabb verzióra, mert valaki anno nem volt képes rendesen megírni a futtatókörnyezetet. És a legjobb fail, hogy frissítést követően is rinyálni fog a böngésződ, mivel a frissítés után már azonnal van 10 biztonsági hiba az új verzióban (legalább).
  • Implementációk
    A nyílt forráskód szépsége, hogy több implementáció is van. Ez nem jelentene gondot, ha lenne egy hivatalos verzió, ami rendben lenne a platformok többségén. Mert ugye ott az Oracle-féle “sz*runk bele az egészbe” JRE Windowsra, Linux-on meg Open JDK van. Ezek többé-kevésbé kompatibilisek egymással, de ha belefutsz egy olyan programba, ami nem fut Open JDK alatt, akkor bizony szívni fogsz a telepítéssel, ha csak nem vagy Level 99 Epic Linux Hacker enchantolt billentyűzettel.
  • Tetű lassú
    Az egész futtató környezet olyan, mintha szándékosan kéziféknek tervezték volna. Nem akarok bele menni a .jar fájlok felépítésébe és abba, hogy miért sz*r a JVM felépítése, mivel a Google elmagyarázta ezt anno, hogy miért is csináltak teljesen új Java VM-et Android alá. De érthetőség kedvéért egy hétköznapi példa: többek között a Java tervezési hibáiból adódóan fut 100%-os processzor használat mellett a Minecraft kb bármilyen gépen.
  • 64 bit támogatása
    Működik is meg nem is. A gond az, hogy nem egybecsomagolva jön ám a x64 és x86 változat a futtatókörnyezetből. Az túl logikus lenne. Így telepíts 2x, ha értelmes sebességet akarsz elérni 64 bites Windows rendszereden. És akkor persze még hekkeld át az alapértelmezett futtatókörnyezet precedenciát, hogy ténylegesen megpróbáljon az alkalmazásod futni 64 biten. Ha sikerrel jártál, akkor bizony a két környezetet külön-külön kell frissítened, természetesen manuálisan. Mert túl nagy elvárás 2015-ben, hogy a frissítő szépen csendben automatikusan frissítsen…

Fejlesztő eszközök

Számos IDE van Java nyelvhez, de igazából egyik eszköz esetén sem éreztem azt, hogy az eszköz van értem és nem én vagyok az eszközért. Igaz, nem próbáltam végig az összes elérhető fejlesztő eszközt csak a NetBeanst és az Eclipse-t. Mindkét program esetén azt éreztem, hogy fényévekkel le vannak maradva a Visual Studio-hoz képest. Intelligens kód kiegészítés csak nyomokban található meg, így nagyon frankó a sok tevepúpos osztálynév begépelése többé-kevésbé manuálisan…

A dokumentáció meglétére nem lehet panasz, mert van, csak éppen nem igen kereshető és megjelenésileg annyira a 1990-es évek elejét idézi, hogy az már fáj. Így kb bármilyen megoldás terén jobban járunk egy StackOverflow kereséssel.

Összefoglalás

A Java nem lenne rossz, de egy masszív vérfrissítés kellene neki. Ez pedig nem fog megtörténni az Oracle “sz*runk az egészre magasról” mentalitásával. Ebből adódóan a Java megmarad a szerverek világában speciális alkalmazások fejlesztésére, meg Android fejlesztésre. Igazából rég kihaló programozási nyelv lenne, ha nem jött volna az Android.

A végére kihagyhatatlan volt ez a kép 🙂

BawtCVX