Alepuzio

DEBUG SU QUERY IN JAVA

Come qualunque sviluppatore J2EE sa esistono due modi per eseguire una query SQL in JAVA:

1. Statement: l'oggetto di questa classe ha la query definita più o meno staticamente e la si esegue con il metodo execute() senza parametri aggiuntivi.


2. PreparedStatement: se la query deve essere ripetuta più volte, eventualmente modificando i parametri, l'oggetto di questa classe deve settare i vari parametri tramite i metodi setString(x,y), setDate(x,y), setBoolean(x,y) etc in base al tipo di parametro, al posto del parametro (primo->1, secondo->2, etc) ed alla variabile che contiene il valore da inserire (indicato con y). Lo stesso effetto si può ottenere con lo Statement tramite concatenazione di stringhe ma la query risulta più lenta da eseguire (e questo non è bello in ambito web).

(So che la mia spiegazione è penosa: per una migliore vedete la documentazione della SUN nei package java.sql.* e java.sqlx.* )

Sotto l'ambiente di sviluppo Eclipse, quando debuggando dovete sapere che query state eseguendo in quel momento ed avete un PreparedStatement dovete andare nella finestra delle variabili (o nella schermata INSPECT - CTRL+I da tastiera) ed aprire i nodi seguenti dell'albero della struttura:

Formiche informatiche



Caratteristica propria dell'informatico di ogni livello è la pigrizia. Pigrizia che spazia dallo "non scrivo il manuale d'uso che tanto poi l'utente fa un po' di prove e se la sbriga lui" allo "sto digitando troppi tasti nello scrivere il codice  che in buona parte fa sempre le stesse cose: fammi pensare se posso velocizzare qualcosina".

Nel primo caso l'utente bestemmia e non usa/compra il software realizzato dal pigro informatico, nel secondo l'informatico si sbriga a fare le cosette solite evitando noia ed errori derivanti e si dedicare ad attività più produttive (come pensare al nome da dare alla nuova macchinetta del caffè delle pause).

Ricordate questo post? Il programmatore non è un novello Mago Merlino che tramite invocazioni di entità infernali incatena spiriti maligni al computer costringendoli a compiere le azioni che l'utente comunica mediante mouse e tastiera, ma segue un percorso logico e lineare per costruire il software (anche se a mio parere è meno produttivo e più ricco di incognite di un bel Sabba in una notte di luna piena con un po' di hardware in un calderone bollente: purtroppo non ho ancora i benchmark di quello che esce fuori così ma l'istinto mi suggerisce qualcosa).

Tale percorso è:

1)scrittura del codice sorgente: il programmatore scrive il programma mediante regole semantiche e sintattiche di un certo linguaggio di programmazione(C, C++, Java, PERL, et cetera et cetera);

2)compilazione: usando programmi opportuni detti compilatori (gcc, g++, javac) il codice sorgente viene trasformato in codice che può essere compresoed eseguito dalla macchina. (Per la verità esistono linguaggi che permettono di non compilare necessariamente il codice ma sono un caso più particolare degli altri);

3)esecuzione:si invoca un programma specifico per far eseguire il programma compilato nella fase (2): nel mondo Windows in genere si clicca sull'opportuna icona si scrive il nome su "Esegui applicazione" o su command line.



Quando i programmi sono piccoli il procedimento non ha grossi intoppi (a parte l'errore manuale); quando cominciano ad esserci dimensioni maggiori e quindi complessità maggiore del programma, con varie dipendenze da file di sistema ed interdipendenze, allora la cosa comincia quantomeno a farsi lunghetta.



Per i programmi scritti in C/C++ (due linguaggi che hanno fatto grande la produzione del software) si ricorre ad un programmino chiamato make. Per eseguirlo basta scrivere in un file (makefile) i nomi dei vari file con alcuni riferimenti ad altri file e lanciarlo: lui si occupa di compilare tutto correttamente (ok, sto banalizzando ma solo per scopo divulgativo).

Questa utility però ha qualche svantaggio:

1)non è stato progettato per essere cross-platform: cioè la sua esecuzione funziona su GNU/Linux non è detto che funzioni su MacOS, nè se va qui è detto che vada su Windows.

2)Ergo ogni sistema ha il suo che differisce dagli altri per pochi dettagli cui nessuno pensa finchè non ci pensa dopo ore spese a capire "perchè sto coso non va su questo coso mentre va su quell'altro coso?" non esplicando però se per coso si intenda "sistema operativo", "computer" o "servitore di Azarot Principe dell'Inferno" (la terza è impossibile perchè per ipotesi di questo discorso abbiamo scartato l'idea di chiamare altri esseri viventi all'interno del processo produttivo: da un lato ci complichiamo la vita, dall'altro non abbiamo a che fare con manodopera esterna e quindi con sindacati vari)



Insomma, con make possono esserci complicazioni inutili e dispendiose. A ragione di ciò un programmatore Java, James Duncan Davidson, ha deciso di creare un nuovo sistema di compilazione chiamato ANT ("formica" in inglese).

Quali sono i vantaggi?

1) Il file su cui scrivere le istruzioni è un file XML valido (build.xml)anzichè di testo normale. Ci sono alcuni svantaggi in generale con XML ma tra i vantaggi è multipiattaforma per cui non ci si deve preoccupare di cambi di piattaforma;

2) ANT è scritto in JAVA, per cui se uno si vuole creare le sue estensioni poi può portarle in qualunque piattaforma senza doverle ricompilare.

3) E'meno complesso scrivere un build.xml che un makefile;

4) Deo gratia, molti ambienti di sviluppo software lo integrano nativamente: nel caso iellato ci sono i plugin che permettono comunque di usarlo.

Eclipse per esempio lo supporta nativamente, NetBeans non so.



A tempo molto perso ho creato una specie di cheatsheet, cioè una guida rapida per consultazione nella creazione di un build.xml. Spero possa essere utile: scaricatelo in pdf se non usate OpenOffice o se pensate che non lo modificherete.

Lo scarico è libero, gratis e la licenza è una Creative Commons BY-SA.

Il file è nel mio MediaBlog.



Alla prossima e happy building!! ;))

Per creare un parser SAX con Java



Il parser deve estendere la classe HANDLEBASE e deve implementare esplicitamente i metodi

• startElement()


• endElement()


• character(char[] buffer,int offset, int lenght)


• startDocument()


• endDocument()

 ocio che il compilatore non da errore se la segnatura non è rispettata.

In effetti questi metodi sono già presenti in HANDLEBASE ma non hanno effetti se non vengono riscritti (overriding) nella classe figlio.

Buon divertimento