Mit gondoltok a Java programozási nyelvről?

szép volt jó volt, de kikopik

bár még van létjogosultsága, meg sok helyen használják, de főleg régebbi rendszerek, ha valaki újat tervez nem ezt veszi elő, max abban az esetben, ha a fejlesztő csapat erre van képezve

nagy projektek is használták, lásd teljesen önálló projektként minecraft

de több nagyobb cég webes kiszolgálója használ részben, vagy egészben még ilyet

ha ma akarnék programozást tanulni, akkor inkább más nyelvet választanék, a java is sokra képes, minden megtanulható, de akkor már valami piacképesebbet választanék

ha cross platformos dolgokat akarok, akkor C#, ha csak androidot, akkor kotlin (ami eléggé hasonlít a javara)

webre meg a PHP a vezető, de a node.js és C# szintén elég előkelő helyen van és még maradnak is

pythont webre nem használnám, de programozást tanulni és bizonyos projekteket megvalósítani hasznos lehet

de ha már scriptnyelvek, akkor a LUA-t is érdemes megemlíteni, bár ennek a felhasználási területe nem olyan óriási

Maga a Java platform alapvetően jó ötlet volt: legyen egy platformfüggetlen, köztes kódra forduló nyelv, ami aztán bárhol elfut, ahol van Java értelmező.

A valóság meg az - bár ez a fejlesztők "tehetségének" is köszönhető -, hogy ritka az, amelyik ugyanúgy elfut Windowson, Linuxon, meg mondjuk FreeBSD-n. Amióta meg kezdik hányni magukból folyamatosan a verziókat, a régieket meg mint műkincseket, menekítik el a nyilvánosság elől, azóta teljes a káosz. Írnak egy szoftvert Java 11-re, 17-en már nem fut, 8-on még nem... vagy pl. amikor a 7-es Javára megírt szoftver a 8-ason már nem fut, és kukázz össze egy 7-es telepítőt, hogy menjen...

Maga a nyelv meg túltolta az objektum-orientáltságot. Ne haragudj, de amikor minden kulturált nyelvben a billentyűzetről beolvasás kb. 1 sor, addig Javában először hozz létre egy ilyen osztályt, aztán abból egy olyan objektumot, aztán annak a tagfüggvényével talán be tudsz olvasni... felesleges túlbonyolítás, még akkor is, ha egyébként logikailag illeszkedik a nyelv rendszerébe.

"ha ma akarnék programozást tanulni"

A Java soha nem volt egy tanulónyelv, és tanuláskor egyébként sem a piacképesség a szempont. Az majd akkor, ha már tudsz haladó szinten algoritmizálni, akkor már lehet agyalni azon, hogy mi lesz a következő megtanulandó technika, amiből pénzt tudsz csinálni.

"ha cross platformos dolgokat akarok"

Akkor lefordítom natívan mindegyik platformra.

A Java akár jó nyelv is lehetne, ha nem lenne olyan borzalmas, mint amilyen.

1. Erős statikus típusosság

C-ben mondjuk van egy ilyen függvényem:

GtkEntry *my_entry;

g_signal_connect(button, "clicked", G_CALLBACK(button_click), my_entry);

A g_signal_connect utolsó paramétere (my_entry) egy gpointer, ami valójában egy void*.

A button_click függvény szignaturája:

void button_click(GtkButton* self, gpointer user_data);

Tehát a my_entry-re mutató pointer (user_data) void*-ként adódik át a button_clicked függvénynek, ahol csinálok egy ilyet:

GtkEntry *entry = (GtkEntry*) user_data;

Ha egyszer TUDOM, hogy a user_data egy GtkEntry-re mutató pointer, és biztosan nem fogok mást átadni, akkor miért ne adhatnám át void*-ként, és a másik oldalon miért ne castolhatnám vissza? Az, hogy nyers pointerként "utaznak" az adatok egyik függvénytől a másikig, igen nagy rugalmasságot biztosít a C-nek és a hasonló nyelveknek. Persze, komoly hibaforrás is lehet, mert ha véletlenül GtkEntry helyett mondjuk GtkVBox-ot adok át, akkor vagy csak simán hibásan fog működni a program, vagy segfault lesz belőle...

