Java 18 met Simple Web Server verschijnt en JavaOne keert terug

Oracle heeft Java 18 beschikbaar gesteld. De nieuwe versie van de programmeertaal bevat negen nieuwe functies op basis van JDK Enhancement Proposals waaronder Simple Web Server voor het testen van code. De JavaOne-conferentie keert dit jaar terug.

Versie 18 van het Java-platform bevat volgens Oracle 'duizenden' verbeteringen voor prestaties, stabiliteit en beveiliging. In totaal hebben 2062 JIRA-issues een fix gehad, waarvan 1261 door Oracle en 801 door de Java-gemeenschap van ontwikkelaars. Van die fixes waren er 168 door individuen gedaan. Verder zijn er negen JDK Enhancement Proposals doorgevoerd. Zo betreft JEP 400 de wijziging dat UTF-8 voortaan de tekencodering is van de standaard Java-api's. Dit moet voor consistentie zorgen en onverwacht gedrag voorkomen, wat kon gebeuren bij het ontwikkelen en testen met de ene tekencodering en uitvoeren met de andere.

Simpel Web Server, JEP 408, biedt een tool om via command-line snel een eenvoudige webserver te starten op localhost:8000. Ontwikkelaars kunnen zo op simpele wijze zien hoe hun Java-code er op het web uitziet. Een derde JEP is 413, die het toevoegen van codesnippets aan de api-documentatie mogelijk maakt. Met behulp van de @snippet-tag voor JavaDoc kunnen ontwikkelaars eenvoudig voorbeeldcode in de api-documentatie plaatsen.

Oracle meldt tegelijkertijd dat JavaOne terugkeert en wel als onderdeel van de Oracle CloudWorld die van 16 tot en met 20 oktober plaatsvindt in Las Vegas. Het bedrijf belooft sessies op het gebied van Java in combinatie met database, microservices, DevOps en machinelearning. JavaOne was het jaarlijkse evenement voor Java-ontwikkelaars dat Sun Microsystems in 1996 voor het eerst hield. In 2018 maakte Oracle bekend dat het evenement zou stoppen en plaats moest maken voor het breder opgezette Oracle Code One.

Reacties (61)

[Zackito]

Werkt java nog steeds maar op 1 core?

[ChappIO]

Werkt java nog steeds maar op 1 core?

Niet meer. In 2006 kwam java 6 uit met uitstekende multi-threading support (java.lang.Thread). En de meeste webservers (jetty, tomcat, en nu simple webserver) ondersteunen dit standaard.

[Reactie gewijzigd door ChappIO op 24 juli 2024 06:56]

[dashorst248]

In 2006 kwam java 6 uit met uitstekende multi-threading support (java.lang.Thread).

java.lang.Thread zit al in Java sinds Java 1.0 (zie de Since sectie).

Jij doelt waarschijnlijk op de integratie van Doug Lea's concurrency framework in de JDK. En die is geïntegreerd met Java in 1.5 (ook bekend als Java 5).

Overigens, het huidige threading model van Java mapt een Thread op een operating system thread, waardoor dit nogal wat resources vreet. In de nabije toekomst willen ze daar lichtgewicht threads (Fibers) voor toevoegen die niet 1-1 mappen op het operating system, zodat je miljoenen threads kan draaien in plaats van honderden.

[Moortu]

Fibers is een andere benaming voor Coroutines.
Het concept van Coroutines bestaat al heel lang.
Kotlin, een programmeer taal die naar javabyte compiled, heeft een implementatie van Coroutines waardoor er miljoenen taken "tegelijk" kunnen draaien op een thread.

[!GN!T!ON]

Gebeurd dat onderwater dan ongeveer op dezelfde manier zoals in JS/Node met een event loop?

[Moortu]

Er zijn Coroutine dispatchers die een thread pool hebben.
Elke coroutine wordt door een dispatcher naar een thread in de pool gestuurd om te draaien.

Coroutines zijn, over het algemeen, suspendable. De Kotlin compiler maakt in principe callback functies van je suspendeable functies. Dit zorgt ervoor dat op elk suspend punt, de code stil gelegd kan worden, er iets anders op de thread gerunned kan worden, en dan kan de code weer verder gaan.

Het is gecompliceerder dan dit, maar dit is in een nutshell

[!GN!T!ON]

Dank je voor je uitgebreide antwoord! Als ik het goed begrijp werkt het dus niet helemaal zoals met NodeJS, want die maakt v.z.i.w. niet (standaard) gebruik van threadpools en losse threads per task / coroutine. Communicatie via callback functies klinkt wel Node achtig

[Moortu]

Het verschil is dat je niet zelf callbacks maakt, dat kan een zooitje worden.
Het is allemaal geregeld door de Kotlin compiler

