Problema con variabile volatile

[linux_r]

Database.getInstance().updateField(10, 1, Integer.toString(cliente.getId_cliente()), (String) userOperatore, GestoreDatabase.Tabella.CLIENTE);
Non è un buon modo di fare un update di uno o più campi. Tra l'altro "sembra" un metodo molto generico/arbitrario e quindi poco comprensibile. Cosa sono ad esempio 10 e 1 ? Solo tu lo sai ....

Per quanto riguarda la classe database al suo interno i metodi sono commentati e hanno la javadoc, comunque si è un metodo generico e a dire il vero non ci vedo nulla di male null'utilizzarlo.

- guardando le invocazioni sulla istanza di Database, sembrano un po' una accozzaglia di operazioni ben diverse. Evita di fare una classe "Database" che fa di tutto e di più. Avresti potuto/dovuto applicare almeno il pattern DAO, per risolvere anche quanto detto al punto precedente.

grazie per questo consiglio , purtroppo è un corso introduttivo a java e non sapevo nemmeno l'esistenza di questo pattern, non è tra gli argomenti del corso , almeno adesso so che esiste

- il codice non è completo ma dai metodi si deduce che SWListaOperatori è uno SwingWorker. SWListaOperatori contiene una inner-class SWInviaAppuntamento che è di nuovo uno SwingWorker (di per sé tecnicamente nulla di sbagliato ma è perlomeno strano/inusuale). Nel doInBackground di SWInviaAppuntamento c'è una anonymous inner class per un Runnable. Nel suo run() ad un certo punto c'è una ulteriore anonymous inner-class per un WindowAdapter. Quando si arriva ad un tale livello di annidamento con pure tutti i vari blocchi if/try in mezzo, dovrebbe suonarti un campanello di allarme .... un grosso campanello ..

Non mi pare di aver letto da nessuna parte che non si possano annidare classi oltre un certo livello, e' una regola?

sempre in questo doInBackground il close non viene fatto sempre. Se next() o getObject() lanciano SQLException, tu non chiudi nulla. Manca di correttezza nella gestione delle eccezioni.
E anche se facessi tutto corretto con le eccezioni, tutta la logica di query ed estrazione dal result-set andrebbe fatta in una classe separata.

mmmm su questo sono d'accordo con te dovrei farlo stesso nella classe database o creare una classe a parte?

- nel primo doInBackground non si capisce assolutamente che cosa si ottiene. Cosa conterrà quel ArrayList<Object>? Che colonna (e di che tipo) prendi con getObject(1) ? Solo tu lo sai ....
Manca di chiarezza.

Anche in questo caso il metodo è commentato e spiega cosa contiene quell'array di ritorno

Comunque le critiche purchè costruttive sono sempre accettatissime