Názory k článku
Java / JDK 18 má vlastní webový server
-
a proč bys to neměl dělat v javě? Přece si kvůli tomu nebudu instalovat python, ruby, php, když už mám javu, v které dělám. Ne všichni mají nainstalovaný python, ne všichni pracují s pythonem a je to další komponenta, kterou musíš udržovat, aktualizovat a starat se o ní.
Živíš se javou, ale vývoj bys raději dělat v pythonu? Nejsou ty jazyky až příliš vzdálené od sebe, aby je bylo možné rozumně zaměnit?
-
L.Stříbrný podporovatel
Tak, někdo se musí obětovat a zjistit, zda náhodou vyfukováním tabákového kouře do vody opravdu nevzniká zlato. To by bylo v pohodě. Horší je, když někdo takový postup adoptuje jako výrobní metodu.
24. 3. 2022, 07:27 editováno autorem komentáře
-
Protože běžně uvaděný "fakt", že Python je pro začátečníky, má velmi omezenou platnost. Platí do té doby, než se posuneš od školních příkladů. Moji kolegové často ani nevědí jak vytvořít balík (co to je setup.py, setup.cfg, pyproject.toml). A když se koukneš po GitHubu, většina lidí, co s ním pracuje, také nemají tuto znalost. Relativní importy všude, dokumentace a typy nikde. V tomhle Java přesně vyniká: "Dělá se to tak a tak, nevymýšlej kolo pane vývojáři."
24. 3. 2022, 08:15 editováno autorem komentáře
-
To je podobný problém, jako s C v Arduino projektech. Tam, kde je příliš velká "bastlířská" komunita se člověk brzo dostane do stavu, kdy při hledání rady a pomoci mu radí často ještě větší looser, než je ten člověk sám. Aby se samouk naučil nějakou technologii dobře, potřebuje kvalitní zdroje a vzory. Jenže u Pythonu, stejně jako u Arduina, na internetu převládají "rady" amatérů, kteří pořádně nevědí co a proč dělají, nad radami odborníků...
-
Stačilo by, kdyby ti, co učí Python, naučily ostatní aspoň ten `setup.py` a `python -m venv .venv`. Stačí tři řádky! Bohužel většina projektů (např. Deep Learning) většinou po stažení začíná zdlouhavým pročítáním všech skriptů, aby to šlo vůbec spustit. Už sem na to sepsal celý návod pro kolegy. Ale opravdu stačí jen toto:
import setuptools as st st.setup( name="project_name", version="0.1.0", install_requires=[ "whatever", ] )py -3.10 -m venv --upgrade-deps .venv .\.venv\Scripts\activate pip install -U -e . code .Raketová věda!
-
Myslím, že problém bude v tom, že v té větě chybí ještě zvratné zájmeno: "Stačilo by, kdyby *se* ti, co učí Python, naučili" ;-).
VŠ nechci soudit, byť jsou také plné teoretiků bez praxe, ale na středních školách často učí nadšenci, kterým bohužel velmi často chybí adekvátní vzdělání a schopnost kontaktu s praxí. Učí své dojmy a pokusy, které si zkouší zároveň s dětmi, což je mimo jiné dáno i zoufale špatným poměrem mezi časem na přípravu a časem přímé výuky a naprostou absencí použitelných výukových materiálů (a když už, tak v angličtině, které spousta kantorů nerozumí).
(Současná reforma informatiky to ještě podporuje spolu s konzumistickým nakupováním zbytečných technologií, pro které se po koupi hledá možnost, jak to využít, místo aby se nakupovalo podle potřeby toho, co se bude reálně používat k něčemu užitečnému.)
A pak jsou tu profi školení, která nejsou akreditovaná v systému DVPP - dalšího vzdělávání pedagogů, takže je problém je zaplatit a naproti tomu akreditované DVPP kurzy, které třeba v JMK vede zpravidla jedna "odbornice na všechno" (jméno jistě dohledáte) od kurzů modelování z hlíny, přes dějepis, matematiku až po typografii nebo databáze. Jaká je úroveň takového kurzu jistě tušíte...
-
Na relativnich importech neni nic spatneho. Requests - nejpouzivanejsi pythonni balik. https://github.com/psf/requests/blob/main/requests/sessions.py pouziva relativni importy.
-
Adam KaliszStříbrný podporovatelKdybyste si radši přečetl ten JEP https://openjdk.java.net/jeps/408 Je to doslova nalinkované v článku a není to nijak dlouhé čtení. Váš příspěvek v tomto světle vyvolává rozporuplné pocity.
-
Já jsem ten JEP právě četl a stále mi není jasné proč by tohle mělo být zrovna součástí JDK. Je pravda, že jsem ten komentář napsal asi blbě a bez kontextu si to může někdo špatně vyložit (jak je asi s diskuze vidět, ale zase je to komentář ke zprávičce, kde je to snad jasné). Takže správně jsem měl napsat:
Zda někdo stojí o statický webový server s Java. -
No nevím, jestli bych chtěl banku s Internet Bankingem postaveným na bastelní v Pythonu... To dneska už zavání stejným amatérismem jako školácké projekty v PHP. To raději slušné a výkonné bankovnictví v Javě...
Jinak doporučuju dostudovat si rozdíl mezi jednorázově spouštěnými skripty v jazycích jako Python nebo PHP a deployovanou Java aplikací do Tomcatu. Má to docela dost zásadní "architektonické" rozdíly.
-
Což ale nic neříká o Pythonu. Pokud chceš robustní řešení, tak architektura je to hlavní. Jazyk a nástroje můžou pomoci, ale nezachrání tě. Zkušený člověk zná limity vývoje v Pythonu a nedělá v nich molochy, které Java sice unese, ale popravdě, je to spíš z nouze ctnost. BTW: Pokud se prosadí GraalVM, myslím že těch projektů v Pythonu, Ruby v kombinaci s Javou může přibývat.
-
Jenže se vyjadřujete naprosto k něčemu úplně jinému. Kouknul jste se co ten JEP 408: Simple Web Server je? Je to jenom statický webový server to nikdo normální v produkci používat nebude.
Provide a command-line tool to start a minimal web server that serves static files only. No CGI or servlet-like functionality is available. This tool will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts.
Když už chcete někoho poučovat, tak byste se měl podívat, jak to je právě třeba s Python abyste tu nepsal nesmysly o deployování.
-
V době kdy jsem dělal v Javě a všude java nainstalovaná byla (což dnes zdaleka neplatí kvůli licenci od Oracle), tak bych tohle uvítal. Dnes všude převládá Python, takže na use case "potřebuji zobrazit tohle v prohlížeči" je to jedno a člověk sáhne po tom co je zrovna nainstalované. Mimochodem, jednoduchý web server dneska spustíte i v PowerShellu ;)
-
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.
-
Najzaujímavejšie je podľa mňa Foreign Function & Memory API . Zjednoduší to tvorbu Java wrapperov pre C/C++ knižnice.
Čo sa týka UTF8, tak ešte do Java 11 ste nemohli použiť FileReader, lebo ten bol natvrdo nastavený tak, že použil kódovanie OS. Java 11 pridala zvlášť parameter pre kódovanie. Takže tejto krok zjednoduší prácu programátorom, aby nevznikali takéto míny.
Zaujímavé je, že v poslednej dobe viaceré jazyky zabudovali pokročilí pattern matching, napr. PHP či Python. Toto Javacke riešenie sa mi ale nepáči.
Zabudovaný web server, úplne v pohode vec.
