Vlákno názorů k článku
Java / JDK 18 má vlastní webový server
od 0x00 - To je pěkný, že už je JDK 18,...
-
NESÚHLASÍM. Vysvetlenie:
Povieš si že je to 10 verzií do zadu. LENŽE, od verzie 11 po verziu 17 nebola žiadna LTS verzia. 5 verzií boli non-LTS,... LTS verzia 17 vyšla len pred pol rokom, teda málo času na migráciu softvéru. Takže je úplne normálne a bežné že dnes sú Java projekty ešte stále na verzii 11 alebo aj 8. Taktiež Oracle a Java moc na kompatibilitu medzi verziami nehľadí, a teda migrácie na novšiu verziu sú komplikovanejšie. U iných jazykoch bežne vidím že prejdem na novú verziu v podstate bez akejkoľvek zmeny kódu. V prípade Javy tomu tak nie je, a už prechod medzi verziou 8 a 11 bol značne komplikovaný. Takže by som ani nehovoril že je to až tak prekážka na stane zamestnávateľa. Navyše prechod z 8 na 11 moc veľký význam nemalo, pretože práve výhody z prechodu sú menšie než náklady na prechod. Nie to že ešte rozdiel medzi týmito 2 LTS verziami v podpore je len 1 a pol roka pre "Premier Support", a navyše verzia 8 má extended podporu ešte o 4 roky dlhšiu, než verzia 11. Btw. inak je toto rozhodne blbé, keďže už mnoho vývojárskych nástrojov Javu resp. JDK 8 nepodporuje (vrátane napr. SonarLint).
Takže sa ani takému stavu v Jave nedivím a skutočne, verzia 8 je najviac používanou verziou Javy aj dnes.
23. 3. 2022, 16:44 editováno autorem komentáře
-
Mám opačnou zkušenost. Zatímco PHP výrazně mění své chování pomalu v každé tečkové verzi u Javy se na kompatibilitu dbá. Toho pláče nad změnami PHP jsem si jako správce užil velmi, když byla na serveru o hlavní řadu nebo dvě nižší verze než byli programátoři zvyklí. Což samozřejmě nevylučuje to, že pokud někdo použije něco, co je označeno za zastaralé a tedy časem určeného ke zrušení, že může být s novou verzí nepříjemně překvapený. Místo Javy od Oracle roky používám OpenJDK - dnf install a o aktualizaci se stará distributor linuxu stejně jako o ostatní rpm v systému. Podle mě je správné, že se programovací jazyk nějak vyvíjí. Např. v 10 se do Javy dostaly věci, do té doby možné jen například díky guava. V Javě si myslím, že se změny dějí dostatečně opatrně (anotace, lambda). Psalo se tu, že Python už v systému je. Aby nebyl, když je zvykem pomocí něj konfigurovat system. Podobně bych mohl argumentovat Perlem. Sotva najdete linux, kde Perl nebude vůbec nainstalovaný. Pokud chcete mít PHP rychlé, stejně použijete např. FastCGI a s FastCGI budete mít rychlý i web s Perlem. I v Perlu jde psát čitelně s use strict.
-
PHP podle mě nejprve hledalo inspiraci v Perlu (proměnné začínající $ - regulární výrazy PCRE, které tvoří knihovna Perlu), později zase hledalo inspiraci v Javě (například výjimky). Ano ty bouřlivé změny. Díval jsem se kdysi do zdrojů PHP a našel lexikální analýzu a pak jen odskoky na procedury. Podobně jako v Basicu na osmibitech. Přiznám se, že Python jsem úplně vynechal, tam mě odradila jeho pomalost, to možná dnes nebude až takový problém. Možná by bylo dobré uvést, co bylo tak značně náročné při přechodu na novější verzi Javy. Něco s šifrováním nebo certifikáty? Myslím, že přechod Python 2 -> Python 3 také není úplně bez potíží, pořád mám v systému nějaké Python 2 balíčky a to používám nejnovější Fedoru. Dnes se web často dělá jinak. To se stáhne jar s javascriptem celé aplikace, která se pomocí REST dotazuje serveru a je jedno v čem je server napsaný
-
A co teprve Raku (https://www.raku.org/)! K Perlu jsem si nikdy nevytvořil špatný vztah, tak jako k PHP :D
-
Vaše diskuze o PHP mi připomněla tohle. Sice to není vyloženě o vývoji jazyka v čase, ale je tam zajímavá anekdota ohledně toho, jak se k jeho vývoji staví jeho autoři.
-
tohle je ještě dobrý bug, je to aspoň celou historii php konzistentní. Ale třeba taková varianta s strtotime('0000-00-00 00:00:00') se změnila už asi 4x a poslední velká změna nastala v 5.2.6 (musel jsem dohledat) odkudy to vyhazuje logický výsledek -62169985172, který ale nevadí funkci date a uklidně to převede na datum.
-
U PHP jsem se naučil, že je vhodný přístup si sám validovat to, co posílám do jeho funkcí a sám si ošetřovat okrajové podmínky. Spoléhat se na tento typ chování a třeba na to, že "00" je "2000" a "0000" by mělo být invalidní (nemluvě o tom, že vlastně netuším, jak se vlastně autor staví k "000") umí člověka nehezky kousnout.
Naštěstí v PHP nemusím trávit moc času.
-
Tak ten přechod mezi verzemi a zpětná kompatibilita je právě ta obrovská výhoda Java. Problémy mezi verzemi jsou opravdu minimální. Chtěl bych vidět tak používaný jazyk, který je na tom se zpětnou kompatibilitou lépe, je potřeba se taky podívat, že ten jazyk vznikl v roce 1996. Mezi Java 8 a Java 11 se odebraly akorát javax package ze standardní knihovny, takže pokud je někdo používal mohl si je krásně přidat zvlášť, jestli tohle je komplikovaný problém tak nevím co by už byl nekomplikovaný. Migrace mezi Java 11 a 17 je naprosto bezproblémová pokud nepoužíváte nějaké interní věci, které se tam více zapouzdřily, ale i to jde stále obejít.
-
A ještě k těm verzím tak o tom by se také dalo dost polemizovat. Pokud bereme opravdu nejpoužívanější verzi Java 8 tak ano ale pokud bychom porovnávali Java 8 vs Java 9+ tak už to bude +- na stejno. Dokonce podle JRebel 2022 Java Developer Productivity Report používá v hlavní aplikaci: Java 8 - 37%, Java 11 - 29% a Java 12+ 12%
-
Problém je, že v PHP rozbíjejí kód zhusta i minor verze. Takže v praxi máš support pro čerstvě napsanou apku tak na 2 roky. V praxi to pak vypadá tak, že ops zahlásí, že končí podpora PHP a že musí nasadit novější. Devs zjistí, že použité Nette s novým PHP není kompatibilní a X knihoven zase není kompatibilní s novým Nette a nové nejsou nebo se chovají jinak. Nemluvě o tom, že zpětná kompatibilita Nette je také na horrorovou telenovelu. Odhad manhours zhruba stejný, jako 3/4 vývoje původní apky. Devs mají živobytí na dalšího půl roku. Tím vzniká takový cyklicky pracující ekosystém. Z jedné strany se sypou peníze a uvnitř roste BMI vývojářů. Navenek se nemění nic, na nové fíčury není čas.
-
Filip JirsákStříbrný podporovatelV Javě se až do verze 9 udržovala kompatibilita API až zpět k verzi 1.0. Teprve v té 9 se připustilo, že by se vůbec o nějakém odstranění mohlo uvažovat. Takže odstraňování je v Javě pořád ještě dost novinka.