[uiltje]

Nee, dit gaat nog verder terug naar "green threads". Doug Lea's concurrency framework is een van de briljantjes van Java, maar de "echte" multithreading zit er al in sinds versie 1.3.

[airell]

als je niet multi-threaded programmeert wel ja...

[Zackito]

Dan zal het programma van onze klant wel singlethreaded geprogrammeerd zijn

[vinsterdamus]

Een single threaded applicatie hoeft niet per definitie traag of "blocking" te zijn. Ik ontwikkel applicaties in Java met een toolkit genaamd vert.x dit zijn single threaded processen maar het maakt gebruik van een event loop om zo efficiënt mogelijk gebruik te maken van je hardware. Multi threading is niet gelijk aan concurrency. Multi threading kan zelfs negatief zijn gezien de cpu scheduling overhead met zich mee brengt

[jrswgtr]

Java kan gebruik maken van Multi-Threading

https://stackoverflow.com/a/3330440/8108407

[Reactie gewijzigd door jrswgtr op 24 juli 2024 06:56]

[jAnO!]

Neuh... sinds java 1 uit 1996 ondersteund het multithreading.

[uiltje]

Ja, maar green threads draaien wel degelijk op maar 1 core. Da's echter al anders sinds 2000 met de intro van Java 1.3.

[jAnO!]

:-) ben zelf bij java 2... (das 1.4 lieve kinderen) begonnen.

[DaCoTa]

Werkt java nog steeds maar op 1 core?

Huh? Ik denk dat je in de war bent met javascript in de browser. Java heeft al ruim een decennia multi-threading.

[Wielink]

Ik denk dat u doelt op JavaScript.

[Ozzie]

Volgens mij is Java altijd multi-threaded geweest. Dus weet niet waar je op doelt?

[fastedje]

Zelfs als je een single-threaded java programma gebruikt, dan nog zal de garbage collector op de achtergrond in een aparte thread aan de slag gaan. Dit gebeurt alleen als je dusdanig veel objecten of arrays gebruikt zodar de heap space vol gaat lopen.

[rvt1]

Wellicht ten overvloede, ik denk dat je javascript in gedachte heb dat maar een thread ondersteunt.
Er is nog wel zoiets als webworkers, maar dat is wel duidelijk anders dan multi-threading..

[Left]

Jij bent denk ik in de war met Javascript.

[dieAndereGozer]

Toen ik voor het eerst met java in aanraking kwam was er al multi threading, dat moet ergens in 2008 zijn geweest. Dus je bent 14 jaar out of date.

[uiltje]

Lost in a time warp? Serieus, green threads zijn al jaren geen ding meer op Java, sinds versie 1.3 (22 jaar geleden). Java is gemaakt voor concurrency, het heeft dingen als het synchronized, volatile etc. keywords al vanaf het begin. Tegenwoordig maak je natuurlijk gebruik van de functionaliteit in java.util.concurrent waarin de meeste abstracte constructies al zijn terug te vinden.

[boeie220]

denk de "nog steeds"... het is ook wel een hele vreemde vraag. Hoezo zou java niet multi-threaded zijn, dat is het al zeker 25 jaar wel...

[Groax]

Oeh, misschien wordt het weer eens tijd om PHP (Laravel) is los te laten en Java weer eens op te pakken

[Cristan]

Persoonlijk vind ik Java een beetje old school. Komt misschien ook uit mijn omgeving: ik heb al jaren geen Java meer gezien, iedereen is over op Kotlin. Je ziet bij de laatste Java versies dat ze functies uit Kotlin overnemen, maar gezien oude code het ook moet blijven doen vind ik het er toch wat hacky overkomen.

[ronaldmathies]

Java is niet alleen de Java API maar ook de JVM. Je weet wel, dat ding wat Kotlin nodig heeft om te kunnen draaien.

Dus elke verbetering aan Java die met de JVM te maken heeft is een verbetering voor Kotlin.

Als taal is Java misschien wat meer Old school maar nog steeds veel populairder dan Kotlin. Zie bijvoorbeeld de Stackoverflow Survey van 2021.

https://insights.stackove...echnologies-language-prof

Volgens de Tiobe index is de populariteit van Kotlin verwaarloosbaar:

https://www.tiobe.com/tiobe-index/

Volgens google trends is kotline ainds 2019 qua groei gestagneerd, en heeft het zelfs een flinke dip gehad tussen augustus 2020 en augustus 2021.

Dat jij het Jaren niet meer gezien hebt zegt misschien meer over jouw omgeving? Opdrachten?

[TheNooz]

Je statement over de JVM gaat alleen niet altijd op als je het hebt over Android apps maken in Kotlin.

[GertMenkel]

