Le due attività non chiedono di ripetere un elenco di API. Chiedono di mostrare come si passa da un problema a una scelta verificabile e come si continua a imparare quando il libro non può più accompagnare ogni passo. È utile conservare le risposte e rileggerle dopo aver lavorato a un progetto reale: il criterio non è indovinare la risposta «giusta» del libro, ma rendere espliciti contesto, prova e limite.
C22.1 – Dalla prima diagnosi a un problema nuovo
Riprendi l'autodiagnosi fatta all'inizio del volume, oppure descrivi ora un problema che allora avresti risolto copiando un esempio. Può essere un archivio che cresce, una richiesta HTTP lenta, una prenotazione concorrente o un programma difficile da distribuire. Scrivi in prosa quale comportamento osservabile vuoi ottenere e quale guasto temi. Indica un mattone del libro che aiuta, uno che in questo caso sarebbe fuori posto e un esperimento minimo che potrebbe smentire la tua scelta. Infine cambia un vincolo, per esempio la sorgente da file a rete o l'uso da un solo thread a molti thread, e spiega che cosa devi riprogettare.
Criterio di riuscita. La risposta distingue il problema dalla prima API venuta in mente; descrive almeno un'invariante o limite misurabile, una prova positiva e una negativa, e riconosce una condizione in cui la soluzione iniziale smette di bastare. Il lettore non riceve punti per il numero di tecnologie nominate.
Indizio. Nel catalogo C29 la build risponde alla domanda «un collega può ricostruire e avviare il programma?». In C30 il parser risponde a un'altra domanda: «quali input e costi accettiamo?». Una build verde non risponde alla seconda.
Soluzione ragionata, un esempio. Voglio importare titoli da un file caricato da un utente e renderli visibili soltanto quando sono tutti validi. Il limite di ottanta unità per riga e quello di cento titoli riducono due costi; un file con milioni di righe vuote mostra che manca un limite complessivo. Provo cento titoli validi, il centunesimo e molte righe vuote; poi verifico che un fallimento non sostituisca il catalogo precedente. AtomicInteger non risolve la pubblicazione completa di più record: serve una transazione o una sostituzione di versione. Se la sorgente diventa HTTP, aggiungo timeout, massimo della risposta e gestione dell'interruzione della rete. La scelta è trasferibile perché ogni nuova misura risponde a un rischio dichiarato.
C22.2 – Leggere una novità del JDK senza confondere progetto e release
Scegli una funzionalità menzionata nelle Conclusioni, per esempio i thread virtuali, la Foreign Function and Memory API o una proposta di Valhalla. Parti dalla pagina del progetto o da una notizia, poi raggiungi il JEP e la documentazione ufficiale della release che stai usando. Registra data della consultazione, stato nella tua release, eventuali opzioni di compilazione ed esecuzione e problema che la funzionalità intende affrontare. Scrivi un esperimento di poche righe o una prova di compilazione che distingua «disponibile» da «annunciata». Concludi dicendo se la useresti nel tuo progetto e quale informazione ti manca ancora.
Criterio di riuscita. La risposta cita fonti primarie con la release esatta; distingue stabile, preview e incubator; separa una motivazione del progetto dal contratto dell'API disponibile. La decisione d'uso contiene un caso concreto e un limite, non soltanto entusiasmo o diffidenza.
Indizio. Una pagina di progetto può contenere lavori per versioni future. Un JEP può essere draft, candidate, targeted o delivered. Per il comportamento in Java 25 controlla la documentazione Java 25 e compila con quel JDK.
Soluzione ragionata, un esempio. Il JEP 444 registra i thread virtuali come consegnati in Java 21. Nel JDK 25 Thread.ofVirtual() è disponibile senza --enable-preview. Il problema affrontato è il costo di mantenere un thread di piattaforma dedicato a molte operazioni che attendono I/O; non è una promessa di accelerare un calcolo CPU-bound. Un programma minimo crea un thread virtuale, lo avvia e ne attende la fine; una prova di carico rappresentativa serve prima di sostituire l'architettura di un servizio. Per una proposta di Valhalla la risposta sarebbe diversa: verifico l'eventuale build sperimentale, ma non tratto la proposta come API stabile di Java 25.