Sviluppatori Jackson Freelance Italiani

Perché le guide che trovo online non funzionano più?

Perché quasi tutte si riferiscono alla versione 2, e nella versione 3 è cambiato l'indirizzo con cui la libreria viene dichiarata e importata.

Cosa è cambiato: sia le coordinate della dipendenza sia i nomi dei pacchetti nel codice sono passati a una nuova radice. Non è una differenza di sintassi: è un progetto diverso a tutti gli effetti dal punto di vista della compilazione.
Conseguenza pratica: copiare un frammento da un tutorial del 2023 produce un errore di compilazione, e la ricerca dell'errore porta quasi sempre fuori strada.
La serie 2 è ancora mantenuta e riceve aggiornamenti, quindi non c'è fretta di migrare — ma va saputo su quale delle due si sta lavorando.

Esiste una guida ufficiale alla migrazione, e nei progetti Spring recenti la direzione è la versione 3.

Le date e gli importi arrivano sbagliati fra due sistemi: è un problema di Jackson?

Quasi sempre è un problema di configurazione, ed è il difetto che genera più ticket nelle integrazioni fra aziende.

Date e fusi orari: se un sistema scrive l'ora locale e l'altro la interpreta come universale, le prenotazioni si spostano di un'ora. Va deciso e scritto nel contratto di interfaccia quale formato si usa.
Decimali: usare il tipo sbagliato per gli importi produce errori di arrotondamento che in fattura diventano contestazioni. Per il denaro esiste un tipo apposta, e va usato da entrambe le parti.
Campi sconosciuti: per impostazione predefinita un campo in più fa fallire la lettura. Nelle integrazioni conviene configurarla perché li ignori, altrimenti ogni aggiunta del fornitore rompe il tuo sistema.

Dobbiamo leggere un file JSON da diversi gigabyte: si può?

Sì, ma non caricandolo tutto in memoria, che è l'errore che fa fallire il primo tentativo. Jackson offre una modalità a flusso che legge il documento pezzo per pezzo.

Quando serve: esportazioni da gestionali, cataloghi prodotto, registri di sistema, risposte di API che restituiscono elenchi enormi.
Il vantaggio: il consumo di memoria resta costante indipendentemente dalla dimensione del file.
Il costo: il codice è meno immediato da scrivere, quindi si usa solo dove serve davvero.

Come gestiamo i cambiamenti di una API senza rompere i client?

È il tema che separa un'integrazione che dura da una che va rifatta a ogni rilascio. Poche regole coprono quasi tutti i casi.

Aggiungere campi è sicuro, a patto che i client siano configurati per ignorare quelli sconosciuti.
Rimuovere o rinominare campi non lo è: vanno mantenuti in parallelo per un periodo concordato, segnalati come deprecati e poi rimossi con preavviso.
Cambiare il tipo di un campo è la modifica più insidiosa, perché spesso non produce errori ma valori sbagliati.

Metti queste tre regole nel documento di interfaccia con i tuoi fornitori: vale più di qualunque scelta tecnica.

Conviene usare un'alternativa?

Esistono altre librerie, ma in ambito Java aziendale Jackson resta la scelta predefinita e quella con più integrazioni pronte. La domanda più utile riguarda semmai la versione.

Per un progetto nuovo: partire dalla serie più recente, che è la direzione dell'ecosistema Spring.
Per un progetto esistente: restare sulla serie 2, che continua a ricevere aggiornamenti, e pianificare la migrazione insieme al prossimo aggiornamento del framework, non come intervento a sé.
Da chiarire in preventivo: su quale versione si lavora. È una riga che evita sorprese quando il progetto passa ad altre mani.