Java / JDK 18 má vlastní webový server

Zajímalo by mě zda opravdu někdo stojí o webový server s Java. Když jsem něco takového potřeboval tak jsem použil Python, ale že by mě napadlo na to použít Java.

Odhaduju, že použití bude stejné jako v Pythonu, tj. na rychlé rozběhnutí při vývoji nebo testech. Kdy není potřeba mít puštěné nějaké těžkotonážní řešeni (i Nginx je složitější než "python -m http.server", o Apachi nemluvě).

No ale proč bych to měl dělat zrovna v Java? V testech je lepší mít nějakou knihovnu jako třeba Wiremock a i pro ten vývoj bych šáhnul spíš po Pythonu a to se Javou živím.

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?

Není Python súčasť väčšiny distier? Java naopak nie je, a musíš si nainštalovať.

23. 3. 2022, 18:05 editováno autorem komentáře

Živíte se Javou a divíte se proč na web Java? A co tomcat, jboss jetty, glassfish ... Ty nejsou v Java?

Ale takhle to není. Otázka je proč použít statický web server v Java.

24. 3. 2022, 11:55 editováno autorem komentáře

Python fakt není odpověď na vše ;)

Leckdo dokonce tvrdí, že jazyk, kde obsazení nese syntetický význam, je odpovědí pouze na jednu jedinou, ale nelichotivou otázku ;-) Před léty jsem byl nucen opravit záhadně se chovající pythoní soft. Po opravě vypadal identicky jako před. Velká bžunda.

Kdybyste 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.

Presne tak, staci se podivat na odkaz ze zpravicky "This tool will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts.".

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í.

Nemate predstavu o deployovani pythonu.

24. 3. 2022, 15:25 editováno autorem komentáře

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 ;)

To je pěkný, že už je JDK 18, když nám všechno běží na javě 8 a fallbackem na javu 6.

Prekazka na strane zamestnavatele ;-)

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

Tak LTS je Java 8 (2014), 11 (2018), 17 (2021) a 21 (2023). Mezi nimi je dost času na přechod. To je stálý problém enterprise řešení, že se fixují na verzi prostředí aby si za upgrade mohli nechat tvrdě zaplatit :)

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.

Ak to porovnávaš s PHP, tak jasné že sa ti zdá že Java na kompatibilitu dbá... totiž PHP je ešte výrazne viac búrlivejšie, je to jazyk v ktorom sa mení všetko čo verzia. Dokonca v ňom je bežne aj 10 rôznych funkcií čo robí jednu a tú istú vec.

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.

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%

“Pěkný” je, že už nebudou finalizéry :)

Považují se za zastaralé už od 9 a zastaralé věci se časem odstraňují

Jasně, tak ony fungují dost mizerně, ale hodně knihoven na ně spoléhá.

V 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.

On to někdo fakt používá?

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.