Vlákno názorů k článku Java je tu 30 let: všestranný jazyk formoval moderní informatiku od Pavel Stěhule - Koncem 90 let byla Java relativně jednoduchý jazyk...
-
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).
-
radekmStříbrný podporovatelty 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í.
-
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.
-
Filip JirsákStříbrný podporovatelAneb 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é.
-
Filip JirsákStříbrný podporovatel
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
wchara 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. -
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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. -
Filip JirsákStříbrný podporovatel
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ů).
-
Filip JirsákStříbrný podporovatel
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.
-
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.
-
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.
-
Filip JirsákStříbrný podporovatel
Existuje dávno: Saxon. Jeho autor je spoluautor specifikace XSLT 2.0.
-
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. -
Pavel TišnovskýZlatý podporovatelGUI 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).
-
Pavel TišnovskýZlatý podporovatel
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í?
-
Pavel TišnovskýZlatý podporovatel
jo vidíš ano (důkaz, že nezestárla pouze Java, ale i moje paměť :-)
-
Pavel TišnovskýZlatý podporovatel
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 )
-
>>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 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.
-
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/issuesPozná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ý.
-
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
-
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.
