Nikdy jsem Javě nepřišel na chuť. Přesto mě láká, a to díky Androidu, který trestuhodně nebyl zmíněn.
Skoro 10 let tam byla stará verze kvůli soudu s Oracle. Mezitím Google Javu opustil (Kotlin, Flutter, ...).
Tak Kotlin je nadstavba Javy, běží to na stejném JVM. Takže javové knihovny a API furt fungují. A pro jednodušší aplikace vytvořil Flutter (jazyk Dart).
Obejde se bez javy a znalosti jejích knihoven? Koukal jsem po nějaké české knize o Kotlinu a vypadá to, že je to minoritní a bez potenciálu.
Kotlin lze kompilovat pro různé targety, JVM je asi nejčastější, ale lze jej kompilovat i do nativního kódu a tuším i do JS. Základ zůstává stejný, ale liší se dostupná API.
Jestli se obejde bez Javy – minimálně na kompilaci bude asi potřeba JDK, běh se v případě kompilace do nativního kódu bez Javy obejde.
Jestli se obejde bez znalosti knihoven Javy – v principu ano, ale záleží, co v tom chcete dělat. Hello world úplně bez problémů (a to i pokud je target JVM), nějaké jednoduché konzolové aplikace taky, ale asi nemalá část použitelného ekosystému bude na JVM.
Myslím, že nad Javou neběží akorát v iOS, kde je to kvůli umělým omezením OS. Používají postup, který mají i ostatní jazyky - zkompilují kód do jazyka, co je na dané platformě nativní. Např dřív Google měl Java do Objective C, nebo věci na Pythonu používají Cython (Python do C).
Do native to lze zkompilovat i na jiných platformách (na Linuxu i macOS jsem to dělal), samozřejmě ne pokud používá knihovny pro jiný target. A jak zmiňoval OSN, jde to přes LLVM.
Java byla pod Oraclem na "life support" tak dlouho ze vznikla zombie Java v1.8 ktera je v korporatu nesmrtelna.
Nastesti se ve verzi 1.8 dostala na slusnou uroven a da s tim i dnes furt pracovat (Pokud nepotrebujete prohnat Touple Java Streamem).
Tak tak, osmička se drží. Ale stále se dá v praxi narazit ještě na 1.4.2 (tedy bez generik a dalších vychytávek).
Najmä v embedded svete. Našťastie som začínal na 1.3 Jave, tak mi až tak nevadí, keď v tom musím robiť. Java Me by mi vadila viac.
Da sa aj v 8cke pracovat s tuple, musite si ich pravdaze sam naimplementovat (pac java to nema dodnes) a ked to urobite OK, tak vam ich Stream zozerie bez remcania.
Tuple je hack který zhoršuje čitelnost kódu, proto v Javě není. Mnohem lepší je používat patřičně pojmenovaný record
S tim jde jen souhlasit. Zvlast kdyz pak ty data vybiras a oni se jmenuji value1, value2, ... jako v C#
v C# sa už dá tuple dokonca aj dekonštruovať
var (name, address, city, zip) = contact.GetAddressInfo();
Zasa record, to je taká cigánska kára. Potrebuješ dostať tri hodnoty z algoritmu a musíš vymýšľať nasilu názov. Vznikne niečo ako "TrackingAlgorithmProcessingResultWithTemperature" V Jave tento typ nepoužívam, ale viem pochopiť motivácie.
24. 5. 2025, 12:09 editováno autorem komentáře
Zombie programovacich jazyku: Python 2 , Java 1.8, PHP 5.3 :)
25. 5. 2025, 09:28 editováno autorem komentáře
Koncem 90 let byla Java relativně jednoduchý jazyk s moderní knihovnou. Napsal jsem pár komunikačních aplikací nad TCP/IP v C, a byl to docela opruz. Oproti tomu v Javě to byl luxusní kód.
Na druhou stranu docela velkou nepříjemností byl dost líný start Javy a občas člověk narazil, že na něco existovala hezká specifikace API, nicméně musela by se koupit relativně drahá implementace. Moc jsem nechápal, že někdo píše aplikace pro desktop v Javě. Minimálně v Linuxu stejně běžely zoufale pomalu (někdy kolem roku 2008 jsem musel používat Notes, a do dneška z toho mám hrůzu).
Někdy po roce 2005 jsem se na Javu podíval znovu, a nestačil jsem se divit, jaký se z toho stal moloch. Nejen ze samotné Javy, ale i z aplikací, které se psaly v korporátu, a i přes JIT - ty aplikace, resp. jejich interface byl neskutečně líný. Vyplňovat formuláře čehokoliv napsaného v nějakém frameworku v Javě - bylo na minuty. Klobouk dolů před obchodníky, že to dokázali prodat, a uplivnutí si nad inženýry, že tohle odvážili nabídnout do lidem. Rozhodně Java přispěla k dnešním kapacitám RAM - bez hodně RAMky a SSD ty aplikace byly nepoužitelné (z mého pohledu - nechápu jak je lidi mohli používat).
ty aplikace, resp. jejich interface byl neskutečně líný.
Mám pocit, že dnes se z toho stala norma. Hardware je několikanásobně rychlejší, ale řada aplikací běží pomaleji. Uživatelé se nad tím už ani nepozastavují.
Osobně si myslím, že nenáviděný, nabobtnalý, nadužívaný a zneužívaný balast s dlouhou řadou historické zátěže a špatných návrhových rozhodnutí by se asi stal i z každé alternativy Javy pro dané cílové nasazení, pokud by se v té době prosadil místo ní (Lisp, Smalltalk, Strongtalk...).
Java je špatně navržená od samého začátku. Dá se říci, že všechno, co ideově nějak vychází z C++, je flawed by design. Už jsem si zvykl, že v IT jsou trendy dílem marketingu silných společností. Někdy si tak říkám, jaké by to asi bylo, kdyby se prosazovaly technologie, jež nejsou postižené už od narození. Netroufal bych si tvrdit, že by to dopadlo stejně jako u těch postižených.
Pro mě je to matlanina na způsob dortu Pejska a Kočičky. S každou další verzí standardu větší a větší matlanina. Ale přiznávám, že už to sleduji jen poočku z povzdálí, protože v zájmu zachování duševního i fyzického zdraví už dobrých 10 let na projektech v C++ odmítám participovat.
Aneb jak napsat, že o tom vůbec nic nevíte, aniž byste to explicitně napsal.Java používá pro Stringy UCS-2, a od verze 9 používá Latin-1, pokud je to možné.
no koncept "znaků" a řetězců v Javě jako gentlemani nebudeme komentovat, to se do slušné společnosti nehodí :-)
Je dobré připomenout, že koncept znaků a řetězců vznikl v Javě v době, kdy Unicode žilo s představou, že 65 536 znaků musí stačit každému. Takže tehdejší UTF-16 pokrývalo všechny code pointy dvoubajtovými jednotkami. Pak v roce 1996 přišlo Unicode 2.0, které tuto hranici najednou prolomilo. Z původního UTF-16 se stalo UCS-2, které pokrývalo jen část znaků Unicode, zatímco do UTF-16 se zavedly surrogate pairs, aby bylo možné dvoubajtovými jednotkami pokrýt všechny code pointy Unicode. Spousta programů tenkrát zůstala u UCS-2, Java se vydala tou cestou, že začala podporovat novou verzi UTF-16. Mohla zůstat u UCS-2 a zavést nějaký nový typ, třeba wchar
a z něj odvozený WString
, ale myslím, že by to bylo horší řešení – jazyky, které mají různé typy znaků s tím mají dodneška problémy.
jj právě proto se o tom raději nebudeme zmiňovat. Dobré řešení to není (spíš nejhorší možné), ale dá se s tím žít a prostě nováčci si musí zvyknout, že char není character (a že vůbec termín "character" má ve světě Unicode jiný význam, než jak je obecně chápán).
Jaké řešení by bylo lepší? Zahodit veškerý tehdejší kód a založit znaky a řetězce v Javě na UTF-32? Zmatek v tom udělalo Unicode, ostatní se s tím akorát snaží nějak vyrovnat. A Unicode bych také úplně nevytýkal, že to neodhadli správně na první pokus – tenkrát bylo hodně revoluční zvětšit prostor pro znaky na 216, těžko jim vytýkat, že neodhadli, že i to bude málo.
správné řešení by byla přímá podpora Unicode 2. V roce 1995 už se vědělo, že to bude 21 bitů (Unicode 2 nevznikalo za zavřenými dveřmi, dokonce tam Sun byl jako člen konsorcia *). To že oficiálně Unicode 2 vyšlo necelý rok po Javě spíš ukazuje, že to už nechtěli řešit a vydali Javu tak jak byla.
* Bill English was one of the founding participants in the Unicode project. He brought Sun Microsystems in as one of the initial members of the Unicode Consortium and served as the consortium's first treasurer, from 1991 to 1996.
Stejně jako nevzniklo přes noc Unicode 2, nevznikla přes noc ani Java.
A co přesně znamená „přímá podpora Unicode 2“? Java podporuje Unicode 2 tak, že pro reprezentaci textových řetězců používá UTF-16. Co mělo být jinak? Použít UTF-32? Udělat char 32bitový? Nemít žádný primitivní typ odpovídající jedné jednotce ze kterých se skládá textový řetězec?
Mimochodem, Java vznikala jako programovací jazyk pro mikrovlnné trouby a podobná zařízení, proto má primitivní datové typy – a proto jí bylo na začátku vytýkáno, že použít pro vnitřní reprezentaci textů dvoubajtové kódování je plýtvání pamětí.
mno to je přece úplně jedno, co Java používá pro reprezentaci řetězců. Máme to slavné zapouzdření, implementační detaily jsou detaily a mohou se měnit ;-)
Na druhou stranu že nemá typ "znak" je divné a matoucí*. Omlouvat to vývojem asi jde, ale že by to bylo skvělé řešení - to tedy není.
Zase na druhou stranu aspoň před mnoha lety přidali metody pro práci s code pointy.
Na druhou stranu že nemá typ "znak" je divné a matoucí*
Striktne vzaté character/znak nie je vhodný pojem vôbec v multijazyčnom kontexte. Vhodnejšie sú pojmy graféma a rúna. (Go a Rust používajú rune namiesto znaku.) A aj to nie je úplne kóšer, lebo máme "znaky", ktoré sa skladajú z viacerých znakov, tzv. grapheme clusters.
UTF-8 je na světě cca od roku 1993. Kdyby udělali to dobré rozhodnutí hned, mohli si ušetřit i tohle "lepší řešení".
UTF-8 je pro reprezentaci textů v paměti aplikace velmi špatné řešení. Jakou délku by měl char
? Proměnlivou? To nezní úplně jako primitivní typ.
V době vzniku Javy se nezdálo jako dobrý nápad nemít primitivní datový typ pro jednu jednotku textu. I vzhledem k tomu, že tehdy i dnes byla převládající reprezentace textů jako pole znaků – proto se ostatně ten datový typ pro text jmenuje String, česky řetězec (znaků).
No o tom to celé možná je. Že návrháři Javy byli v zajetí představ převzatých z C a jiných starších jazyků. Škoda.
To ovšem píšete se znalostí 30 let dalšího vývoje. To, že Java těsně navazovala na C a jiné starší jazyky je s největší pravděpodobností jedna z nutných podmínek toho, aby se rozšířila tak, jak se rozšířila. A pořád platí, že procesory a paměti v mikrovlnkách před 30 lety opravdu neumožňovaly tak velkou míru abstrakce, jaká by se vám dnes líbila.
Pravděpodobně nebo téměř jistě. Totéž se stalo s XML, v bledě modrém s C#. Co mne zaráží - jak to bylo rychlé. V té dekádě mezi 1995-2005 se sešlo víc faktorů - výkon hw byl přesvědčivý a predikovatelný, korporát potřeboval modernizovat sw psaný ještě v éře COBOLu, a po roce 2000 v USA začali intenzivně a jak nikdy dříve pumpovat dolary do ekonomiky.
Jenže XML i C# jsou také technologie od samého začátku špatné. 90. léta byla skutečně plodná, pokud jde o vznik nových věcí. Ale většinou šlo o bastardy, které se marketingem prosadily. Za nejplodnější éru považuji 60. léta. Takže zatímco 60. léta formovala IT, 90. léta IT spíše deformovala.
Náhodou C# je mnohem hezčí jazyk než java - problém C# a celého .NETu byla ta vázanost na Windows a uzavřenost - kdyby .NET byl od začátku open source tak tu Java dnes není a nepomohly by ani ty miliardy co spolkl marketing.
V tej dobe bol problem aj kulturny: MS shopy riesili len riesenia od Microsoftu, vratane interneho toolingu. Na vyvoj bolo Visual Studio, na spravu zdrojovych kodov TFS, a vo vsetkom ostatnom rovnako. Idea bola, ze aj ked sa objavi nejaky dobry napad u tretej strany, Microsoft to skopiruje a presadi svoje riesenie, takze "eventualne to bude aj tu" a povodne riesenie vytlaci/zanikne.. Nesiel cez to vlak. V javovej komunite boli otvorenejsi voci pouzivaniu kniznic a nastrojov tretich stran, tak vyvoj isiel pruznejsie.
XML je spatne? Ja nevidel spatne XML, ja videl jenom spatne navrzene XML. No a pak tady mam lidi kteri XML nahradili treba txt nebo json a pak pisou megalogiku k overovani vstupu v txt nebo json... takze jsme zpatky u problemu mezi zidli a klavesnici...
Zlí jazykové tvrdí, že výsledkem snahy navrhnout formát pro lidi i pro stroj je formát špatně čitelný pro lidi a ještě hůře pro stroj. A, upřímně, jak jsem začal XML řešit celkem krátce po jeho vzniku, není lehké s tím nesouhlasit.
Pritom XSLT jsou neuveritelne mocny nastroj. Mel jsem tu velmi schopneho programatora ktery nemel rad slozite veci a udelal pres konverze generatory ruznych typu faktur a pak nejake zvejkani ucetnich dat pro mobilni operatory.
Neuvěřitelně mocný nástroj to je, ale ta "jednoduchost" je často taková, že výsledek vlastně není příliš srozumitelný ani příjemný k používání. Ona ne každá jednoduchost je automaticky nutně k užitku věci. I když efektivní to je, o tom žádná.
A uz existuje nejaky OPRAVDU funkcni XSLT/XPATH2 engine?
Nevim, ptam se, ja s tim pred lety svihl prave pro to, ze se na to dalo spolehnout asi jako na IE6 splnujici webstandardy.
XSLT1 zoufale nedostacujici, k tomu knihovny podporujici "vybrane pertie" XSLT2 a ve vysledku celkove nepouzitelne.
A i ty XSLT1 transformatory v browserech pomale jaxvina.
Ono by se chtělo zamyslet nad tím, zda XSLT dává vůbec smysl. To, že to je pomalé je nejmenší problém. A že jsem toho v XSLT napsal mraky ale stále se ještě v noci budím s hrůzou, že v tom zase budu něco dělat (stejně jako u PL/SQL).
Presne tak... kdyz kdykoliv vidim jak nekdo hleda duvod proc mu zpracovani dat pres txt/json nefunguje a na cem mu to pada tak se vzdy usmivam...
Jo a pak je paráda něco v takových šablonách upravovat, to je opravdu za trest. Nikdo s tím nechce nic mít.
Nedavno me dobehl cva 15 let stary bash skript, ktery interne vyuzival xsltproc a kde jsem neuvazene pridal par komentaru, ze kterych slo poznat,, ze jsem autor.
Ptali se se me, co to dela, jak a proc, moje odpověď byla:"Byl jsem mlady a potreboval jsem penize"
Viz například API Fio banky, které kromě standardních formátů, které zahrnují i celkem rozumné XML, nabízí i CSV a „jejich XML“. To má elementy ve stylu <column_12 …>
, protože odpovídá 1 : 1 tomu CSV.
GUI knihovny pro Javu byly skutečně na dost špatné úrovni. Jak AWT (teoreticky rychlá), tak i Swing. Osobně se mi rychlostí a vzhledem líbilo SWT z Eclipse, jenže to nebyl standard balenej přímo v Javě.
Ale jestli jsi narazil zrovna na Notesy, to se nedivím, to bylo velké špatné, rozbité a marné (jediná aplikace, kvůli které jsem lidem musel instalovat ovladače myši - s těmi generickými od MS prostě Notesy nejely).
GUI knihovny sice nic moc, ale pokud bylo obchodní zadání aplikace s GUI, jedny zdrojáky a jedny binárky pro všechny 4 podporovane platformy, jaké byly jiné možnosti?
jj souhlas, nic moc rozumného nebylo. Jako ano, třeba Tk (tkInter), ale to se používalo spíše v akademické oblasti (některé aplikace byly fakt pěkné), ne v komerční sféře (a dává to smysl).
Zkusím hádat, které Ty platformy to byly: Wintel, Mac, SunOS a ta poslední?
ajo ok. Ale pro Linux přišla Java později, až někdy koncem 1998. macOS popravdě nevím, kdy přišel, ale Sun to nenabízel.
Tak Swing a Tkinter sú úplne iná liga (Swing je prvá liga, Tkinter skôr piata, dedinská).
Swing je profesionálna knižnica, mimochodom výborne navrhnutá, zatiaľ čo Tkinter je vhodný skôr na menšie skriptíky.
Problém bol (a do istej miery stále je), že koncom 90. rokov neexistoval hardvér, ktorý by dokázal spúšťať Swing aplikácie na bežnom desktope. To viedlo k legendárnemu mýtu: „Java je pomalá“.
Pôvodné AWT išlo nesprávnym smerom – namiesto generovania vlastného GUI len obalovalo platformové funkcie pre Linux, Windows či Mac. To je cesta do pekla, pretože takéto riešenie je dlhodobo neudržateľné.
Viď zoznam bugov v SWT:
SWT bug listy: https://bugs.eclipse.org/bugs/buglist.cgi?component=SWT&product=Platform
Keď sa James Gosling dozvedel, že SWT opakoval chyby AWT, vraj ho to riadne nahnevalo.
Správny prístup je generovať GUI v nízkoúrovňovej grafickej knižnici, ako to robí Swing, a nie priame volanie API operačných systémov
Podobný prístup ako Swing dnes používajú napríklad Flutter alebo Avalonia (grafická knižnica Skia), čo je správna cesta pre multiplatformové GUI.
23. 5. 2025, 17:06 editováno autorem komentáře
hmm... citam spravne? "spravna graficka kniznica ma vlastne GUI, ktore pochopitelne nie je vizualne kompatibilne s nativnym GUI OS"
Jedna z vycitiek voci JAVE co mam, je prave to, ze jej aplikacie zvycajne vyzeraju ako past na oko. A ked clovek otvori uplne svojbytne okno na vyber suboru, tak sa omladne o 30 rokov ;).
(o kulturnom soku co som nedavno utrpel, ked mi dodavatel dodal WWW aplikaciu+Tomcat, sa radsej nejdem rozpisovat :D )
>>> (o kulturnom soku co som nedavno utrpel, ked mi dodavatel dodal WWW aplikaciu+Tomcat, sa radsej nejdem rozpisovat :D )
Jeej, pekné retro, vtedy som mal ešte vlasy <3
Neviem, pri vývoji na win desktope roky používam okrem iného Netbeans s nastaveným windowsáckym look&feel. Neskúmal som, akú knižnicu používa, no predpokladám že v tomto režime tiež len zaobaluje natívne UI komponenty. A nepríde mi, že by bolo GUI nejak nevkusné alebo problematické.
NetBeans je Swing. Swing si vytvára svoje vlastné komponenty v Java2D grafickej knižnici.
Vo Swingu bol aj JDeveloper, všetky JetBrains IDE, ZAP (Zed Attack Proxy), či Burp Suite.
>>NetBeans je Swing. Swing si vytvára svoje vlastné komponenty v Java2D grafickej knižnici.
Nj, Netbeans bol rýchly a dobrý, mám naň dobré spomienky. Aj napriek tomu, že bol vo Swing-u. Teda ešte je, ale už sa viac používa IntelliJ idea miesto Netbeans. Dokonca som rozbehal NetBeans aj na raspberry pi 1, čo som sa čudoval, ako je to vôbec možné.
Pomalosť Javy bola spôsobená tým, že ľudia si neuvedomovali cenu rôznych operácii a vyrábali objekty ako číňan telefóny a niektoré veci robili zbytočne vysokoúrovňovo, na 3 metódy ťahali hneď knižnicu. Čiastočne to bolo spôsobené aj marketingom javy ako jazykom pre blbších, čo nebolo celkom tak, malo to isté svoje quirks.
25. 5. 2025, 11:54 editováno autorem komentáře
SWT je super knihovna, trochu nízkoúrovňová, ale požívala se mi vždycky příjemně. Měl jsem rád FormLayout. A hlavně najednou ukázala, že není problém mít Java aplikaci s GUI, která je rychlá.
SWT je vlastně správně udělaný AWT toolkit. Sice komplikuje přípravu instalačních balíčků, ale je dobrý.
Na Windows AWT ušel, protože se opíral o Win32 API, ale na GNU/Linuxu se opíral (a pořád ještě opírá) o opravdu hodně škaredý toolkit. A hotových komponent bylo jen minimum. Ocenit se musel "responzivní design", tedy správci rozvržení.
Swing měl škaredé multiplatformní vzhledy od samého počátku. A "nativní vzhledy" - Windows a GTK rozhodně nebyly dokonalé. Koneckonců vzhled GTK používá doteď užásný dialog pro výběr souborů ve stylu GTK 2.0. Dnes situaci zachraňuje FlatLaF, což je ale tak trochu moloch.
23. 5. 2025, 12:51 editováno autorem komentáře
Super knižnica? Však to má tisícky otvorených bugov, ktoré nikto nikdy nevyrieši. A nie je to primárne problém SWT developerov, ale zle zvoleného prístupu. Je nemožné vytvoriť mutliplatformovú GUI knižnicu pomocou obalovania volaní Linux/Windows/Mac OS funkcií. To plodí len nekonečný rad bugov. Správny postup je ten, ktorý zvolili Swing, Flutter a Avalonia - vykresľovanie svojich komponentov v nízkoúrovňovej grafickej knižnici.
Keď Swing aplikácie nestíhali, tak proste nebol čas na multiplatformové GUI aplikácie v Jave; bolo treba pár rokov počkať, kým to šlo. JetBrains produkty dokazujú, že vo Swingu viete robiť špičkové UI aplikácie.
JasperReports dostali dávnejšie geniálny nápad prejsť zo Swingu do SWT. A tak to aj vyzerá. To ich Studio sa nedokáže prispôsobiť vyššiemu rozšíreniu. Je to proste celé zle.
tedy vlastně přístup "zahodíme všechno, co dělá GUI vrstva OS a uděláme to znovu", je vlastně lepší? Potom není divu, jak je Swing pomalý a je vidět každý chybějící event o resize/redraw atd.
Takhle to dělají GTK a Qt a spousta dalších multiplatformních knihoven pro tvorbu GUI. Jedna vrstva má na starosti ovládací prvky, druhá vrstva má na starosti (nejen) kreslení. Vrstva na kreslení (v případě Swingu Java2D) má většinou nějakou část, která musí být jiná pro každý podporovaný OS.
Swing (Java2D), Flutter, Avalonia, Compose multiplatform (Skia) používajú nízkoúrovňové knižnice na tvorbu komponentov. To o niečom hovorí.
SWT a wxWidgets to robia tak, že volajú OS funkcie. No a majú tisíce bugov, niektoré aj 20 rokov staré:
https://bugs.eclipse.org/bugs/buglist.cgi?component=SWT&product=Platform
https://github.com/wxWidgets/wxWidgets/issues
Poznám x úspešných aplikácie z prvej skupiny, ale jen jednu z druhej. PicoTorrent používa wxWidgets, ale to má len také skromnejšie UI.
GTK pôvodne volalo tiež OS level funkcie, ale postupne sa to menilo:
Starting with GTK 2.8 (2005), GTK began shifting to Cairo for rendering.
By GTK 3.0, all rendering was done using Cairo, eliminating direct OS-level drawing calls. Instead of relying on native OS widgets, GTK draws everything itself, making it more consistent across platforms.
23. 5. 2025, 19:47 editováno autorem komentáře
Hovorit to o niecom moze, ale maju vlastne problemy.
Aj ked sa snazia mat temu pripominajucu platformovu, tak nieco tam vzdy unika a dana aplikacia budi dojem uncanny valley. Okrem toho typicky pohoria na a11y; co bezny user nevnima, ale prave ten, co to potrebuje, tak velmi bolestivo.
A ked sme pri bugoch, qt ich ma tiez pozehnane. A gtk sa neprofiluje ako multiplatformovy toolkit. Niektori ludia sa ho snazia portovat, casom ich to prestane bavit a o par rokov skusi niekto dalsi, ale produkcna kvalita to nie. To je len x11 a wayland, pricom x11 uz je len v maintenance.
Svět není černobílej
Oba přístupy mají svůj smysl.
Vlastní vykreslování vede k nestandardnímu UI, Swing měl i nestandardní dialogy třeba pro ukládání / otevírání. To není jen otázka vzhledu, to se jakž takž dá flikovat nějakým tématem, ale hlavně tím zabíjíte integraci do OS, ta aplikace nedokáže využít běžná rozšíření systému (na Windows třeba doplňky do open/save dialogů), nedá se standardně skriptovat (na Windows třeba pomocí AutoIt ap.), mají problémy asistenční technologie. Prostě cokoli, co předpokládá standardní komponenty systému.
Chudák uživatel.
Kromě toho Swing byl prostě napsanej blbě, je tisíc GUI knihoven, který se sami kreslej (Qt, GTK, Tk) a jsou rychlý.
Když vybírám GUI multiplatfromní tootlkit, tak mám požadavek, aby to používal systémové zdroje. Tisícovka bugů je sice smutná záležitost, ale ano, mám tento požadavek. Toolkit s vlastním vykreslováním nemám rád.
Jsem pred rokem dvěma zkoušel Qt6 na macOS, tmavý vzhled, a checkbox sice kreslil nerozeznatelné od nativního, ale blbě stavy. Ve světlém vzhledu problém nebyl.
QT majo fajn bindings pre Javu, chvíľu som sa s tým kedysi hral, vyzeralo to dobre. Neviem aký to malo osud, snáď to ešte funguje.
Swing má v mojom srdci špeciálne miesto, najmä téma Metal pôsobí tak retrofuturisticky.
Téma Steel je zjevně vypůjčené z macOS 8. Ocean se taky moc nepovedl, ale působil svěžeji.
Když zavedli Nimbus, tak jsem se nad těmi omalovánkami rozesmál, ale asi to byl odraz doby.
Vzhled Windows by potřeboval údržbu, moc si nerozumí s HiDPI. A vzhled GTK nový dialog pro výběr souboru. No, můžu začít programovat :-).
Není náhoda, že v JetBrains začali do Swingu přispívat. Špatně si vybrali toolkit a už se to s nimi veze :-)
Jednou si zkusím něco udělat s pomocí JavaFX
JavaFX je aktívne vyvíjané, rozhodne nie je mŕtve.
https://www.youtube.com/watch?v=FxHbXY34iFQ&t=152s
Mne sa vždy steel pozdával, bol svojský. Ocean tiež. Ocean síce nie je úplne top skin, ale skúšku časom zvládol. Sú mnohé skiny ktoré na prvý pohľad vyzerajú super, ale po čase zistíte, že nie sú ono.
Úspech JetBrains hovorí o niečom inom. Kebyže si zvolili SWT, tak o nich dnes možno nevieme. Je prirodzené, že JetBrains si tvorí svoje vlastné nadstavby alebo prispievajú ku bug fixom keď na Swingu im beží celý business.
Bolo by sa treba spýtať ich, čo si myslia o Swingu.
no Java na desktopu je trošku zlo.
Ale na druhou stranu - okolo toho roku 1995 se to lámalo a prostě něco nového každý očekával. C++ to nebylo (to je jen jazyk), Delphi taky vlastně nebylo, tak prostě ohnuli jazyk, který byl vyvinut pro něco jiného a řekli "toto je budoucnost Internetu" :-)
Nadpis článku mi přijde dosti populistický a obsahově divný. Java formovala moderní výpočetní technicku? Možná bych se alespoň pousmál, kdyby slovo formovala bylo upraveno na deformovala, ale ani tak by nápis vlastně nedával smysl. Java tu prostě jen je 30 let.
"formovala" nebo "deformovala" - hele asi ano. Minimálně formovala jednu až dvě generace programátorů v názoru na to, jak má vypadat OOP. A taky jim pokřivila názor na typové systémy, a to do té míry, že nedají koncepty jinak typovaných jazyků (F#). Hmm takže z tohoto pohledu "deformovala" :-)
rok 1995 bol najplodnejsim rokom, kedy vzniklo najviac programovacich jazykov, ktore sa pouzivaju stale vo vyznamnej miere: Delphi, Java, PHP, Ruby, JavaScript.
To sa bude tazko prekonavat :)
https://en.wikipedia.org/wiki/Timeline_of_programming_languages
23. 5. 2025, 07:24 editováno autorem komentáře
Upřesním, co se vlastně před třiceti lety stalo. Dne 23.5.1995 se Netscape rozhodl licencovat Javu od Sunu (viz https://www.tech-insider.org/java/research/1995/0523-a.html).
Dobový článek o genezi Javy: https://www.tech-insider.org/java/research/1995/07.html
<Nadsázka>
Pozitiva
- Naučil jsem se uklízečku nazývat lépe znějícím Garbage collector.
- Slevnily RAM.
Negativa
- Zrušení vícenásobné dědičnosti a nahrazení (pro mě pouze na pohled koncepčnějšími, ale ve skutečnosti jen opruzujícími) interface.
- Vývojáři si zvykli na použití knihoven, které řeší "všechno", ale já dodávám, že jen na 95%.
- Uživatelé si zvykli, že program je pomalý, zabere (se svými knihovnami) spoustu místa na disku, vyžere "všechnu" RAM a chování (časové prodlevy) se mezi jednotlivými spuštěními téhož programu mohou lišit. Z pohledu pokročilého uživatele tímto zmizely pozorovací instinkty, kdy když nějaké čtení z disku nebo zápis drvá déle než jindy, znamená to, že HDD se s námi loučí.
- Opět se ukázalo, že když nebyl naplněn původní záměr a projekt totálně selhal (záměr použití Java byl pro jednoduchá domácí zařízení typu pračka nebo mixér), může silná firma projekt podržet natolik, aby se z něj stal celosvětově využívaný ekosystém. Viz VHS.
</Nadsázka>
No flame, please. Nebudu argumentovat k dementi výše napsaného, protože to vyjadřuje mé osobní pocity před X lety. Poté, co jsem kdysi napsal svůl první a poslední komerční program (prý se s vyřešením jedné chyby používá dodnes), nechci mít s Java nic společného. Naštěstí nemusím.
"Zrušení vícenásobné dědičnosti a nahrazení (pro mě pouze na pohled koncepčnějšími, ale ve skutečnosti jen opruzujícími) interface" - to je možná na místě otázka, jestli vůbec koncept dědičnosti je dobrý nápad :-)
Tak mě v té době (cca 2000) v C++ vícenásobná dědičnost umožnila (pro mě elegantně) vyřešit timeouty v komunikaci, tehdy po sériové lince. Jedna třída Timer, druhá třída obecného zařízení a třetí třída timeoutovaného zařízení podědila obě. Buď přišla událost od časovače nebo od zařízení a dokázal jsem ve stavovém automatu (další třída jako potomek timeoutovaného zařízení) řešila komunikacní protokol a fungovalo to. Tím neříkám, že je to nejlepší řešení a třeba v Java to nejde (jde pomocí interface).
Tak jaký koncept, když ne dědičnost? Nejsem teoretik, ale tahle myšlena mě zaujala.
Jiný koncept, než třídní hierarchie: skládání tříd, traity (viz Rust) a dependency injection (přímo Java). Nebo jít funkcionální cestou.
https://codeburst.io/inheritance-is-evil-stop-using-it-6c4f1caf5117
Díky. Nějaký smysl to dává, i když už jsem asi příliš nepružný, abych považoval argumenty uvedené v článku za problém koncepce a ne konkrétního návrhu. Ale možná, že právě o to jde. Tak dík ještě jednou.
"Vícenásobná dědičnost" v Java nyní částečně je protože interface může mít default metody.
Java fakt není pomalá, spíš naopak, maximálně její spuštění nebo použité frameworky, ale i to se nyní dá řešit pomocí AOT nebo CDS.
V době, o které mluví ovšem pomalá byla. A to dost brutálně. O paměťové náročnosti ani nemluvě. V tomhle ohledu má pravdu.
Na desktopu byla Java pomala a s hnusnym UI. Kdo z koncaku videl logo Java pri instalaci nebo spousteni, zacal se krizovat. Web dal ovsem tento zabe polibek a vznikla princezna Spring/Spring Boot. Zazraky se deji! Ty uvedene zebricky jsou takove...no...na prvnim miste hlavne jede JavaScript/TypeScript/React bla bla. Univerzity a vyvoj AI a kurzy tlaci vsichni Python, jenze Python ma pro produkci urcite neprijemne mouchy. Vsechno jsou to takove podivne mezistavy, nic z toho vlastne neni uplne dobre. Java jede samospadem, C# pro milovniky .NET, PHP vaha, no. Myslim, ze v IT mame na vic. V budoucnosti muze vzniknout specialni jazyk urceny na to, aby v nem psala apky AI - fullstack a superstrucny. Uvidime.
V budoucnosti muze vzniknout specialni jazyk urceny na to, aby v nem psala apky AI
Pro účely AI vznikl před téměř 70 lety jazyk LISP.
Na základě dobových představ akademika. Realita je opakovaně zatloukla do země. Některé koncepty se, s realističtější syntaxí, ale zachovaly.
Na co by AI potřebovala z hlediska člověka realističtější syntax? Alan Kay trefně označil LISP za koncept, jenž pro computer science znamená totéž, co Maxwellovy rovnice pro elektrodynamiku - je to vlastně to jediné, co by vám teoreticky mělo stačit k tomu, abyste vyřešil jakýkoli jev klasické elektrodynamiky. Ale v praxi je naprostá většina lidí nepoužívá, protože jsou příliš abstraktní. V praxi si vystačí s méně abstraktními, ale přímočařeji použitelnými nástroji. To ale není důvod k tvrzení, že Maxwellovy rovnice realita zatloukla do země. Pokud bych chtěl někomu (resp. něčemu) poskytnout co nejsilnější nástroj k řešení problémů klasické elektrodynamiky, tak s omezením např. na Ohmův zákon by dost rychle narazil na jeho limity.
Syntax LISPu sluzi na priamy zapis AST :)
Takze ano, staci na vsetko, kazda dalsia nadstavba uz len prida svoje obmedzenia.
Představa, že jazyk vyvinutý člověkem v 70. letech, bude "ideální" reprezentací pro AI, je dost smělá. Připomínám všechny ty "geniální" funkce typu "cddadr", které, jak uznáš, se skutečně překonaly. Že má mít jazyk, klidně i používaný AI, reprezentaci, která je lidsky snadno pochopitelná a čitelná, snad nikdo nebude zpochybňovat, protože tam skončit asi nechceme. Trvám na tom, že Lisp je dítě své doby a ano, je dost univerzální, asi jako Turingův stroj a podobné věci. To z něj ještě nedělá ideál.
24. 5. 2025, 13:08 editováno autorem komentáře
Tak zrovna srovnávat to s Turingovým strojem, který má celkem nezastupitelnou pozici díky jeho výhodě (nekonečné pásce, o které se sice ve slušné společnosti moc nemluví, ale která je přímo zodpovědná za všechny ty teoretické zázraky založené na kardinalitě spočetného nekonečna) a současně i nevýhodě (té stejné nekonečné pásce, která dělá veškeré výpočty nejen že neefektivní, ale i nerealizované v našem Vesmíru) to není moc dobré.
Pokud programátor není prase, tak nemá šanci tohle použít v programu s použitím modern(ějš)ích LISPů. Tohle už dost smrdí potřebou zavést si proměnnou nebo změnit datovou strukturu.
Docela se obávám, že další jazyk se teď do popředí nedostane, minimálně ne nějak rychle.
Dneska ty top jazyky (top podle používanosti, ne nutně kvality) mají obrovskou výhodu - je pro ně k dispozici šílené množství materiálů, zdrojáků atd. To by až tak nevadilo před pár lety - není rozdíl, jestli existuje deset nebo tisíc učebnic, když stačí jen jedna dobrá. Jenže dneska právě na tyto materiály jsou natrénované LLM modely, které dávají +- rozumné odpovědi (to je na delší debatu, ale prostě začátečníci dostávají aspoň něco).
Takže to lidem, co s jazykem začínají, dost hodně pomáhá a tudíž je tady velký tlak začít používat právě tyto jazyky. Je to taková kladná zpětná vazba, která hodně pomáhá těm top jazykům.
Poznámka: vidím to na školení, prostě lidi začnou zkoušet jazyk a ptají se LLMek na všechno (nápověda tyto otázky přímo nezodpoví, logicky). Mají výpomoc a jsou spokojeni a řekněme že zpočátku i docela rychlí
PS: mám na tyto pomůcky vlastní názor, ale to je názor starého zapšklého ajťáka (který navíc okolo LLM teď pracuje), tak to sem moc nepatří :-p
Nahodou... mne takhle AI dost pomohlo napsat disasembler pro jeden exoticky CPU. Jinak bych se do te prace vubec nepustil :-) A programovani mne zacalo opet bavit.
Druha strana mince - zaucoval jsem novacka a rikal jsem mu: ber odpovedi AI hodne z rezervou protoze tenhle jazyk ma velmi spatne nauceny. Tak motal dve syntaxe dohromady a jen daval copy + paste. Tak takto ne pratele. V tomto pripade AI vypinala mozek.
Ani jsem nepochopil ze muze takto mizerne muze vypadat vysledek studia z FITu.
Pokud ten člověk při studiu neprogramuje nějaké vlastní projekty pro zábavu, nebo nedělá něco mimo školu, tak to takhle může dopadnout. Mně studium na FEL ČVUT (FIT ještě neexistovala) rozšířilo obzory, ale programovat jsem uměl už před studiem a nejvíc jsem se stejně naučil na vlastních projektech. To není kritika fakulty, cílem studia je naučit se o počítačích a o programování.
To co současní nováčci často neumí je práce s referenční dokumentací (a zrovna u Javy byla vždycky slušná - chvála všem bohům za Javadoc) a místo toho používají obecné vyhledávače či Stack Overflow.
23. 5. 2025, 12:41 editováno autorem komentáře
Copak ve skole nejsou semestralky, projekty, cviceni? Zapichy jsou zadarmo? Aspon nejaky zaklad? To je tech 3-5let studia uplne v trapu? Ja uz mel v prvaku a druhaku programovani v C. A to predpokladam ze ten clovek nemel programovani na stredni a nezabyval se tim v krouzcich nebo sam.
Ma predstava je takova ze clovek uplne gumovy ktery do VS vubec k programovani nepricich by nejake zaklady na informatickem oboru z VS ziskat mel.
Pro mne jako cloveka ktery skolu nedodelal to je proste WTF moment.
Musim si opet vzpomenout na jednoho prednasejiciho ktery nam rikal: Ti co planuji ze skoly odejit necht davaji obzvlaste pozor, protoze se tim pak budou zivit :-) A mel pravdu.
Zadarmo zápočty a semestrálky samozřejmě nejsou, ale málokdy jde o nějak rozsáhlé nebo složité programy. Tady se samozřejmě nějaké základy získají.
Pokud ale student sám o sobě nevyhledává předměty, kde je potřeba něco většího, nebo si nezvolí třeba semestrální projekt či závěrečnou práci, která je vyloženě implementační, tak toho moc naprogramovat nemusí. To nemusí být nutně špatně, když se orientuje třeba na řízení v IT.
No ono spíš jde o to jestli člověk měl zkušenosti s programováním. Já si třeba přivydělával, že jsem psal ty semestralky za jiné a vydělal si tak solidní peníze. Složité bylo akorát vymyslet, jak to napsat 4x jinak.
Tak třeba na FIT VUT si student bakaláře v povinných předmětech napíše aspoň kompilátor (do dost easy-to-use pseudoassembleru, pro který další [zpravidla] semestr píše interpretr) nebo webový informační systém. Je fakt, že všechno to jsou sice trošku větší projekty, ale týmové a často někteří členové týmu napíšou fakt málo.
"na prvnim miste hlavne jede JavaScript/TypeScript/React bla bla" to právě ne. Jako chápu, že je tu bublina vývoje frontend-backend aplikací, ale to je docela malá část informatiky. Asi hodně viditelná část informatiky a navíc podobný SW se dělá i u nás (ČR), takže je i hodně pozic okolo JS/TS, ale jinak vzniká hodně software, který je "skrytý" - neběží přímo na webu.
> předpoklad, že nad virtuálním strojem Javy budou provozovány i další programovací jazyky umožňující přímý či nepřímý překlad do bajtkódu
Co je myšleno tím nepřímým překladem? Jde o situace, kdy je v překladu nějaký meziprodukt (např. tasty v případě Scaly)? Ten tam ale bude prakticky vždy (když vynechám triviální věci jako Jasmine, kde by snad mohl stačit jednoprůchodový překlad), jen často bude existovat jen v RAM.
tím nepřímým jsem myslel například překlad přes ASM https://asm.ow2.io/ Některé překladače se netrápí přímým generováním bajtkódu, ale používají něco takového. Asi jen technický detail, ale já si s tím kdysi hrál (a moji studenti napsali pár DP na toto téma), tak to rozlišuju.
Tak generovat bytecode bez pomocné knihovny by mi přišlo jako masochismus. Resp. nejlepší způsob, jak to dělat bez takové knihovny třetí strany, by nejspíš většinou bylo si takovou knihovnu napsat sám. Ale proč…
Java je u mne dost oblíbená:
+++ multiplatormní
+++ zatím spolehlivá
+++ programy jsou věkem/trvale přenositelné - stále výborný TrueCrypt (zaniklý, ale stále užívám i na nejnovějších o.s.), výborný JDownloader, ...
A minus - inu čekat než se rozběhne JVM.
oprava:
+++ multiplatformní
doplnění:
Již neužívaný dobrý WebFileSys a jiné, už si nezpomínám.
Jaké uživatelský SW je u vás oblíbený?
Java ma svoje chyby, lec porad to byl projekt, ktery "stavel na ramenech obru" a rozsiroval nebo alespon pouzival tehdy stavajici uroven Computer Science.
Ten jazyk navrhli lidi, kteri meli o Computer Science aspon nejake matne tuseni a nepokousi se znovuvynalezat kolo.
To kdyz jse podivam treba na "navrh" Reactu, to by jeden blil. Filozofii useEffect(), to fakt za strizliva vymyslet nejde, pak ty famozni vynalezy typu Redux, zdravime vynalez MVC patternu z roku 1974.
Nebo python3, ktery stylem vlastovciho lepeni dobastluje featury na urovni stare Javy 5.
Nebo GO, ktere na zaklady typu exceptions a generik proste rezignuje.
Java a hlavne jeji ekosystem je genialni zalezitost, ktera nema konkurenci. Vzdycky me pekelne sejri, kdy musim udelat nejakou trivialitu v Pythonu nebo GO, v java/springboot brnkacka s primapovanim Maven komponenty, v GO a Pythonu srani s GITHUB knihovnama na ktere 4 roky nikdo nesah a hromadou neresenych issues a CVE listem az za roh.
Hlavni problem Javy je v tom, ze vede programatora, tudiz muze programovat kazdy, treba nastojaka na parezu po kolena v bahne Gangy. A pak to dopadne jak Lotus Notes nebo Liferay, neco otresneho.
V C++ nic tak hrozneho napsat nejde, protoze s takovou "kvalitou" programovani by to ani neslo spustit/zkompilovat.
S aspon trochu schopnym programatorem je Java program efektivni, treba Tomcat, Kafka, Camel Na desktop aplikaci se porad nehodi, ale na cokoliv backendoveho s potrebou trochu komplexni business logiky a s potrebou integrace na jine systemy - nedostizna zalezitost.
A nastesti na Frontend uz mame Vue3/typescript. Vue stejne Jako javu navrhoval clovek s povedomim o computer science a da se s tim celkem bezbolestne pracovat.
Gočko ale generika má. To Java s type erasure jen tak napůl.
Jinak my děláme Go i Python a tedy problémy s "knihovnama na ktere 4 roky nikdo nesah a hromadou neresenych issues a CVE listem az za roh" nemáme. Byl by nějaký příklad takového bahna?
PS: i v Javě se objeví krásná CVEčka, třeba takové to CVE pro log4j byla docela chuťovka a ukázalo se, kolik SW si s sebou tahá superstaré verze.
Jo. Třeba sqlx :-)
Poslední commit před rokem, PR 69, issues halda. Teprve se začínám v go eko-systému pohybovat, ale popravdě oproti Rustu mě to přijde těžký hipster style. V podstatě najít knihovnu kterou by někdo udržoval (a rozvíjel) je halda prolézání githubu a mnohdy je jednodušší si to napsat sám. Ale to bude daň za to že go je tak trochu github-centric :-D
Sám dělám v Go, a když jsem procházel deps K8s, tak jsem se zhrozil. Ted si pamatuji jen Cron libku, protože tu jsem právě hledal pro náš projekt, a myslel, že se inspiruji v K8s (CronJobs).
Takový ten Unix Cron byl sice asi feature complete, ale L pro last day of the month by neuškodil apod.
A když by ten PR mergnuli, a K8s zaktualizoval modul, tak by CronJob získal nezdokumentovanou feature.
Java je upspesny projekt. Byla navrzena jako COBOL pro 21. stoleti a tim bezpochyby je. V dnesni dynamicke dobe kdy se vsechno meni je to idelani jazyk pro aplikace s zivotnosti 10+ let.
Souhlas. Lidi se často diví, že pro HFT se používá Java. trik je, že to nepíšeš jak hlásá enterprise a zároveň to máš rychleji než v C++ a dále to jde "tunit", když víš jak pracuje GC. Java a JVM hlavně je nejvíce "hated" a zároveň underrated platforma.
Živý mne především Python :D; to jen na okraj.
Súhlas. A čo sa týka špeciálne desktopových aplikácií, z tých napísaných komplet v Jave používam najdlhšie asi JOSM (interaktívny OpenStreetMap editor), cca 15 rokov, počnúc Core2 strojmi s 1G RAM. Pričom user experience mi nikdy neprišiel nejak zásadne horší, než pri natívnych aplikáciách podobnej komplexity.
Byl jsem snad ještě na střední co vycházel seriál "Pod kapotou JVM". Tenkrát to pro mne bylo jak objevování nového světa. O 20 let později tu je od stejného autora článek. GOAT.
Nedávno mne zaujal rozhovor/video: "What I Have Learned by Reading James Gosling's Code" (https://www.youtube.com/watch?v=yAaMHAW3SsY&list=PL6CuIDGsjyuOBgjACAehiN1qXh80o3FX3). Zcela mi to změnilo pohled na ten jazyk i autora jazyka. GOAT :D
23. 5. 2025, 20:41 editováno autorem komentáře
https://bugs.openjdk.org/browse/JDK-8139665
30 rokov vývoja a 30 bitov na pixel stále nefunguje v Java2Disaster.
Prevadi ji primo pod sveho majitele - IBM.... Ale necht uloha redhatu na otevreni javy (IcedTea), nikdy neni zapomenuta.....
Mne prijde skoda, ze se zbavili JNLP. To byl konecne jednoduchy zpusob, jak spoustet Java aplikace...
Preco nie su v clanku spomenute tie cringe reklamy na Javu?
Odporucam vyhladat na youtube: JavaZone,
World without Java, JavaZone 2013: Javapocalypse