Tag: groovy, jvm, java, gradle, jenkins, scripting
Livello: intermedio
TL;DR: Sintassi sintetica e dinamica su JVM, 100% interoperabile con Java, standard per Gradle, Jenkins Pipeline e automazioni backend.
Linguaggio orientato agli oggetti su JVM con tipizzazione opzionale, dinamica o statica.
Interoperabilità trasparente e bidirezionale con tutto l'ecosistema e il bytecode Java.
Supporto nativo alle Closures con passaggio implicito del parametro it.
Operatore Safe Navigation ?. per prevenire NullPointerException nell'accesso a proprietà.
Operatore Elvis ?: per dichiarare fallback rapidi su espressioni nulle o false.
Groovy Truth per valutazione booleana implicita su stringhe, numeri e collezioni.
Sintassi letterale semplificata per la dichiarazione e manipolazione di liste e mappe.
String interpolation tramite GString delimitate da doppi apici con sintassi ${var}.
Metaprogrammazione dinamica a runtime con ExpandoMetaClass e a compile-time tramite AST.
Ruolo primario come DSL per build tool come Gradle e automazioni CI/CD.
Q: Che differenza c'è tra una Closure Groovy e una Lambda Java?R: Una closure Groovy è un'istanza della classe Closure con delegazione dinamica dello scope (owner, delegate, this), mentre la lambda Java è un'implementazione fortemente tipizzata di un'interfaccia funzionale.
Q: Come si comporta l'operatore di uguaglianza == rispetto a Java?R: In Groovy l'operatore == invoca automaticamente .equals() proteggendo da null pointer, mentre per verificare l'uguaglianza dei riferimenti in memoria si usa l'operatore .is().
Q: Perché e quando si usa l'annotazione @CompileStatic?R: La uso per abilitare il type checking a tempo di compilazione e produrre bytecode diretto identico a Java, eliminando l'overhead dinamico nelle sezioni critiche per le performance.
Confondere le stringhe con apici singoli (standard Java) e doppi apici (GString interpolabili).
Degrado prestazionale nell'uso intensivo del dynamic dispatch senza opportune ottimizzazioni statiche.
Comportamento inatteso con operatori booleani quando si ignora la logica del Groovy Truth.
Risoluzione errata delle variabili nelle pipeline Jenkins per via dei diversi binding di esecuzione.
// Inizializzazione collezioni e safe navigation
def user = [name: 'Marco', address: null]
def city = user?.address?.city ?: 'Roma'
// Closures, collezioni e Groovy Truth
def numbers = [1, 2, 3, 4, 5]
def evens = numbers.findAll { it % 2 == 0 }.collect { it * 10 }
if (evens) {
println "Numeri elaborati: ${evens.join(', ')}"
}
// Classe con AST Transformations
import groovy.transform.Canonical
@Canonical
class Developer {
String name
String role
}
[ ] Strategie di risoluzione dei delegati nelle Closures (delegate, owner, thisObject).
[ ] Annotazioni AST comuni (@ToString, @EqualsAndHashCode, @CompileStatic, @TupleConstructor).
[x] Sintassi e utilizzo di Safe Navigation ed Elvis Operator.
[x] Costrutti base per pipeline Jenkins scriptate e dichiarative.
Apache Groovy Documentation (docs.groovy-lang.org)
Gradle User Manual
Jenkins Pipeline Syntax Reference