Sorry, maar een populariteitsindex did assembly in de top tien heeft vind ik niet bepaald betrouwbaar. Kijkend naar de Stackoverflow populariteitsindex staat Kotlin nog boven Rust, terwijl Rust onderhand steeds vaker begint voor te komen. Daar zijn Javascript en Python ook boven Java te vinden. Onder de professionals wordt NodeJS zelfs boven Java geplaatst.

Het is maar net waar je het voor gebruikt. In webapplicaties verwacht ik geen Kotlin te zien, in Android-apps verwacht ik geen Java te zien. Kotlin is mede dankzij Kotlin/native en Android ook al lang niet meer afhankelijk van de JVM, dat geldt alleen als je je code daadwerkelijk voor de JVM schrijft.

Er zijn ook hele gebieden die vooral op Microsoft en C# lijken te werken in plaats van Java. Sommige opleidingen gaan dan weer voor PHP of C++. Het is afhankelijk van waar je terecht komt welke programmeertaal je tegenkomt.

Ik ben zelf vooral opgeleid in C#, maar schrijf tegenwoordig (helaas) vooral Java.

[ari3]

Persoonlijk vind ik Java een beetje old school. Komt misschien ook uit mijn omgeving: ik heb al jaren geen Java meer gezien, iedereen is over op Kotlin. Je ziet bij de laatste Java versies dat ze functies uit Kotlin overnemen, maar gezien oude code het ook moet blijven doen vind ik het er toch wat hacky overkomen.

Kotlin heeft de laatste tijd wat momentum gehad, maar nu in Java 19 coroutines beschikbaar zullen komen, zijn er geen killer features meer die Kotlin bijzonder maken. Ik voorspel dat Kotlin uiteindelijk hetzelfde lot krijgt als Groovy, Scala en Clojure: tijdelijk momentum en goede aanjagers van innovatie, maar uiteindelijk niet mainstream en populair omdat Java het beste ervan heeft overgenomen.

[GertMenkel]

Kotlin heeft een aantal features waar Java gewoon niet aan wil (verplichte, expliciete nullability, bijvoorbeeld) waardoor ik denk dat Kotlin het nog wel even volhoudt.

De beknopte syntax is met bijvoorbeeld het ontwikkelen van Android-applicaties echt onmisbaar, dus ook daarom zal Kotlin nog blijven hangen, in elk geval tot Google naar Fuchsia overstapt voor hun mobiele platform.

[rvt1]

wellicht old school maar voor grote projecten is dit wel belangrijk. Tenslotte willen 'we' niet om de 4 jaar een gehele applicatie doorlopen omdat de taal veranderd is.. We willen updates, nieuwe features and zeer goede backwards compatibility.. En we willen dat het draait... altijd draait zonder uitzondering.

Voor veel bedrijven is dat een stuk belangrijker dan 'new' and 'shiny'.

Ok is java code , alhoewel old-school zeer goed leesbaar. Kotlin ook, maar daar is het wel makkelijker constructies te maken waarvan je kunt denken 'huuuuuu???'..

[k0enf0rNL]

In elke taal kan je constructies maken waarvan je niet snapt wat het doet als je het voor de eerste keer leest. Je kan niet een taal afschieten omdat mensen er niet mee om kunnen gaan en er troep mee bouwen.

[bzzzt]

Het is niet zo zeer dat er troep mee gebouwd wordt, maar dat een bepaalde subset van de programmeurspopulatie het schitterend vindt helemaal los te gaan op bv. functioneel programmeren. Dat is erg mooi en uitdagend om mee bezig te zijn, maar dat je code daarmee voor 90% van een toch al met tekorten worstelende beroepsgroep moeilijk begrijpbaar is wordt dan geen rekening mee gehouden.

Hoorde een paar jaar geleden op een Java conferentie iemand roepen: "Ik hou van Scala; bedrijven betalen mij fors om die code om te zetten in leesbaar Java".

[NielsFL]

Voor zover ik daar op let zie ik juist dat Kotlin apps plaats maken voor herschreven versies ontwikkeld met Flutter/Dart.

Geen idee of dat ook beter is, of dat deze devs simpelweg de hippe taaltjes van het moment volgen.

[bzzzt]

Google heeft even Kotlin gepushed als 'standaard' voor Android vanwege de rechtszaak met Oracle. Ik denk dat de 'typische' front-end developer zich meer thuisvoelt bij dingen als Dart omdat het meer op Javascript lijkt.

[ChappIO]

Als je zo een compleet framework zoekt als Laravel dan is Spring Boot een goede kandidaat. Het zou me niks verbazen als die binnenkort ondersteuning inbouwen voor deze nieuwe webserver.

[bzzzt]

