Post

Validazione di password con Regular Expression

DOMANDA: Come posso convalidare una password di almeno 8 caratteri che deve contenere almeno un carattere e almeno un numero? RISPOSTA: La soluzione più laboriosa consiste nell'effettuare la ricerca all'interno della stringa con i metodi classici di java (operazioni su stringhe). Vorrei però proporvi un metodo alternativo più elegante e compatto utilizzando le Regular Expression : Questo codice verifica se la password inserita è lunga almeno 8 e massimo 20 caratteri e contiene almeno una lettera e almeno un numero: package regex;      public class RegexTest { public static void main(String args[]){ Pattern pattern = Pattern.compile( "((?=.*[0-9])(?=.*[a-zA-Z]).{8,20})" ); Matcher matcher = pattern.matcher( "password1" ); System.out.println(matcher.matches()); } } oppure, semplicemente: package regex;      public class RegexTest { public static void main(String args[]

Creare un eseguibile Java

Immagine
DOMANDA: Come posso creare in Java un eseguibile equivalente al .exe tipico di Windows? RISPOSTA: Anche in Java è possibile creare un file eseguibile che può essere avviato al doppio click. Procedura semplice utilizzando l'IDE Eclipse: Fate click destro sul vostro progetto e selezionate "Export": Dalla finestra selezionate Runnable JAR file (all'interno della cartella Java): Una volta premuto Next vi si aprirà quest'altra finestra: Qui selezionerete il Launch Configuration (la vostra configurazione di run, ovvero quale classe Main avvierà il vostro programma), l'Export Destination (il path dove salvare il jar eseguibile) e come gestire le librerie necessarie (in genere l'opzione "Package required libraries into generated JAR" va benissimo). A questo punto non resta che cliccare FINISH e provare, con un bel doppio click sul JAR appena creato, se abbiamo raggiunto il nost

Eccezioni checked ed unchecked

DOMANDA: Perché alcune eccezioni mi generano errore durante la compilazione ed altre no? RISPOSTA: In Java esistono due tipi di eccezioni: le unchecked  come nel caso delle RuntimeException e quelle checked (ad esempio le Exception ). La regola che differenzia i due tipi di eccezione è la seguente: le eccezioni unchecked non obbligano il programmatore a gestirle, quelle checked invece si. Facciamo un esempio chiarificatore. Eccezione UNCHECKED : package eccezioni;      public class Eccezione1 extends RuntimeException{ public Eccezione1(String msg){ super (msg); } } Eccezione CHECKED : package eccezioni;   public class Eccezione2 extends Exception{ public Eccezione2(String msg){ super (msg); }   } Classe che lancia i due tipi di eccezioni: package eccezioni ;   public class LanciaEccezioni { public void lancioEccezione1(){ throw new Eccezione1("ECCEZIONE 1"); } public void lanc

Problemi di casting

DOMANDA: Perché se effettuo una divisione tra due interi in una variabile double ottengo in output un numero senza cifre decimali? double risultato = 10 / 3; OUTPUT: 3,0 RISPOSTA: Come si può intuire, in Java, a causa della regola sulle precedenze degli operatori, il cast automatico avviene dopo la  divisione tra i due numeri interi 10 e 3. Il risultato 3 viene quindi convertito in double e diventa 3,0. L'operazione sopra, infatti equivale a: double risultato = (double) (10 / 3); OUTPUT: 3,0 Per ottenere la precisione prevista (senza perdita di informazione) basta fare il cast di almeno uno dei due interi a double: double risultato = (double) 10 / 3; oppure: double risultato = 10 / (double) 3; entrambe le operazioni danno il risultato sperato: OUTPUT: 3,3333333333333335 Ovviamente lo stesso risultato poteva essere raggiunto attraverso l'utilizzo dei letterali: double risultato = 10D / 3;

Hibernate: differenza session.get() e session.load()

DOMANDA: Qual è la differenza in Hibernate tra l'utilizzo di session.get(...) e session.load(...)? RISPOSTA: In Hibernate ci sono due metodi per recuperare gli oggetti: GET: Utente utente = ( Utente ) session . get ( Utente . class , idUtente ); Il metodo get() carica l'oggetto accedendo al database (se non è già presente un'istanza nella cache con lo stesso id) per valorizzarne gli attributi. Qualora non ci fosse nessuna corrispondenza, il metodo restituisce null. LOAD: Utente utente = ( Utente ) session . load ( Utente . class , idUtente ); Il metodo load() restituisce invece un'istanza del proxy di riferimento all'oggetto in questione (nel nostro caso Utente) senza accedere al database (viene valorizzato solo il campo id quindi). Solo quando si accede all'oggetto con i suoi metodi viene eseguito l'accesso al database (se non è già presente l'oggetto in cache). Questo metodo si comporta, nella pratica, co

Enigmi Java: (0.1 * 10) == 1 è false?

DOMANDA: Perché se sommo dieci volte la variabile double x = 0.1 il controllo  x == 1 mi da false? package  conversione;         public   class  DieciVolte  {                                       public   static  void  main(String[] args) {                double x = 0;                            for ( int i=0; i<10; i++)                  x += 0.1;               if (x == 1)                  System.out.println( "SI, il valore di x è: " + x);               else                   System.out.println( "NO, il valore di x è: " + x);            }         } RISPOSTA: La soluzione a questo enigma non dipende da Java, né dal linguaggio di programmazione.  L' inganno sta nella conversione del numero 0,1 (in base 10) all'equivalente in binario (ovvero in base 2) che risulta essere un numero periodico leggermente inferiore a 0,1  (0,000110000110000110...) .     Questo comporta che sommare 10 v

Controlli di sicurezza JSP e Servlet

DOMANDA: Perché non basta fare i controlli di sicurezza in una pagina JSP che rimanda ad una Servlet? RISPOSTA: La servlet è esposta (tramite configurazione del file web.xml ) allo stesso modo di una JSP, quindi è pubblica. Chiunque la può richiamare via GET , POST o per qualunque metodo previsto dalla servlet stessa e quindi si potrebbe avere una risposta bypassando la JSP e quindi i controlli in essa contenuti. Quindi è corretto (e fondamentale) mettere in sicurezza anche l’accesso alla servlet. La regola che vige per il web è che qualunque input o output che  proviene o può provenire da un utente (quindi da una fonte non sicura) deve essere controllata/filtrata.