Spring Boot YAML vs Properties: Confronto Configurazioni e Domande da Colloquio 2026
Confronto tra application.yml e application.properties in Spring Boot 4.1: sintassi, file multi-profilo, regole di precedenza, secret cifrati con Jasypt e le domande sulla configurazione nei colloqui.

Spring Boot offre due formati principali per la configurazione delle applicazioni: YAML e Properties. Entrambi i formati servono allo stesso scopo, ma differiscono significativamente in sintassi, leggibilità e casi d'uso. Il confronto che segue mostra le differenze pratiche e le domande da colloquio che emergono sulla configurazione esternalizzata di Spring Boot.
YAML è adatto ai progetti con configurazione profondamente annidata o con più profili. Properties è adatto alle configurazioni semplici e piatte, o ai team poco familiari con la sintassi YAML.
Spring Boot Properties vs YAML in sintesi
Con Spring Boot 4.1, la linea di release attuale, entrambi i formati alimentano lo stesso Environment e vengono associati in modo identico. Le differenze riguardano la sintassi, alcune regole di caricamento e il comportamento quando esistono entrambi i file.
| Caratteristica | YAML | Properties |
|---|---|---|
| Configurazione annidata | Gerarchia nativa | Notazione a punti |
| Più profili in un solo file | Separatore --- | Separatore #--- o !--- |
| Sintassi delle liste | Array YAML nativi | Notazione a indici [0], [1] |
| Commenti | # su qualsiasi riga | # o ! su qualsiasi riga |
Caricabile con @PropertySource | No | Sì |
| Entrambi i file nella stessa posizione | Sovrascritto | Ha la precedenza |
| Curva di apprendimento | Sensibile all'indentazione | Minima |
Le ultime due righe sono quelle che i candidati trascurano più spesso. La documentazione di riferimento di Spring Boot sulla configurazione esterna specifica che i file YAML non possono essere caricati tramite @PropertySource o @TestPropertySource e che, quando application.properties e application.yml si trovano nella stessa posizione, vince il valore di .properties. La raccomandazione ufficiale è scegliere un solo formato per l'intera applicazione.
Differenze Sintattiche Fondamentali
La differenza fondamentale risiede nella strutturazione dei valori di configurazione. I file Properties utilizzano una struttura piatta chiave-valore, mentre YAML rappresenta dati gerarchici con indentazione.
Formato Properties
# application.properties
server.port=8080
server.servlet.context-path=/api
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=admin
spring.datasource.password=${DB_PASSWORD}
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=falseFormato YAML
# application.yml
server:
port: 8080
servlet:
context-path: /api
spring:
datasource:
url: jdbc:postgresql://localhost:5432/mydb
username: admin
password: ${DB_PASSWORD}
jpa:
hibernate:
ddl-auto: validate
show-sql: falseVantaggi della Configurazione YAML
YAML offre diversi vantaggi per configurazioni complesse. La struttura gerarchica riduce la ridondanza e migliora significativamente la leggibilità.
# Profili multipli in un singolo file
spring:
profiles:
active: development
---
spring:
config:
activate:
on-profile: development
datasource:
url: jdbc:h2:mem:devdb
driver-class-name: org.h2.Driver
logging:
level:
root: DEBUG
com.example: TRACE
---
spring:
config:
activate:
on-profile: production
datasource:
url: jdbc:postgresql://prod-server:5432/proddb
driver-class-name: org.postgresql.Driver
logging:
level:
root: WARN
com.example: INFOLa separazione dei documenti con --- permette di definire più profili in un singolo file. Questo consolidamento semplifica la gestione delle impostazioni specifiche per ambiente.
I file Properties supportano lo stesso layout multi-documento. Una riga che contiene soltanto #--- (o !---) divide il file in documenti:
# application.properties
spring.profiles.active=dev
#---
spring.config.activate.on-profile=dev
server.port=8080
logging.level.root=DEBUG
#---
spring.config.activate.on-profile=prod
server.port=80
logging.level.root=WARNIl separatore non deve avere spazi iniziali e deve contenere esattamente tre trattini. Da Spring Boot 2.4 la proprietà spring.config.activate.on-profile ha sostituito la vecchia sintassi spring.profiles, in entrambi i formati.
"I file Properties richiedono un file per profilo" è una risposta sbagliata frequente. I file .properties multi-documento esistono da Spring Boot 2.4. Il vero limite riguarda YAML: non può essere caricato con @PropertySource.
Attivazione dei profili, gruppi e bean @Profile sono trattati nel modulo di colloquio su profili e ambienti.
Liste e Strutture Dati Complesse
YAML gestisce liste e strutture nidificate in modo più naturale rispetto ai file Properties.
# Lista di server
application:
servers:
- host: server1.example.com
port: 8080
ssl: true
- host: server2.example.com
port: 8081
ssl: false
allowed-origins:
- https://example.com
- https://app.example.com
- https://admin.example.com
features:
authentication:
enabled: true
providers:
- oauth2
- ldap
caching:
enabled: true
ttl: 3600Il formato Properties equivalente richiede notazione indicizzata:
# Stessa configurazione in Properties
application.servers[0].host=server1.example.com
application.servers[0].port=8080
application.servers[0].ssl=true
application.servers[1].host=server2.example.com
application.servers[1].port=8081
application.servers[1].ssl=false
application.allowed-origins[0]=https://example.com
application.allowed-origins[1]=https://app.example.com
application.allowed-origins[2]=https://admin.example.com
application.features.authentication.enabled=true
application.features.authentication.providers[0]=oauth2
application.features.authentication.providers[1]=ldap
application.features.caching.enabled=true
application.features.caching.ttl=3600Binding delle Configuration Properties
Spring Boot consente il binding type-safe della configurazione con l'annotazione @ConfigurationProperties:
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;
import java.util.List;
@Component
@ConfigurationProperties(prefix = "application")
public class ApplicationConfig {
private List<ServerConfig> servers;
private List<String> allowedOrigins;
private FeaturesConfig features;
// Getters and setters
public static class ServerConfig {
private String host;
private int port;
private boolean ssl;
// Getters and setters
}
public static class FeaturesConfig {
private AuthConfig authentication;
private CacheConfig caching;
// Getters and setters
}
public static class AuthConfig {
private boolean enabled;
private List<String> providers;
// Getters and setters
}
public static class CacheConfig {
private boolean enabled;
private int ttl;
// Getters and setters
}
}Variabili d'Ambiente e Esternalizzazione
Entrambi i formati supportano l'override tramite variabili d'ambiente. Spring Boot converte automaticamente tra i formati:
# Override dei valori di configurazione
export SPRING_DATASOURCE_URL=jdbc:postgresql://prod:5432/db
export SPRING_DATASOURCE_USERNAME=produser
export SERVER_PORT=9090
# Le liste possono essere separate da virgole
export APPLICATION_ALLOWED_ORIGINS=https://a.com,https://b.com# Riferimento a variabili d'ambiente in YAML
spring:
datasource:
url: ${DB_URL:jdbc:h2:mem:default}
username: ${DB_USER:sa}
password: ${DB_PASSWORD:}
application:
api-key: ${API_KEY}
secret: ${APP_SECRET:default-secret}Validazione con Bean Validation
Le proprietà di configurazione possono essere validate con Jakarta Bean Validation:
import jakarta.validation.constraints.*;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.validation.annotation.Validated;
@Validated
@ConfigurationProperties(prefix = "application.security")
public class SecurityConfig {
@NotBlank(message = "JWT secret is required")
private String jwtSecret;
@Min(value = 300, message = "Token expiration must be at least 5 minutes")
@Max(value = 86400, message = "Token expiration cannot exceed 24 hours")
private int tokenExpiration = 3600;
@NotEmpty(message = "At least one allowed origin is required")
private List<@URL String> allowedOrigins;
@Email
private String adminEmail;
// Getters and setters
}Configurazione Specifica per Profilo
Spring Boot supporta file di configurazione specifici per profilo per entrambi i formati:
src/main/resources/
├── application.yml # Configurazione comune
├── application-dev.yml # Ambiente di sviluppo
├── application-staging.yml # Ambiente di staging
├── application-prod.yml # Ambiente di produzione
└── application-test.yml # Ambiente di test# application-prod.yml
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 30000
logging:
level:
root: WARN
file:
name: /var/log/app/application.log
management:
endpoints:
web:
exposure:
include: health,info,metricsAltre domande di esercitazione su questi file si trovano nel modulo di colloquio su application.properties e YAML.
Pronto a superare i tuoi colloqui su Spring Boot?
Pratica con i nostri simulatori interattivi, flashcards e test tecnici.
Domande Frequenti nei Colloqui
Domanda 1: Quando preferire YAML rispetto a Properties?
YAML è più adatto per configurazioni complesse e gerarchiche con proprietà nidificate, liste e profili multipli. I file Properties sono preferibili per configurazioni semplici, sistemi legacy o quando i membri del team non hanno familiarità con la sintassi YAML. Un motivo concreto a favore di Properties: i file aggiuntivi importati con @PropertySource devono essere .properties. Inoltre, in YAML uno spazio fuori posto sposta silenziosamente una chiave sotto il nodo padre sbagliato.
Domanda 2: Come caricare più file di configurazione?
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.PropertySource;
@Configuration
@PropertySource({
"classpath:database.properties",
"classpath:messaging.properties"
})
public class AdditionalConfig {
}Secondo la documentazione di riferimento, i file YAML non possono essere caricati direttamente né con @PropertySource né con @TestPropertySource. Per YAML serve quindi una PropertySourceFactory personalizzata:
import org.springframework.beans.factory.config.YamlPropertiesFactoryBean;
import org.springframework.core.env.PropertiesPropertySource;
import org.springframework.core.io.support.EncodedResource;
import org.springframework.core.io.support.PropertySourceFactory;
import java.util.Properties;
public class YamlPropertySourceFactory implements PropertySourceFactory {
@Override
public org.springframework.core.env.PropertySource<?> createPropertySource(
String name, EncodedResource resource) {
YamlPropertiesFactoryBean factory = new YamlPropertiesFactoryBean();
factory.setResources(resource.getResource());
Properties properties = factory.getObject();
String sourceName = name != null ? name : resource.getResource().getFilename();
return new PropertiesPropertySource(sourceName, properties);
}
}Domanda 3: Qual è l'ordine di priorità delle sorgenti di configurazione?
Spring Boot carica le configurazioni in questo ordine (priorità più alta sovrascrive quella più bassa):
- Argomenti da linea di comando
- SPRING_APPLICATION_JSON (JSON inline)
- Parametri Servlet
- Attributi JNDI
- Java System Properties
- Variabili d'ambiente del sistema operativo
- File specifici per profilo (application-.yml)
- Configurazione applicazione (application.yml)
- Annotazioni @PropertySource
- Valori predefiniti
All'interno dei file di configurazione vale un secondo ordinamento: i file specifici per profilo sovrascrivono quelli generici, e i file esterni al JAR impacchettato sovrascrivono quelli contenuti nel JAR. Nella stessa posizione, .properties sovrascrive .yml. Un candidato in grado di spiegare perché un valore impostato in application.yml viene ignorato senza alcun avviso (un application.properties dimenticato accanto) dimostra vera esperienza di debugging.
Domanda 4: Come gestire i secrets in modo sicuro?
# Utilizzo di Spring Cloud Config Server o Vault
spring:
cloud:
vault:
uri: https://vault.example.com
token: ${VAULT_TOKEN}
kv:
enabled: true
backend: secret
config:
import:
- vault://secret/application
- vault://secret/databaseDomanda 5: Cos'è Jasypt e come cifra le proprietà di Spring Boot?
Jasypt Spring Boot decifra i valori racchiusi in ENC(...) durante la costruzione dell'Environment, così i secret cifrati possono stare in application.yml o application.properties ed essere associati come valori normali:
# application.properties
spring.datasource.password=ENC(nrmZtkF7T0kjG/VodDvBw93Ct8EgjCA+)# The master password is supplied at runtime, never committed
java -Djasypt.encryptor.password=$JASYPT_MASTER_KEY -jar app.jarjasypt.encryptor.password è l'unica proprietà obbligatoria e l'algoritmo predefinito è PBEWITHHMACSHA512ANDAES_256. Il formato non fa differenza: lo stesso valore ENC(...) funziona in YAML e in Properties.
La risposta che distingue un candidato senior: Jasypt non elimina il secret, lo sposta. Chi possiede la master password può decifrare ogni valore del repository, e ruotarla significa cifrare di nuovo tutti i valori. Vault o un secret manager cloud aggiungono controllo degli accessi, audit e rotazione, che Jasypt non offre.
Lo starter 4.0.x (4.0.4, gennaio 2026) richiede Java 17 e Spring Boot 3.5+, e il suo README non menziona Spring Boot 4. La libreria Jasypt sottostante non ha più avuto release dopo la 1.9.3 di maggio 2019. Prima di portare un progetto basato su Jasypt a Spring Boot 4, lo starter va verificato su un branch dedicato.
Domanda 6: Come funziona il Relaxed Binding?
Spring Boot supporta diverse convenzioni di scrittura per la stessa proprietà:
# Tutte queste forme sono equivalenti
application:
apiKey: value # Camel Case
api-key: value # Kebab Case (raccomandato)
api_key: value # Underscore
API_KEY: value # Uppercase (per variabili d'ambiente)Best Practice per Ambienti di Produzione
# application-prod.yml con pratiche raccomandate
spring:
datasource:
url: ${DATABASE_URL}
username: ${DATABASE_USERNAME}
password: ${DATABASE_PASSWORD}
hikari:
maximum-pool-size: ${DB_POOL_SIZE:10}
leak-detection-threshold: 60000
jpa:
open-in-view: false
properties:
hibernate:
jdbc:
batch_size: 50
order_inserts: true
order_updates: true
server:
shutdown: graceful
tomcat:
accept-count: 100
max-connections: 10000
threads:
max: 200
min-spare: 10
management:
server:
port: 8081
endpoints:
web:
exposure:
include: health,info,prometheus
endpoint:
health:
show-details: when_authorized
probes:
enabled: true
logging:
pattern:
console: "%d{ISO8601} [%thread] %-5level %logger{36} - %msg%n"
level:
root: INFO
org.springframework.web: WARN
org.hibernate.SQL: WARNFonti
- Documentazione di riferimento Spring Boot: Externalized Configuration: ordine delle sorgenti di proprietà, file properties multi-documento con
#---, precedenza di.propertiessu YAML, niente YAML in@PropertySource - Release di Spring Boot: 4.1.2 è la release GA attuale (ottobre 2026)
- README di Jasypt Spring Boot: sintassi
ENC(...), algoritmo predefinito, requisito Spring Boot 3.5+
Inizia a praticare!
Metti alla prova le tue conoscenze con i nostri simulatori di colloquio e test tecnici.
Cosa conta nella scelta tra YAML e Properties
La scelta tra YAML e Properties dipende dai requisiti specifici del progetto. YAML offre migliore leggibilità e struttura per configurazioni complesse, mentre i file Properties offrono semplicità e ampio supporto degli strumenti. Le applicazioni Spring Boot moderne tendono verso YAML grazie alla rappresentazione naturale dei dati gerarchici e alla possibilità di definire più profili in un singolo file. Anche i file Properties lo consentono, con il separatore #---. Quando entrambi i file si trovano nella stessa posizione vince .properties, e solo i file Properties possono essere caricati con @PropertySource. Indipendentemente dal formato scelto, i dati sensibili dovrebbero sempre essere forniti tramite variabili d'ambiente o servizi di configurazione esterni come HashiCorp Vault o Spring Cloud Config Server. I valori ENC(...) cifrati con Jasypt spostano soltanto il secret sulla master password.
Sapresti trovare il bug in Spring Boot?
Uno snippet reale, un bug nascosto, un tentativo al giorno. Senza account per provare.

Scritto da
Anthony Fillion-MailletFondatore di SharpSkill
Sviluppatore fullstack da oltre 10 anni. Guida SharpSkill e risponde di tutto ciò che vi viene pubblicato.
Aggiornato il 27 ottobre 2026
Tag
Condividi
Articoli correlati

Colloquio Spring Boot: Propagazione delle Transazioni
Padroneggia la propagazione delle transazioni in Spring Boot: REQUIRED, REQUIRES_NEW, NESTED e altro. 12 domande di colloquio con codice e trappole comuni.

30 Domande per Colloqui Spring Boot: Guida Completa per Sviluppatori Java
Prepara i tuoi colloqui Spring Boot con queste 30 domande essenziali su auto-configurazione, starter, Spring Data JPA, Security 7 e testing.

Colloquio Spring GraphQL: Resolver, DataLoader e Soluzioni al Problema N+1
Preparazione ai colloqui Spring GraphQL con questa guida completa. Resolver, DataLoader, gestione del problema N+1, mutation e migliori pratiche per le domande tecniche.