Jso

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…

Leggi anche l’articolo originale.

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…

Leggi anche l’articolo originale.

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 🙂

Leggi anche gli articoli originali: 1, 2 e 3

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…

Leggi anche l’articolo originale.

Una lunga discussione sull’ennessimo web framework, Apache Wicket che viene qui paragonato al “fratello” Apache Tapestry, con divagazioni su JSF, GWT e sull’onnipresente Struts ovviamente. Tra i suoi punti di forza e innovazioni rispetto agli altri web framework vi sono:

• Un eccellente supporto built-in ad AJAX;
• La capacità di modificare la struttura delle pagine programmaticamente;
• Perfetta separazione tra codice e templates (i templates non possono contenere codice);
• Un approccio object-oriented
• Facile apprendimento (per developers Java-oriented)

Naturalmente ci sono pro e contro, come in ogni cosa. Ma la principale ragione dell’esistenza di Wicket è che non esistono altri web framework programmabili in puro codice Java (quasi tutti seguono piuttosto il classico modello dichiarativo, con file di configurazione XML ad esempio). Naturalmente poi è anche questione di gusti, ma gli impatti più evidenti si hanno nell’ottimizzazione e nella versatilità del codice. In ogni caso anche Wicket, come pure Tapestry, Freemarker, JSF (con Facelets) e gli altri framework component-oriented rappresenta una valida alternativa ai precedenti framework Model 2 tipo Struts, tanto per citarne uno famoso 🙂

Leggi anche gli articoli originali: 1, 2 e 3

Alcune interessanti riflessioni sulla tematica dell’open-source: quando un progetto realizzato nel tempo libero può diventare un progetto open-source da proporre alla comunità degli sviluppatori?

Geertjan Wielenga, sviluppatore del NetBeans Team, racconta la sua esperienza spiegando i passi che hanno portato il suo JFugue Music NotePad (un editor musicale scritto utilizzando la NetBeans Platform e JFugue API, una potente API per la gestione dei file midi) a diventare un progetto open-source.

In sintesi, secondo la sua opinione occorre:

• disporre di un progetto che abbia raggiungo almeno un certo livello di coerenza (ovvero che possa attrarre l’interesse di altri sviluppatori)
• rilasciare un prototipo, anche non completo, alla comunità
• attendere che qualcuno si interessi al progetto (nel frattempo lo sviluppo da parte dell’autore non si arresta)
• se qualcuno si interessa al progetto ed ha una conoscenza specifica del dominio maggiore di quella dell’autore diviene “contributor”
• altri utenti sono semplici utilizzatori, “observers”
• negli anni il progetto può evolvere raggiungendo buoni livelli, addirittura oltre le aspettative dell’autore stesso!

Leggi anche l’articolo originale.