[ANN] nuovo meeting 23 settembre: Java 25 updates
4 views
Skip to first unread message
Roberto Franchini
Sep 16, 2025, 5:13:46 PMSep 16
to JUG Torino - JVM User Group Torino
Ciao a tutti,
torniamo online il 23 settembre, alle 18.30 su youtube, con Simone Bordet che ci presentera' gli aggiornamenti di Java 25.
Dettagli su meetup:
PS; se avete proposte per i prossimi talk, fatevi avanti!
-- Roberto Franchini
"The impossible is inevitable"
https://github.com/robfrank/
https://twitter.com/robfrankie
https://www.linkedin.com/in/robfrank
"The impossible is inevitable"
https://github.com/robfrank/
https://twitter.com/robfrankie
https://www.linkedin.com/in/robfrank
Andrea Ligios
Sep 24, 2025, 10:36:39 AMSep 24
to Roberto Franchini, JUG Torino - JVM User Group Torino
In seguito al talk di ieri, ho aggiornato l'Epica che già avevo creato per migrare tutto a Java 25, aggiungendo le modifiche consigliate 😉
Non vedo l'ora di avere tempo di giocarci (in ogni caso, entro fine anno sarà tutto in produzione).
Come sempre, grazie Simone (e grazie Frank, e viva il JUG)! 🖖🏻
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugtorino/CAMpo0wgNoc4m%2Bcm%3D6pj-NGwtLfVL46mPnKH2SSBV66NiHXG2MA%40mail.gmail.com.
Roberto Franchini
Sep 24, 2025, 10:42:03 AMSep 24
to JUG Torino - JVM User Group Torino, Simone Bordet
Una domanda che non ho fatto ieri a @Simone Bordet .
Meglio ZGC o Shenandoah?
O forse: ci sono scenari dove uno e' meglio dell'altro?
Andrea Ligios
Sep 24, 2025, 12:24:14 PMSep 24
to Roberto Franchini, JUG Torino - JVM User Group Torino, Simone Bordet
Se lo chiedi a Google, Gemini ti risponde con un video di Simone :D
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugtorino/CAMpo0wg3qno7hq%3Dz%2Bhf2Nq6ie31jN5%2BYBrc11tNpyYf4uu2evA%40mail.gmail.com.
Francesco Vasco
Sep 24, 2025, 1:09:00 PMSep 24
to JUG Torino - JVM User Group Torino, Simone Bordet
Anche io sono interessato.
Ho fatto delle prove ed ho notato un consumo di CPU costante con Shenandoah generazionale.
Non ho approfondito, ed onestamente dubito di essere stato il primo a identificare un problema così lampante.
A prescindere, resto curioso della risposta, nello specifico per JVM con heap<32GiB (+ComressedOops).
Francesco
Simone Bordet
Sep 25, 2025, 11:58:34 AMSep 25
to Roberto Franchini, JUG Torino - JVM User Group Torino
Ciao,
On Wed, Sep 24, 2025 at 4:42 PM Roberto Franchini
<ro.fra...@gmail.com> wrote:
>
> Una domanda che non ho fatto ieri a @Simone Bordet .
> Meglio ZGC o Shenandoah?
> O forse: ci sono scenari dove uno e' meglio dell'altro?
Personalmente, ho una predilezione per ZGC. L'algoritmo è lo stesso si
Azul Zing C4, l'implementazione è diversa, ma comunque siamo su piani
simili.
L'attività su ZGC è quella che fa da driver per tutti gli altri GC.
Ci sono state diverse features che sono state proposte dal team di
ZGC, implementate in ZGC e solo dopo portate su G1 e altri GCs, quindi
la ricerca è su ZGC e sai che sei sempre all'avanguardia.
E questo vale per OpenJDK in generale, non solo per Oracle JDK.
Detto questo, non ho seguito gli ultimi dettagli di Shenandoah.
L'ultima volta che ho guardato Shenandoah usava un forward pointer
piazzato _prima_ dell'object header, mentre ZGC usa colored pointers.
Questo vuol dire che Shenandoah usa più memoria, un po' in contrasto
con Compressed Object Headers, mentre ZGC usa dei bits nel puntatore e
non richiede memoria in più.
C'era comunque in programma per Shenandoah di rimuovere il forward
pointer e sovrascrivere direttamente l'object header, quindi magari
non è più un problema.
Però Shenandoah è disponibile per Java 8, credo x32, e supporta
compressed oops per heap < 32 GiB.
Alla fine dovete provare e fare dei benchmarks per il vostro caso.
Penso che in entrambi i casi si tratti di vedere quanta CPU in più
consumano ma credo che per entrambi si passi da una automobile
utilitaria a un aeroplano.
Magari c'è differenza tra i due aeroplani, ma il problema di fare GC
in modo efficiente a pausa zero è risolto.
DI ZGC mi piace anche l'autotuning e il GC logging con statistiche
avanzate (non so in Shenandoah).
Se fate dei benchmarks, fare sapere i risultati :)
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
On Wed, Sep 24, 2025 at 4:42 PM Roberto Franchini
<ro.fra...@gmail.com> wrote:
>
> Una domanda che non ho fatto ieri a @Simone Bordet .
> Meglio ZGC o Shenandoah?
> O forse: ci sono scenari dove uno e' meglio dell'altro?
Azul Zing C4, l'implementazione è diversa, ma comunque siamo su piani
simili.
L'attività su ZGC è quella che fa da driver per tutti gli altri GC.
Ci sono state diverse features che sono state proposte dal team di
ZGC, implementate in ZGC e solo dopo portate su G1 e altri GCs, quindi
la ricerca è su ZGC e sai che sei sempre all'avanguardia.
E questo vale per OpenJDK in generale, non solo per Oracle JDK.
Detto questo, non ho seguito gli ultimi dettagli di Shenandoah.
L'ultima volta che ho guardato Shenandoah usava un forward pointer
piazzato _prima_ dell'object header, mentre ZGC usa colored pointers.
Questo vuol dire che Shenandoah usa più memoria, un po' in contrasto
con Compressed Object Headers, mentre ZGC usa dei bits nel puntatore e
non richiede memoria in più.
C'era comunque in programma per Shenandoah di rimuovere il forward
pointer e sovrascrivere direttamente l'object header, quindi magari
non è più un problema.
Però Shenandoah è disponibile per Java 8, credo x32, e supporta
compressed oops per heap < 32 GiB.
Alla fine dovete provare e fare dei benchmarks per il vostro caso.
Penso che in entrambi i casi si tratti di vedere quanta CPU in più
consumano ma credo che per entrambi si passi da una automobile
utilitaria a un aeroplano.
Magari c'è differenza tra i due aeroplani, ma il problema di fare GC
in modo efficiente a pausa zero è risolto.
DI ZGC mi piace anche l'autotuning e il GC logging con statistiche
avanzate (non so in Shenandoah).
Se fate dei benchmarks, fare sapere i risultati :)
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Danilo Ventura
Sep 26, 2025, 12:04:36 PMSep 26
to JUG Torino - JVM User Group Torino
Ciao a tutti... Preso dall'entusiasmo, ho proceduto oggi a migrare il mio progetto Spring Boot da Java 21 a Java 25.
Ho adoperato il plugin maven di Open Rewrite e non ho riscontrato particolari difficoltà ma solo alcuni inconvenienti che vi elenco e che magari possono tornare utili.
Il primo problema l'ho riscontrato con il maven plugin di jib che adopero per creare l'immagine docker del mio progetto. L'ultima versione (la 6.4.6) da un errore quando si tenta di buildare l'immagine docker:
--> failed to execute goal com.google.cloud.tools:jib-maven-plugin:3.4.6:dockerBuild (default-cli) [...] the root cause is from ASM ClassReader about unsupported class file version, see https://github.com/GoogleContainerTools/jib/blob/master/docs/faq.md#i-am-seeing-unsupported-class-file-major-version-when-building: Unsupported class file major version 69
Il workaround, in attesa che esca la nuova versione del plugin, è stato di overridare per jib le dipendenze org.ow2.asm con la versione 9.8.
L'altro problema, forse più curioso, l'ho trovato con lo Spring Boot Maven Plugin (sto usando la versione 3.5.6 di Spring Boot, che è l'ultima). In pratica dopo che Open Rewrite mi ha rimosso "public static" dai miei metodi main, runnando "mvn build", nel mio progetto multimodulo, lo spring-boot maven plugin non trovava più i main. Qui il mio workaround è stato revertare i main e dire ad Open Rewrite di lasciarli così come sono per il momento.
Spero che la mia esperienza possa essere utile.
Buon weekend
Ho adoperato il plugin maven di Open Rewrite e non ho riscontrato particolari difficoltà ma solo alcuni inconvenienti che vi elenco e che magari possono tornare utili.
Il primo problema l'ho riscontrato con il maven plugin di jib che adopero per creare l'immagine docker del mio progetto. L'ultima versione (la 6.4.6) da un errore quando si tenta di buildare l'immagine docker:
--> failed to execute goal com.google.cloud.tools:jib-maven-plugin:3.4.6:dockerBuild (default-cli) [...] the root cause is from ASM ClassReader about unsupported class file version, see https://github.com/GoogleContainerTools/jib/blob/master/docs/faq.md#i-am-seeing-unsupported-class-file-major-version-when-building: Unsupported class file major version 69
Il workaround, in attesa che esca la nuova versione del plugin, è stato di overridare per jib le dipendenze org.ow2.asm con la versione 9.8.
L'altro problema, forse più curioso, l'ho trovato con lo Spring Boot Maven Plugin (sto usando la versione 3.5.6 di Spring Boot, che è l'ultima). In pratica dopo che Open Rewrite mi ha rimosso "public static" dai miei metodi main, runnando "mvn build", nel mio progetto multimodulo, lo spring-boot maven plugin non trovava più i main. Qui il mio workaround è stato revertare i main e dire ad Open Rewrite di lasciarli così come sono per il momento.
Spero che la mia esperienza possa essere utile.
Buon weekend
Il giorno mar 16 set 2025 alle ore 23:13 Roberto Franchini <ro.fra...@gmail.com> ha scritto:
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugtorino/CAMpo0wgNoc4m%2Bcm%3D6pj-NGwtLfVL46mPnKH2SSBV66NiHXG2MA%40mail.gmail.com.
- Danilo Ventura -
Reply all
Reply to author
Forward
0 new messages