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

Con le versioni 5 e 6, Java ha introdotto diverse modifiche al linguaggio.
Oltre ai già noti (e a volte criticati) generics, boxing/outboxing, annotations, enums, static imports ora si parla di closures. In alcuni casi si tratta di zucchero sintattico o poco più, in altri casi di importanti modifiche al linguaggio, nel costante sforzo di rendere Java sempre competitivo nei confronti degli altri moderni linguaggi (C++, C#, Smalltalk, Ruby o Groovy…).

Ma ci sono anche delle “resistenze” ad accettare queste modifiche al linguaggio e spesso, come si osserva in questo post di TSS, sono proprio i “senior” a sembrare più restii ai cambiamenti. Forse per timore di perdere quel vantaggio che hanno acquisito con anni di esperienza, i senior sembrano in qualche modo spaventati dalle novità o semplificazioni recentemente introdotte nel linguaggio. Ma quel che spaventa di più forse è l’incompatibilità dei binari generati e così molti “preferiscono” ancora lo stile 1.4.

L’aspetto che mi sembra più interessante tuttavia è la possibilità di poter utilizzare altri linguaggi nella JVM come JRuby o Groovy ad esempio, il che rende meno “indispensabili” le continue estensioni del linguaggio Java vero e proprio. Non dimentichiamo infatti che Java è molto di più di un linguaggio: è una VM, un insieme di librerie ed API molto ricche, un mondo di framework open-source e molto altro…

Leggi anche l’articolo originale.

La semplicità di Ruby (e dei linguaggi di scripting in generale) o la consolidatà versatilità e robustezza di J2EE per la creazione di grosse architetture Enterprise? E un dubbio: è sempre vero che problemi complessi si possono ridurre ad una programmazione “semplice”, oppure è ancora giustificato l’elevato prezzo di una “learning curve” iniziale?
Come dire… la programmazione non è (ancora) per tutti…

Leggi anche l’articolo originale.