To už je 24, však najpoužívanejšie verzie sú 11 a 8. A stále to beží na 3 biliónoch zariadení?
21. 3. 2025, 20:42 editováno autorem komentáře
Verzia 8 sa uz silne odsuva. Ano 11 je stale velmi pouzivana ale v podstate az teraz sa zacina objavovat uplna podpora frameworkov pre nove verzie Javy (moduly, spring, jakarta, ...). Takze je cas preskocit asi rovno na 21.
Ale nove veci v 24 su tiez zaujimave ale prechod uz nebude taky bolestivy ako napriklad medzi 11 a 17.
To s tou 11 se mi to moc nezdá. Když už někdo přešel z Java 8 na 11 tak nemá jediný důvod proč zůstávat na 11 a neupgradovat má 17 nebo rovnou na 21. Co vidím v okolí spousta projektu přecházelo rovnou na 17.
Navíc Spring Boot 3, který vyžaduje 17 je tu už déle než 2 roky. Verze 2 už není podporovaná a řekl bych, že si moc projektů commercial support pro Spring neplatí.
Primarny dovod je sulad servletovych specifikacii, verzii napr. Tomcat-u, springu, hibernate, prechod na jakarta baliky a ich spatna kompatibilita.
Skuste dat toto vsetko dohromady plus napriklad nieco z eclipse (EMF) a nebolo to celkom trivialne plus napriklad odstraneny Nashorn JS engine (myslim ze vo v15), ... a podobne 'drobnosti' ktore dokazu vasou aplikaciou celkom pekne zamavat. Ten vyvoj javy je momentalne sialene rychly ale nove veci vychadzaju v principe uz iba pre Java 17 a vyssie takze to vyzera nadejne, existuje dovod ako management dokopat k tomu aby do toho dali nejake peniaze aj ked je to bez funkcnych rozsireni.
To je nesmysl, 99,9% knihoven co jdou na Java 11 jdou i na Java 17, tam vážně problém není. Verze Jakarta je naprosto irelevantní (maximálně min verze, ale to je 11). Nashorn se skoro nikde nepoužívá a když už, tak jsou lepší alternativy např. GraalJS. Vážně neexistuje moc rozumný důvod zůstávat na Java 11.
Tak skuste prehodit Activiti workflow engine do GraalJS aj s celym frontendom a napojenim na messaging a DB.
Tu mate napriklad aktualny a to sa v case vyvijalo a nebolo vzdy takto jednoduche pre Tomcat:
https://tomcat.apache.org/whichversion.html
Skuste si na internete pohladat ako padali aplikacie pod Java 17, eclipse veci ako napriklad XText to je nocna mora.
Vsetko sa to zlepsilo a naozaj dnes je ralativne stabilny stav ale 2 roky dozadu tomu tak iste nebolo.
My tu mame aj aplikacie ktore su starsie ako 10 rokov.
To, že bude Nashorn z JDK odebrány se vědělo víc jak tři roky (spíš déle). Spousta projektů v době vydání Java 17 ještě stále využívala Java 8. Hodně se to zlomilo až tak 2 roky zpět se Spring Boot 3, který je k tomu dotlačil. Takže jestli v dnešní době existuje projekt, co nelze provozovat na Java 17, tak ten projekt je mrtvý.
Co se týká Tomcat, tak fakt si nevybavuji, že by v době vydání nové verze Java byl nějaký větší problém. Ono je v dnešní době dobrým zvykem, minimálně sestavovat aplikace s nejnovější Java verzí, tak aby se problémy odhalily co nejdřív a pro produkci používat nějakou LTS. Jestli narážíte na přechod z "Java EE" na Jakarta, tak ano bylo to někde bolestivé.
Dva roky dozadu už vážně knihovny, frameworky a tooly podporu Java 17 neřešily to už se řešila 21.
Eclipse obecně má vždy problém s novou Java verzí, ale to je kvůli jejich JDT.
To ze je projekt mrtvy mne v mojich dependencies velmi nepomoze. Ak je raz tam musim vynalozit usilie ktore nieco stoji aby som sa ho zbavil. Uz iba pretestovat taketo aplikacie pri prechode na novsiu verziu je nemala zabava.
Jenže, tohle je problém, že to někdo nechá 10 let vyhnít. Na dependencies ani nešáhne. Vůbec nic nedělá a pak se po 10 letech diví, že jsou jeho dependencies mrtvé a honem honem budeme to muset řešit. Nakonec brečí, jak se to všechno mění. Místo toho aby to dělal průběžně. Jak už jsem psal, je potřeba ty aplikace alespoň sestavovat a s tou nejnovější verzí, aby se tyhle problémy ukázaly co nejdříve a byl dostatek času to řešit.
Nezmysel... možno na papieri, ale problém s kompatibilitou medzi verziami Javy sú tu veľké. Argumentovať už nemusím, bo kolega Pavel Tavoda
ti sem dal všetky informácie. Java ale už z podstaty ako funguje, ako sa vyvíja a aké zmeny v nej nastávajú proste kompatibilitu nevie zabezpečiť. V iných jazykoch je teda výrazne menej zmien narušujúcich kompatibilitu.
Ďalší problém je aj migrácia samotná. Mnoho krát nemáš žiadne dostupné riešenie pre implementáciu funkcionality jedna k jednej, a musíš úplne nahradiť knižnicu, alebo prepísať veľké kusy kódu.
Jazyk samotny spatnu kompatibilitu ma 100% (asi jediny krat bol enum keyword). Problem su kniznice. Napr. v Java 17 bol odstraneny --illegal-access. Ak mate kniznicu v dependencies ktora pristupuje do internych struktur smola. Ked sa to cele spocita tak je toho nakoniec dost vela co sa musi urobit.
Projekty sa aspon ocistia od mrtvych dependencies a zmodernizuju. Ja na to nenadavam ale tej roboty bolo dost na projektoch ktore sme uz prehodili.
BTW to slovní spojení "spatnu kompatibilitu" jsem původně v češtině pochopil jako "špatnou kompatibilitu" (slovensky "zlou"?) a ne jako "zpětnou kompatibilitu" . Je vidět, že chybějicí iterpunkce někdy dělá divy.
Tady je potřeba ale dodat, že se hlavně odstraňují resp. omezují věci, co oficiálně nebyly podporované a byly v dosti šedé zóně. Ale všechno bylo oznámeno dost v předstihu a jejich náhrady by tenhle problém již do budoucna měli vyřešit.
Môžem sa mýliť, ale 17 je najpoužívanejšia a prechádza sa na 21. Tie legacy verzie sa používajú len tam, kde majú veľmi konzervatívnych paranoidnych adminov, alebo obskúrny hardvér. Nie je dôvod.
Njn. krátká a dlouhá škála, taky se na tom občas zaseknu, pokud to mi to rovnou nevyplývá z kontextu.
Stejně je to dost ;) Dají se tam počítat všechny Androidy, nebo tam už se tomu nesmí říkat Java, když je to od Google?
Lenže ja som to schválne neprekladal a to z 3 dôvodov:
1. Ani inštalátor v CZ či SK jazyku to neprekladá na miliardy
2. "3 bilión" si rýchlejšie spojíš s Javou než "3 miliardy", jednoducho je to "typické" číslo pre Javu.
3. Išlo o referenciu na meme, ktoré práve taktiež obsahuje "3 bilióny", nie miliardy.
Existuje nejaká JS aplikácia, ktorá nepretržite beží od septembra 2018 s minimálnymi zmenami (oprava chýb a bezpečnostné opravy)?
Asking for a friend.
Tento článok nemá nič spoločné s Javou, ale ak to chceš tak dobre počuť, tak JavaScript je určite stabilnejší a zároveň je v ňom menej legacy softwaru a viac moderného softwaru než v Jave.
Nikde nehovorím že JS je naj perfekt jazyk (aj keď áno, rád JS používam, a aj práve frameworky ako Svelte či VueJS). A áno, sú tu aj iné veľmi dobré jazyky (poslednou dobou ma jeden z nich zaujal - Zig), inak ale aj Golang, Vala, Haskell, ERLang, C/C++, a vlastne čokoľvek čo nie je PHP a Java. Pretože PHP a Java sú skutočne merateľne špatné jazyky. PHP najmä kvôli najmenej konzistentnému API, a Java práve kvôli uzavretosti, množstvu legacy kódu, neskutočnému boilerplate, a nehutnej syntaxi. To nemôžeš nesúhlasiť. Aj keď viem že v najnovších verziách Javy už nejaká práca na redukovanie boilerplate začala, ale je to stále najhorší jazyk čo sa týka syntaxe a boilerplate.
Takže nevidím dôvod, prečo by som sa k Jave nevyjadroval v negatívnom zmysle, keď je tu vlákno o Jave.
To, že v Javě běží treba čtvrt století staré aplikace, není znamkou nekvality Javy a jejiho "ekosystému", ale naopak známkou jejich dost slušné kvality.
Java bývala velice příjemným objektovym jazykem. Nekonzistencí s objektovym paradigmatem tam bylo jen pár (pole, primitivní datové typy,..).
Samozřejmě se ale nemohla vyhnout modernizaci, takže obohacena o další přístupy (funkcionalni, aspektove..) už je dost nepřehledná, tedy hlavně pro nováčky.
Ale největší problém, myslím, vždy dělala těm, kteří programuji klasicky proceduralne (a proceduralne se snazi zachazet s objekty) a ještě nebyli schopni svůj přístup k programování otočit nohama vzhůru a začít se na to dívat čistě objektově.
> otočit nohama vzhůru
Nenazval by som to takto. Evokuje to ze treba uplne zabudnut proceduralne programovanie a nejako sa to zacat ucit odznova. Objektove programovanie je skor rozsirenie proceduralneho a nejake upratanie zodpovednosti jednotlivych casti kodu pripadne si dostudovat nejake patterny aby to clovek vedel spravne vyuzivat.
>Objektove programovanie je skor rozsirenie proceduralneho a nejake upratanie zodpovednosti jednotlivych casti kodu
Treba v hlave prepnúť prepínač a nastaviť iný mindset. Kým pri procedurálnom programovaní sa zvykne rozmýšľať spôsobom vstup-výstup, pri objektovom (a objektovo-orientovanom) nastupujú rôzne metafory, vzory atď. Zrazu sa z kopy mlynčekov stane mestečko, ktoré si žije svojim životom. To, že Java tak trochu moc pajcla C-čko, bola pragmatická voľba v tom čase. Niekedy je to aj na škodu, ale dá sa s tým žiť.
Procedurálne programovanie v op/oop nie je nutné, viď OCaml, Julia.
No tak JavaScript je vyber toho najhorsieho co kedy vzniklo. Uz iba null vs undefined pri porovnavani == === !== ... ?!?? Tam sa kludne pomyli aj 10 rokov programujuci senior.
Samozrejme neexistujuca typova kontrola co ciastocne dobieha TypeScript ktory to ale tiez robi trochu neohrabane a niekedy sa musi vratit syntax lebo prave narazili na nieco co koliduje s inou vlastnostou.
Co take JQuery? To uz je u vas legacy alebo moderne? Akosi zabudate ze je to o vybere. V JS stale vznika nieco nove ale nesmiernou rychlostou aj stare zanika takze skuste upravovat 10 rokov stary projekt v JS. Zakladne paradigmy sa menia kazdy rok.
Co je na Jave uzavrete?
To, že něčemu nerozumíte ještě fakt neznamená, že to nemá smysl. To jen znamená, že tomu nerozumíte. A že tomu nerozumíte jste ukázal hned tím vaším příkladem protože JS funguje zrovna v tomhle ohledu naprosto logicky.
A jQuery je prostě jQuery. Dnes už se naštěstí běžně rutinně nepoužívá na věci, na které se naprosto nehodí takže se dá používat jako užitečná knihovna ve specifických jednoduchých případech tam, kde smysl má. Černobílý problém z toho děláte vy.
Odpovedal som na toto:
> JavaScript je určite stabilnejší a zároveň je v ňom menej legacy softwaru a viac moderného softwaru než v Jave.
Co zjavne nie je pravda
> že tomu nerozumíte jste ukázal hned tím vaším příkladem protože JS funguje zrovna v tomhle ohledu naprosto logicky
Nie nefunguje to logicky, ako som pisal bezne sa tam pomyli aj senior programator a to je iba blbe porovnanie.
Myslim ze nikto si nemysli ze JS je skvely jazyk. Je to proste jazyk ktory ako JEDINY sa da pouzit na client side. Tu mate dalsie veci na zamyslenie ak si myslite ze JS je skvely jazyk:
https://medium.com/javascript-non-grata/the-top-10-things-wrong-with-javascript-58f440d6b3d8
https://thorprojects.com/2012/11/05/why-javascript-makes-bad-developers/
Ne, to že to zopakujete vícekrát z toho pravdu fakt neudělá. A navíc jsem nikde nepsal, že je to skvělý jazyk. To jste si zase vymyslel vy.
"Nie nefunguje to logicky, ako som pisal bezne sa tam pomyli aj senior programator a to je iba blbe porovnanie."
Tak potom nechápem ako to že ja som sa v tom nepomýlil ešte dávno dávno keď som bol junior programátor. Asi si vymýšľate, lebo skutočne si to nikto len tak nepomýli.
"Myslim ze nikto si nemysli ze JS je skvely jazyk."
Však to som tu tiež povedal. Žiaľ mám pocit že idete do boja proti mne s argumentom, ktorý so mnou súhlasí. "nemáš pravdu, ono je to X" zatiaľ čo ja tvrdím že je to "X" takže ako nemám pravdu?
Btw. tie články sú bludy ľudí čo sú zarytý vývojári v jazykoch využívajúci úplne iné princípy, a nadávajú na jedne veci, ale nevidia že v iných veciach je práve ich jazyk "big mistake of design". Aj Java robí ľudí špatnými programátormi. Učí ich písať boilerplate a designovať API ich knižníc či softwaru tak aby ktokoľvek kto používa ich softvér musel písať absurdné množstvá kódu. A množstvo kódu je priamo úmerné s potenciálnym množstvom BUGov.
"Co zjavne nie je pravda"
Lenže ono to pravda je. Hovorím o API. Dnes v prehliadači v pohode funguje webstránka čo bola napísaná ešte v minulom storočí. Zároveň ale je výrazne viac nového softvéru v JavaScripte než v Jave. V Jave máš minimum projektov, čo vznikajú dnes a používajú najnovšiu verziu Javy. V JavaScripte dnes aktívne sa vyvíja softvér v dnešných verziách Javy. Dokonca mnohý si nastavujú do jsconfig či eslint pravidiel "ESNext".
Inak mám tu dať článok TOP 1000 things wrong with Java?
Inak ten článok na medium "10 things wrong with JavaScript" je taký nezmysel až sa krútim hlavou. AngularJS, Lips? To čo sú za argumenty? Nejdeme taktiež povedať že v Java je špatná lebo nie je C# a má nejakú špatnú knižnicu čo už je dávno síce deprecated a bola používaná 20 rokov dozadu? Prvý argument že JavaScript, ale potom mi ukážte jazyk kde viete definovať číslo na tisíc cifier za desatinou čiarkou. Žiadny!!! Lebo to je sakra vlastnosť počítačov nie jazyka. Všetky argumenty tom článku sú totálne nezmysli.
23. 3. 2025, 15:07 editováno autorem komentáře
Už jsem starý, abych věřil v univerzální jazyk na vše a abych jako JS developer tady ten jazyk slepě chválil,ale ty 2 odkazy jsou přes 10 let staré a většina už fakt není pravda. I ty statické typy (pokud budeme ignorovat TS i když osobně ho beru jako evoluci JS) se do čistého JS pomalinku začínají dostávat (samozřejmě zatím ve fázi návrhu).
... jo a přidávám se k ostatním s tvrzením, že ten první článek je ve většině věcí dávno zastaralý a mimo a znovu tak jen ukazujete, jak vůbec nerozumíte tomu, o čem píšete. Druhý jsem raději ani nečetl.
Java (vrátane celého ekosystému) je hlavne nástroj úplne iného kalibru pre inú cieľovú skupinu, než JS. Porovnávať ju má zmysel tak s .NET a C# alebo s Go. JS (alebo PHP a do veľkej miery aj Python a pod.) popri tom je a bude hračka pre use cases, kde limitácie a inžinierske nedostatky jazyka, runtime a hurá prístup 3rd party vendorov neprekážajú. Na trochu rozsiahlejšie biznis backendy s dlhším životným cyklom je to úplne nevhodné.
To je pravda, ERLang je úplne iná kategória a práve by som povedal že Enterprise, kde chceme maximum stability, minimum BUGov, výkon, atď... tak je to asi fakt naj jazyk čo poznám. Inak ERLang je najviac OOP jazyk vôbec (viac než Java či C#), ak niekto chápe čo v skutočnosti OOP je (a že procesy sú v podstate izolované "objekty"), len preto že to nemá keyword "class" nič nemení na tom či je alebo nie OOP, mnoho ľudí si myslí že class === OOP. Čo nie je pravda. Je to len jedna možná implementácia OOP princípu v mnohých jazykoch (Java, C#), ale už v JavaScripte práve vidíme že "class" keyword môže byť použité aj na niečo úplne iné (ako syntax cukor).
23. 3. 2025, 15:27 editováno autorem komentáře
Erlang je objektový jazyk (jeden z mála).
Java je objektově orientovaný jazyk :-)
Na druhou stranu muselo to být. Musela vzniknout. Muselo se to stát, aby se ukázalo, že některé nápady prostě nejsou dobré.
Ja som bol vtom, že Objektovo-Orientované jazyky sú podskupinou objektových (object based), čo je širší pojem. OO jazyky spĺňajú "svätú trojicu", ostatné podskupiny idú na to ináč.
> Erlang je objektový jazyk (jeden z mála).
Na toto prosím zdroj. Dočítal som sa, že je actor-based, a že je funkcionálny. Nerozporujem, len nie je mi jasné, v čom je konkrétne objektový, tak nech to mám v nejakom článku vysvetlené.
Lebo sa mi zdá, že nie je, tak nech si upravím pohľad.
23. 3. 2025, 23:32 editováno autorem komentáře
Minule som len tak rozmýšľal, že je asi úplne jedno, čo Alan Kay myslel pôvodne že by OOP mohlo byť. Bol to nápad. Nápadov je nekonečno. Rozhodujúca je realizácia a tá, ktorá sa presadila vyzerá inak ako pôvodný nápad.
Původní Kayův nápad je realizován v podobě Smalltalku. Stručně řečeno, dynamicky typovaný jazyk založený na vzájemné komunikaci objektů prostřednictvím zpráv, na jejichž základě dotčený objekt rozhodne, jakou metodu aplikuje. (Objekty jakožto instance tříd, nové třídy vznikající děděním a kompozicí - ale to už není to nejpodstatnější.)
Rozlišení objektový jazyk a objektově orientovaný jazyk je nepřesné, Kay zavedl pro svou myšlenku pojem OOP, která se dnes používá i pro jazyky typu C++, jež vycházejí ze starší myšlenky, zhmotněné v podobě jazyka Simula 67 a dále rozvedené v knize Hoare, Dijkstra, Dahl: Structured Programming, 1972.
Odkaz na smalltalk som pochopiteľne čakal. Ale bez ohľadu na to, či sa mi smalltalk páči alebo nepáči, nedá sa povedať, že by sa presadil. A nedá sa ani povedať, že by sa presadilo pharo. Ktoré tak trochu sledujem. A je rozdiel realizácia, ktorá sa nepresadila a realizácia, ktorá sa presadila, aj keď nie úplne v zmysle pôvodnej myšlienky. Takže bez ohľadu na encyklopedické znalosti alebo čistú faktickú správnosť, OOP je to, čo si o tom myslí väčšina ľudí a to je dané jazykmi, ktoré sa presadili.