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.

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