Ik denk het niet: die nieuwe webserver is echt heel basic en kan alleen lokale bestanden serveren. Geen ondersteuning voor servlets e.d. dus zelfs voor Spring Boot te weinig functionaliteit.

[Groax]

Spring Boot ken ik, in combinatie met Hibernate is dit een super framework

[Jerre Muesli]

De beste projecten waarop ik gewerkt heb zijn nog steeds deze waar geen Hibernate in gebruikt is. Het komt met tal van tradeoffs en is uiteindelijk een draak van een ding.

[Cyb]

Hibernate/JPA heeft ook een aardige leercurve. Het gaat meestal mis om het moment dat een novice denkt even snel wat persistence code te kunnen toevoegen. Hibernate/JPA heeft inderdaad tradeoffs, maar alternatieven hebben ook weer andere tradeoffs.

[k0enf0rNL]

De tradeoffs zitten hem met name in de relaties en het ophalen/mappen van deze relaties. Waar je zou verwachten dat bij een relatie met fetchtype eager hij automatisch bedenkt dat hij dat in 1 query moet doen doet hij dat in de praktijk niet en gaat hij vrolijk een extra query uitvoeren voor iedere relatie.

[Cyb]

Met tradeoffs doel ik meer op dingen als performance, JPA requirements van entity classes t.o.v. ddd domain classen, proxing. (Als eager fetching niet werkt, terwijl je verwacht dat het wel zou moeten werken, dan heb je ergens iets in je code iets verkeerd.)

[gimbal]

Dat is maar hoe je het gebruikt. Je kunt ook gewoon native queries uitvoeren en dat zelfs eenvoudig laten mappen naar objecten. 0 rompslomp en gewoon maximale performance. Maar als dat je doel is dan is zoiets als JOOQ waarschijnlijk net wat meer relevant.

[k0enf0rNL]

Dan ga je toch voorbij aan het hele nut van Hibernate als je zelf queries gaat lopen bakken en dat naar objecten mapt?

[bzzzt]

Als Hibernate in een project zoveel overhead geeft dat het netto verlies in productiviteit oplevert is het toch niet nuttig?
Het een hoeft het ander ook niet uit te sluiten; je kan prima standaard 'CRUD' spul in Hibernate mappen en voor de spannende queries SQL of JOOQ gebruiken. (Hibernate kan trouwens ook prima arbitraire SQL naar objecten mappen)
100% Hibernate gebruiken zou geen doel op zich moeten zijn.

[k0enf0rNL]

En wat werd daar als alternatief gebruikt?

[youri_ajax]

En dan Kotlin ipv Java niet te vergeten.

[Ozzie]

Spring Boot heeft zelf gewoon een ingebouwde webserver, dus zie niet echt meerwaarde hierin voor spring boot.

[gimbal]

Niet echt ingebouwd want zo werkt Spring Boot nu eenmaal niet, het is modulair. Maar standaard wordt Tomcat meegepackaged als je spring-boot-web meepackaged. Je hebt de keuze om daar Jetty van te maken.

[k0enf0rNL]

Of Undertow

[adje123]

Haha ja, dat heb ik laatst ook gedaan en heb wel gemerkt dat het weer even erin komen is.

Kreeg wel een leuke meme van een vriend, naar aanleiding van dat ik Java weer heb opgepakt.
Op twitter vroeg Kim Kardashian een keer
"Can you guys please recommend books that made you cry"

Toen had een kerel op haar gereageerd met
"Data structures and algotimes in Java(2ndedition)"

Dat was wel herkenbaar.

[Cyb]

Java staat niet bekend om z'n vooruitstrevendheid

Sinds 2017 is Java van een feature drive release model naar een train model van een half jaar. Dus Java is nu een stuk vooruitstrevender dan bijv. 10 jaar geleden. Ook is Java veel meer dan alleen een taal, het is een platform, een verzameling van specificaties, een community, een host voor andere JVM talen, een *taal* waar diverse organisaties aan verbonden zijn. Als je bijv. Kotlin (taal) wilt leren, dan is het kennen van Java een vereiste om Kotlin goed te kunnen begrijpen. Het leren van Java als taal, is slechts de eerste en misschien wel de gemakkelijkste stap (als je al kan programmeren) op de roadmap om een Java developer te worden. Daarna kan je altijd nog *specialisaties* nemen als Kotlin, Scala, Clojure, als je meer er uit wilt halen dan Java als taal zelf biedt.

[arjohn]

Lekker kort door de bocht...

[gimbal]

Vooruitstrevendheid is niet hetgene wat robuuste oplossingen tot gevolg heeft. Leuk voor de hipsters maar de mensen die werk gedaan willen krijgen die pakken toch de tried and true methoden. Ja Java is oud en vrij log maar daar is de IDE voor uitgevonden.