Dobbiamo produrre dei report in pdf da java?
Le soluzioni sono tante. Noi oggi ne tratteremo una in particolare: jasperReport!
Non è semplicissimo, ma cercheremo di seguire tutti i passi necessari per renderlo facile…
Ecco cosa faremo:
1. produzione file jrxml e compilazione del file jrxml in jasper
2. uso del file jasper in java per produrre un file PDF
Prosegui nella lettura di “JasperReport, iReport e java” »
lug 02
giu 10
Questa è una buona notizia per i programmatori java 
Da qualche tempo è nato un ambizioso progetto: jQuery4j. Il nome dice già molto da solo: jQuery4j, ossia jQuery per java.
Come si può intuire quindi, il progetto ha come scopo quello di consentire agli sviluppatori java di creare le proprie funzioni jQuery lato server, con creazione dinamica degli script lato client per l’interazione con i widgets jQuery! Non male!
Prosegui nella lettura di “jQuery4j: gestire jQuery da java” »
giu 09
Era davvero un po’ di tempo che se ne parlava ed ora sembra proprio che ci siamo! Apache Tomcat 7 è finalmente sulla buona strada: l’ultima versione del popolare contenitore di servlet è arrivato alla fase finale dello sviluppo
Ad oggi, sono state rese disponibili quattro client-release agli sviluppatori per eseguire i vari test, con la RC4 rilasciata appena la mattina dell’8 giugno.
Tomcat 7 sarà perfettamente allineato alle specifiche Servlet 3.0, offrendo una serie di vantaggi interessanti per gli utenti Tomcat, tra cui:
- Supporto alle annotation
- Configurazione dinamica delle librerie tramite codice inserito nel web.xml
- Embedding semplificato
- Miglioramento del secure session tracking
Controlla le note di rilascio di Apache Tomcat 7, oppure vai semplicemente alla pagina di download della RC4.
apr 22
Su questo argomento si trova davvero poco online… davvero poco (almeno in italiano). Effettivamente si può considerare un argomento “di nicchia”, ma come si fa a non conoscere certi argomenti e poi esigere di esser chiamati “programmatori java”?
Comunque sia, chiariamo subito una cosa che sembra essere poco chiara:
In java, il ciclo di vita di un oggetto parte dal momento della sua creazione (cioè quando si usa la parola chiave new) e finisce quando l’oggetto è eliminato dal garbage collector.
In java l’allocamento degli oggetti nella RAM avviene in uno spazio di memoria riservato che prende il nome di heap. Per quanto questo spazio possa essere grande, esso è comunque finito e può quindi saturarsi. Per questo motivo la JVM, di tanto in tanto, ripulisce la heap dagli oggetti non più necessari. A tale scopo essa usa il garbage collector (gc). Esso è autonomamente in grado di decidere quali oggetti eliminare e quali no. Ma come fa questo strumento a prendere tali decisioni? Per rispondere a questa domanda dobbiamo necessariamente addentrarci nelle attività svolte dalla JVM.
Java è un sistema thread-based multitasking. Paroloni da paura che per adesso lasciamo così come sono. Quello che ci interessa sapere è che ogni thread ha il proprio runtime stack il quale viene usato per gestire l’esecuzione dei metodi. Ogni elemento di questo stack viene chiamato activation record e corrisponde ad una chiamata di un metodo. E’ proprio analizzando il runtime stack dei vari thread attivi che il garbage collector riesce a comprendere quale oggetto lasciare vivo e quale eliminare! Se il gc trova nella heap un oggetto che non ha alcun riferimento nei vari runtime stack e non viene richiamato da altri oggetti, allora il gc procede alla eliminazione dalla RAM di quell’oggetto, liberando memoria.
apr 17
Un’anonymous class (classe anonima) è una inner class che viene contemporaneamente definita e istanziata e non ha un nome.
Un’anonymous class (classe anonima) esiste se e soltanto se esiste una super classe da estendere o un’interfaccia da implementare!
Quando estende una classe, la sintassi dichiarativa assume la seguente forma:
new <nome superclasse> (<lista opzionale di argomenti>) {…}
Quando invece implementa un’interfaccia, assume la seguente forma:
new <nome interfaccia> () {…}
Bisogna osservare che sebbene una classe anonima estenda una classe o implementi un’interfaccia, essa non usa né la clausola extends né la clausola implements.
Inoltre, come per le local classes, anche le anomymous classes non possono usare la parola chiave static in fase di dichiarazione.
[to be continued...]
apr 12
Per local class (classe locale) si intende una inner class che è definita in un blocco di codice. Un blocco di codice potrebbe essere il corpo di un metodo, di un costruttore, un blocco locale, un inizializzatore statico o un inizializzatore di istanza.
Alcune caratteristiche di una local class:
- una local class non può avere memebri statici (questo però non esclude la possibilità di avere un membro final static, essendo esso una costante)
- una local class non può avere modificatori di accessibilità (public, private, ecc.). Sarà quindi dichiarata scrivendo semplicemente class nomeClasse {…}
- una local class può estendere un’altra classe
- all’interno del blocco in cui è definita, una local class può accedere solo ai membri dichiarati final
- una non-static local class può accedere sia ai membri statici sia ai membri non statici della classe contenitore (da non confondere con il blocco contenitore)
- una static local class può accedere solo ai membri statici della classe che la contiene
- una local class (essendo locale) può essere istanziata solo nel blocco nel quale è definita e deve essere dichiarata prima di essere utilizzata
Prima accortezza: se il blocco contenente la dichiarazione della local class è definito in un contesto statico (ad esempio un metodo statico o un inizializzatore statico) allora la local class è implicitamente statica e quindi non richiede alcun oggetto contenitore per essere istanziata.
Facciamo però attenzione al fatto che, sebbene in certi contesti (appena visti) la local class è intesa implicitamente statica, essa non consente di utilizzare nella propria dichiarazione la parola chiave static. Mai.
Facciamo anche attenzione al fatto che se una local class si trova dichiarata in un contesto statico, ciò influenzerà quello che la local class può “vedere” nel contesto contenitore. Prosegui nella lettura di “Java, local classes” »
apr 04
Una non-static member class è una inner class definita senza la keyword static (vedere il punto (2) dell’esempio sotto).
Bisogna osservare che:
- Un’istanza di una non-static member class può esistere solo e soltanto insieme all’istanza della classe che la contiene
- Una non-static member class non può avere static members (a meno che non siano anche final)
- Il codice scritto in una non-static member class può avere accesso diretto a ogni membro (inclusi i nested) anche se dichiarato private
Vediamo un esempio con un po’ di casi particolari.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | public class MyLinkedList { private String message = "Shine the light"; // (1) public Node makeInstance (String info, Node next) { return new Node(info, next); } public class Node { // (2) non-static member class (NSMC) final static int maxNumOfNodes = 100; private String nodeInfo; private Node next; private String message ="Messaggio dal Nodo "; // (3) public Node(String nodeInfo, Node next) { this.nodeInfo = nodeInfo; this.next = next; } @Override public String toString(){ message = "Modifica del message di Node"; // (4) return MyLinkedList.this.message + " in " + nodeInfo + " (" + maxNumOfNodes + ")"; // (5) } } } public class ListClient { public static void main(String[] args) { MyLinkedList list = new MyLinkedList(); MyLinkedList.Node node1 = list.makeInstance("node1", null); MyLinkedList.Node node2 = list.makeInstance("node2", node1); System.out.println(node2.toString()); } } |
Osserviamo il punto (4).
Viene modificato il valore asseganto all’attributo di tipo stringa message. Ma esistono 2 attributi di tipo stringa denominati message! Li vediamo dichiarati al punto (1) e al punto (3), entrambi private. Il message al punto (1) appartiene alla classe contenitore (MyLinkedList), mentre quello dichiarato al punto (4) appartiene alla non-static inner class (Node). Abbiamo detto che in una non-static member class possiamo riferirci a qualunque membro, anche dichiarato private, anche appartenente alla classe contenitore. Ma come possiamo riferisci all’attributo message del contenitore? Lo si può fare con un uso particolare della parole chiave this. Osserviamo a tal riguardo il punto (5).
ATTENZIONE.
Se non fosse stato dichiarato l’attributo al punto (4), allora scrivendo
1 | return message + " in " + nodeInfo + " (" + maxNumOfNodes + ")"; // (5a) |
non si avrebbe alcun errore (come invece ci si potrebbe aspettare), poiché ci riferiremmo, in modo implicito, all’attributo message della classe contenitore!!!
Facciamo attenzione a questo caso particolare!
feb 02
Che confusione!
Sui tipi annidati (nested type) e la classi interne (inner classes) in giro per la rete ci sono scritte un sacco di fregnacce! Probabilmente perché la SUN, a partire dalla versione 1.4 di java, ha fatto un po’ di casini con la nomenclatura, modificando il significato di alcuni termini. Comunque sia, ora proviamo a fare chiarezza.
Per prima cosa mettiamo in chiaro un concetto: le definizioni in informatica si danno e si usano in inglese. Ci si può riferire al corrispondente termine italiano per meglio comprendere di cosa si parla, ma è l’inglese che rende univoco un concetto o una definizione.
Torniamo quindi all’Università e alle definizioni
Definizione:
Con il termine nested type (tipi annidati) si intende indicare:
- nested classes
- nested enums
- nested interfaces
Definizione:
Con il termine nested class (classe annidata) si intende una classe dichiarata all’interno di un’altra classe.
Allo stesso modo si definisono le nested enum e le nested interface.
Ci sono 4 tipi di nested classes:
- static member classes, enums e interfaces
- non-static member classes
- local classes
- anonymous classes
Definizione:
Con il termine inner class (classe interna) si indica una qualsiasi nested class purché NON di tipo 1 (vedi definizione precedente).
Facciamo un esempio commentato a dovere:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | class Alessandro { // (1) Top level class static class SMC {/*...*/} // (2) Static member class interface SMI {/*...*/} // (3) Static member interface class NSMC {/*...*/} // (4) Non-static member (inner) class void nsm() { class NSLC {/*...*/} // (5) Local (inner) class in non-static context } static void sm() { class SLC {/*...*/} // (6) Local (inner) class in static context } SMC nsf = new SMC() { // (7) Anonymous (inner) class in non-static context /*...*/ }; static SMI sf = new SMI() { // (8) Anonymous (inner) class in static context /*...*/ }; enum SME {/*...*/} // (9) Static member enum } |
dic 02
Ma abbiamo davvero capito come vengono gestiti i reference in java?
Piccolo snippet per metterci alla prova.
Ammettiamo di avere 2 classi
- ClasseA
- ClasseB
e che ClasseB sia una sottoclasse di ClasseA ossia “ClasseB extends ClasseA”.
Ora, supponendo che le classi si trovino tutte nello stesso package, scriviamo questo codice nel nostro main method:
1 2 3 4 5 6 7 8 | ClasseA a; ClasseB b; a = new ClasseA(); b = new ClasseB(); a = b; //(1) b = a; //(2) |
Problemi?
Il codice scritto funziona? Anzi, compila?
La risposta è, ovviamente, no e il problema è nell’ultima riga (2): b = a;
Perché?
Eppure sembra tutto ok!
In (1) abbiamo assegnato b ad a, quindi a = b. Come è mai possibile che scrivendo poi b = a la cosa non sia corretta?
La spiegazione è nel tipo di dichiarazione iniziale dei reference a e b.
ClasseA è una superclasse di ClasseB, quindi scrivere a = b è possibile per automatico widening (a è “più grande” di b). La cosa invece non è possibile in senso inverso perché b è “più piccolo” di a e non può quindi “contenerlo”.
L’osservazione più comune a questo punto è:
ma se in (1) abbiamo scritto a = b significa che a e b sono diventati uguali! Quindi come è mai possibile che b = a dia problemi?
Già, come è mai possibile?
Leggete il post su java i reference e la RAM e forse ne capirete di più…
nov 19
Molti le nominano, pochi le usano, meno le conoscono.
Eppure sono moderatamente utili e molto semplici da usare…
In java una
1 | assert |
è un’affermazione che il programmatore fa in un certo punto del codice da lui scritto.. Il compilatore si occupa di verificare che tale affermazione sia corretta, in caso contrario lancia un’eccezione di tipo unchecked. E’ decisamente opportuno disabilitarle in fase di produzione del sistema, mentre possono essere utili in fase di sviluppo e test.
Come si dichiarano?
In 2 modi diversi:
1 2 | assert <boolean expression>; assert <boolean expression>: <message expression>; |
Se ad esempio, in una nostra classe stiamo calcolando la velocità come spazio/tempo, potremmo scrivere:
1 2 | assert spazio > 0; assert tempo > 0: "Il tempo non è un numero positivo!" + tempo; |
Come si abilitano?
Per default le asserzioni sono disabilitate.
Bisogna quindi esplicitamente abilitarle. Ecco come fare:
1 | >java -ea <classe da eseguire></classe> |
In questo modo abilitiamo l’uso delle asserzioni nella nostra classe e in tutte le sue dipendenze, ma non nelle classi di sistema (quelle caricate direttamente dalla JVM). Per abilitare anche quelle ci tocca scrivere:
1 | >java -esa |
L’errore più clamoroso che si possa commettere nell’uso di una
1 | assert |
è quello di confonderla con la gestione delle eccezzioni!
Enrico (7)
fede (3)
Francesco (3)
nevruz (3)
Fabio (2)
Gigi (2)
Giuseppe (2)
lodos1 (2)
matteo (2)
Pao (2)
andrea (1)
Danilo (1)
