Posts | Java

14/04/13

Everything about Java 8

Una carrellata di tutte le novità attese in Java 8. E sono davvero tante!

  • Miglioramento nelle interacce
  • Interfacce funzionali
  • Espressioni Lambda
  • Miglioramento nei tipi generici
  • Aggiunte alla Collections API
  • Aggiunte alla Concurrency API
  • Aggiunte alle IO/NIO API
  • Cambiamenti a Reflection ed Annotation
  • Nashorn JavaScript Engine
  • Miglioramenti delle performance

Per approfondimenti:

02/03/12

Tuning GlassFish for Performance

jvm-tuning-view

Ecco un articolo piuttosto tecnico, ma molto ben fatto e dettagliato sulla taratura delle performance per  l’Application Server di riferimento nel mondo Java, Glassfish.

L’articolo inizia con alcune best practise comuni del mondo JavaEE (multi thread model, gestione delle sessioni HTTP,  caching dei beans, gestione dei pool e delle transazioni) per poi divenire più specifico. In particolare vengono trattati diffusamente:

  • Ottimizzazione del Server
    • Deployment
    • Logging
    • Web Container
    • EJB Container
    • Network Listener
    • Thread Pool
    • Resources
  • Ottimizzazione della JVM
  • Ottimizzazione del Sistema Operativo
    • Parametri di rete
    • Numero massimo di files aperti
    • TCP/IP
    • Gestione del timing (orologio di sistema)
    • Network Interface Card (NIC)
  • Test di un caso pratico (con grafici)

Di seguito l’articolo completo:

28/12/11