De Java-ban (és más, erősen típusos nyelvekben) ilyenkor vagy Object-et dobok át (ami nagyon nem ajánlott), vagy lehet szarakodni a <T extends anyamkinja>, vagy polimorfizmus, vagy pedig castolgathatok, ami ugyancsak nem ajánlott... nekem a görcs áll a kezembe ezektől az agyonbonyolított megoldásoktól. Igazából a generikus típusparamétereket meg a polimorfizmus olyan problémákra adnak megoldásokat, amik nem is léteznének OOP nélkül, arról nem is beszélve, hogy a polimorfizmus mögött is valójában pointer castolgatások állnak.

(Igen, tudom, ide-oda castolgatni típusok között nem biztonságos, ezt aláírom.)

2. Kényszeres objektum orientáltság

Border beállítása FlowPane-nek:

FlowPane pane = new FlowPane(10, 10);

pane.setBorder(new Border(new BorderStroke(Color.BLACK, BorderStrokeStyle.SOLID, CornerRadii.EMPTY, BorderWidths.DEFAULT)));

Az a nyomorult border egy objektum, aminek a konstruktorának a paramétere egy objektum, aminek a paramétere egy enum konstans, ami valójában objektum... téboly.

Az, hogy minden objektum, egy baromság.

3. A Java egyik legerősebb pontjának a hatalmas frameworköt tartják, ehhez képest 2022-ben olyan alapvető dolgok nincsenek benne, mint pl. egy JSON parser (EE-ben, SE-ben nincs).

A JavaFX-et is kivették, isten tudja miért, pedig arra még lehet mondani, hogy viszonylag modern, ellenben a Swinggel.

De egyébként JavaFX több ponton is magában hordozza ezt az agyonbonyolított szemléltet.

Csinálj például benne egy olyan textarea-t, aminek el lehet rejteni a karaktereit, de ha kell, akkor meg is lehet jeleníteni őket, és ki lehet másolni a benne lévő szöveget.

A TextField nem tudja elrejteni a karaktereket, a PasswordFieldből pedig nem tudod kimásolni a szöveget. Csak ilyen überkomplex

megoldások vannak, mint ez is:

public class PasswordFieldSkin extends TextFieldSkin {

public static final char BULLET = '\u2022';

public PasswordFieldSkin(PasswordField passwordField) {

super(passwordField, new PasswordFieldBehavior(passwordField));

}

@Override protected String maskText(String txt) {

TextField textField = getSkinnable();

int n = textField.getLength();

StringBuilder passwordBuilder = new StringBuilder(n);

for (int i=0; i<n; i++) {

passwordBuilder.append(BULLET);

}

return passwordBuilder.toString();

}

}

Mondjuk GTK-ban ez ennyi:

gtk_entry_set_visibility(entry, FALSE);

És innentől nem látszódnak a karakterek.

4. A Java L-A-S-S-Ú.

Mire a JVM feláll és a HotSpot lefordítja a kódot, addigra egy C/C++-ban írt kód már rég lefutott. Nagyon kevés olyan feladatot tudsz találni, ahol a JVM gyorsabb tud lenni, az is csak akkor érvényes, amikor már az egész JVM felállt és a kód le van fordítva.

5. Ez a "platformfüggetlenség" (write once run everywhere) tök jól hangzik, de ezt akkoriban találták ki, amikor úgy tűnt, hogy majd mindenféle mobilcucc asztali gépre írt programokat tud futtatni. Manapság azért már látjuk, hogy mennyire nehéz olyan appot írni, ami asztali gépen is és mobilon is minden szempontból (adaptív megjelenés, beviteli módszerek, energiakezelés...) jól fut.

Másrészt igen, nem nehéz belefutni olyan dolgokba, amik egyik platformon jól futnak, a másikon bugosan. Viszont ha keresztplatformos libeket/frameworköt használsz, akkor pedig nem nehéz bármelyik másik nyelvben hordozható kódot írni, csak fel kell építeni egy fordítási környeztet minden célplatformon, és lehet fordítani.