Java 7 What`s New & Performance

Finalmente Java 7! Ci siamo quasi…

Certo i rilasci delle Java VM non sono così frequenti; specie dopo l’acquisizione da parte di Oracle, in effetti, un po’ di apprensione per l’uscita della versione 1.7 c’era…

Ma ora ci siamo quasi e le novità introdotte nella JVM non sono di così poco conto:

  • Modularizzazione
  • Supporto per linguaggi dinamici
  • Nuove API per l’I/O e per il file system
  • Supporto nativo per l’XML (probabile)
  • Safe rethrow delle eccezioni
  • Null dereference expressions, in stile Groovy
  • Better type inference, per l’instanziazione dei generics
  • Multi-catch, clausole multiple nella gestione delle eccezioni
  • Class loader ulteriormente migliorato
  • Migliorata la pipeline per i componenti Java 2D
  • Miglioramenti a Swing
  • JavaFX

ed altri ancora…

E’ interessante inoltre notare come il processo di incremento delle performance, già iniziato con Java 1.6, non si si a fermato, anzi! I test effettuati evidenziano un aumento percentuale anche più rilevante rispetto al precedente passaggio di versione. Che dire? Oracle sembra aver fatto un buon lavoro, forse anche superiore alle attese…

12/04/10

Very bad news for Java…


Nulla da fare, purtroppo sembra veramente che l’acquisizione di Sun da parte di Oracle, come purtroppo si temeva all’inizio, stia portanto alla fuga di moltissime teste illustri.

Proprio in questi giorno sono state annunciate le dimissioni niente meno che di James Gosling, il padre di Java. E non è il solo purtroppo…

Dovremo aspettarci presto qualcosa di nuovo da open jdk?

07/07/09

An ordered properties file

Mi è capitato di dover salvare un file di properties “ordinato” ovvero nel quale le chiavi fossero ordinate rispetto ad un certo criterio. Poichè la classe java.util.Properties estende java.util.Hashtable<Object, Object> normalmente le properties sono memorizzate senza alcun ordinamento specifico.
In qualche caso invece, se il file ottenuto è di grandi dimensioni, può essere utile disporre di un qualche tipo di ordinamento. La soluzione è abbastanza “tricky”, pertanto la pubblico.
La seguente classe rappresenta la chiave:

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
/**
 * A key in the form Sn, where n is an integer number.
 *
 */
public class MessageKey implements Comparable {
 
    private Integer key;
 
    public MessageKey(final String pKey) {
        final String vKey = pKey.substring(1);
        try {
            key = Integer.valueOf(vKey);
        } catch (NumberFormatException vExc) {
            Logger.error(vExc);
        }
    }
 
    public Integer getId() {
        return key;
    }
 
    public int compareTo(final MessageKey pKey) {
        return key.compareTo(pKey.getId());
    }
 
    @Override
    public String toString() {
        return "S" + key;
    }
 
}

A questo punto occorre creare il nuovo oggetto Properties, facendo l’override del metodo keys() per ottenere, all’atto del salvataggio, il file ordinato. Il tutto senza ridefinire classi di sistema. Sono necessari alcuni passaggi per costruire una Enumeration ordinata (utilizzata nell’implementazione base della classe Properties), transitanto attraverso un Vector ed una List, riordinabile con il metodo standard Collections.sort(…). La soluzione risulta compatibile con Java5 e Java6.

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
final Properties vProps = new Properties() {
    private static final long serialVersionUID = 1127046528812232390L;
 
    @Override
    public Enumeration<Object> keys() {
	// this is for key reordering...
	final Vector<MessageKey> vKeysEnum = new Vector<MessageKey>();
	for (Enumeration<Object> vEn = super.keys(); vEn.hasMoreElements();) {
	    vKeysEnum.add(new MessageKey((String) vEn.nextElement()));
	}
	final List<MessageKey> vKeysList = Collections.list(vKeysEnum.elements());
	Collections.sort(vKeysList);
 
	final Vector<Object> vOrderedKeys = new Vector<Object>();
	for (final MessageKey vKey : vKeysList) {
	    vOrderedKeys.add(vKey.toString());
	}
	return vOrderedKeys.elements();
    }
 
};
//...
vProps.setProperty("S" + vMsgKey.getId(), "something");
//...
vProps.store(...);
14/06/08

CMS war… finding the right one

Il problema di trovare un buon cms open-source mi ha sempre affascinato. La gestione dei contenuti (e dei documenti) ad oggi è un problema tutt’altro che nuovo. In rete si trovano davvero centinaia, se non migliaia di alternative sviluppate sulla piattafoma LAMP, piuttosto che in Python, Java o .NET e c’è anche un sito che si è preso la briga di catalogarle e confrontarle (quasi) tutte. Ma in tutta questa varietà come si fa ad orientarsi? E perchè tante alternative? E come mai la scelta vincente è spesso il php, tantochè addirittura molti portali che trattano di Java si basano proprio su cms php?

Le alternative sono molteplici ma tra tutte sembrano proprio Mambo, Joomla e Drupal a suscitare il maggiore interesse nella comunity. Perchè sono in effetti davvero facili da usare, user-friendly e potenti al tempo stesso. Richiedono una semplice installazione, c’è una ricchissima dotazione di plugin e il costo di hosting e gestione in molti casi è davvero ridicolo.

Più complesse le soluzioni Java (Alfresco, Magnolia per citarne alcune) che richiedono risorse e tempi di startup più consistenti. Inoltre questi cms sono più orientati alla gestione documentale piuttosto che alla gestione/publicazione dei contenuti sul web. Anche Plone (basato su Python/Zope) richiede competenze maggiori ed è giustificato generalmente in contesti Enterprise.

Alcune alternative che ho trovato interessanti perchè ben si avvicinano ai cms php ma offrono alcune caratteristiche enterprise proprie di Java (supporto multi-db, clustering, versioning, chiara separazione e riuso dei contenuti rispetto alla presentation logic, livelli di autorizzazione sul singolo componente, esportazione dei contenuti in formato xml…) sono dotCMS e OpenCms. Tra l’altro dotCMS è costruito su LifeRay probabilmente il più promettente e potente portlet container sviluppato in Java, che come Riot offre una sorta di framework (c’è da stupirsi?) per lo sviluppo di portali Java. Molti interessanti, se non altro perchè utilizzano al loro interno il meglio della tecnologia Java attualmente disponibile 🙂

22/05/08

Making Java Easier

Ancora una volta si parla della “complessità” di Java, di quella learning curve iniziale che è richiesta a chi si accosta per la prima volta alla tecnologia. E che in genere spaventa, alimentando il mito secondo il quale Java è “difficile”. Non tanto per il linguaggio in sè o per le API (che in alcuni casi risultano a dire il vero un po’ ostiche, si pensi al Calendar o a java.awt.* per fare esempi noti) ma quanto piuttosto per tutto ciò che a Java sta attorno (frameworks, application server, J2EE e via dicendo).

La precisazione è ancora una volta il “target”: Java è pensato per grandi progetti enterprise, portabili, robusti e scalabili. Che non è certo il target di PHP, Ruby o ASP di cui (a volte) si “invidia” la semplicità. Nel dettaglio alcuni punti e alcune risposte:

  • Sistema di deployment: la struttura di JAR/WAR/EAR non è particolarmente immediata, e per piccoli progetti manca la comodità di deployare la singola classe, servlet o JSP (vero in parte). Questa struttura a mio avviso continua a rimanere molto buona per i progetti enterprise
  • Ricaricamento dinamico delle classi: questo sarebbe molto utile, senza il bisogno di effettuare ogni volta il deploy completo dell’applicazione che può richiedere anche molto tempo. Qui una risposta (almeno parziale) al problema c’è già: JavaRebel
  • Una GUI console: non ne esiste una comune ai vari Application Server che consenta di configurare tutto ciò che serve, DataSources, EJB, JNDI, parametri della JRE… data la varietà manca un approccio univoco, però ci sono varie alternative. Ad esempio l’ottimo LambdaProbe per Tomcat (che sostituisce la console nativa, piuttosto scarna invece)
  • Una GUI visuale integrata con le IDE: è sempre stato un punto dolente di Java, ora con Netbeans/Glassfish, Sun ha fatto sicuramente un buon lavoro. Il deploy su altri application server invece risulta ancora abbastanza difficoltoso. E’ inoltre in corso un porting su Eclipse.

Altre risposte a questi quesiti? ProjectZero, Groovy/Grails, Ruby/Scala, OSGi su Glashfish v3…

29/04/08

Open EJB 3.0

Da poco è stata rilasciata da parte di Apache SF un’implementazione leggera delle specifiche EJB 3.0: ciò significa che può essere utilizzata, ad esempio, all’interno di Tomcat, JUnit, TestNG, Eclipse, IntelliJ, Maven, Ant, ogni altra IDE o applicazione Java.

Con l’avvento di Open EJB e Open JPA potremmo finalmente dire addio ai vecchi e pesanti application server in virtù della costante crescita di quelli più “lightweighted” e open source? Magari ancora no, ma è sicuramente un ottimo inizio…

18/04/08

Java, LAMP, .NET…

Allo stato attuale chi vince la “battaglia del web”? E chi ha più chanches per il futuro?
A mio modo di vedere (e in questo condivido gli articoli) bisogna fare distinzione in base al “target”: un conto è il sito web per uso personale, un conto è il blog per il social networking, un conto è il portale basato su CMS, diversa ancora è l’applicazione Enterprise (CRM, ERP, reporting, document management…) che utilizza il web solo come strato di presentation. I contendenti? Java, LAMP, .NET, RoR, Grails e la lista potrebbe proseguire…

Alcuni aspetti secondo me sono essenziali:

  • LAMP e RoR hanno dalla loro parte la facilità d’uso e l’immediatezza; PHP ad esempio é una soluzione C-based. L’approccio è quello di un processo per ogni richiesta differente. Ciò porta a notevole efficienza nelle performances. La facilità nel linguaggio deriva dal fatto che sono orientati allo “scripting” (ma supportano il paradigma OO)
  • Java si basa sul concetto di Virtual Machine (thread piuttosto che processi), non nasce per il web ma aggiunge il supporto web tramite il J2EE e numerosi frameworks: JSF, Struts, Spring MVC… la scelta è vasta è richiede un lungo tempo di apprendimento. I benefici si vedono nelle applicazioni di grandi dimensioni, nella sicurezza, nella portabilità, nell’interoperabilità, nel design…
  • .NET rappresenta una scelta più “organizzata” in quanto alla base vi è un unico produttore. L’approccio della VM nasce con Java nel 1996, .NET lo fa suo in tempi più recenti e sviluppa un buon framework con numerosi componenti (in Java invece le scelte sono molteplici e possono essere anche disorientanti!) che in alcuni casi nascono evidentemente dall’esperienza Java (NHibernate, log4net…)

Alla luce di queste considerazioni non deve stupire più di tanto che quindi molti siti (portali) che promuovano prodotti Java come TheServerSide, JavaLobby o Spring siano sviluppati usando Drupal ovvero un CMS PHP! Oppure che il portale TheServerSide.NET (versione di TheServerSide per il mondo .NET) non sia scritto in .NET 🙂
Per approfondire:

07/02/08

Web Application: To couple or Not to couple?

Ancora a proposito di web framework… discorso inflazionato è vero ma a quanto pare tutt’altro che concluso! Il topic in questo caso è se in una web application sia meglio codificare tutto in una action oppure separare nettamente la web logic dalla business logic. La risposta parrebbe ovvia, ma non tutti sono dello stesso avviso.
Si possono catalogare fondamentalmente 4 approcci:

  1. Due classi: 1 action basata (*) sul framework e 1 business logic non basata sul framework
  2. Due classi: 1 action non basata sul framework e 1 business logic non basata sul framework
  3. Una classe: action e business logic nella stessa classe basata sul framework
  4. Una classe: action e business logic nella stessa classe non basata sul framework
    (*) si legga “che estende classi del framework”

Tra tutte l’approccio preferito è sicuramente il numero 1, la 2 rappresenta il totale disaccoppiamento (ad esempio in Struts 2 / Webwork le azioni possono essere POJO e quindi totalmente disaccoppiate dal framework), mentre 3 e 4 sono generalmente considerate bad practise. Esistono sicuramente buone ragioni per disaccoppiare la business logic dalla action:

  • Testability: se disaccopiata la business logic può essere testata in maniera indipendente (es. JUnit)
  • Web services: la business logic può essere utilizzata in un web-service o in servizi remoti
  • Caching: riferito alle business facades

Mentawai (un framework ad approccio programmatico con supporto per l’injection di cui esiste anche una versione Ruby) sembra offrire la libertà sufficiente per implementare tutti gli approcci (1,2,3,4). A voi la scelta…