Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

100 ottobre
, anno 2005

JSP (o WebWork?), riposa in pace…

Avatar

Massimiliano Bigatti

Massimiliano Bigatti è sviluppatore senior, autore tecnico e appassionato di fotografia.
Certificato, tra le altre, come SUN Certified Enterprise Architect for Java2 Enterprise
Edition Technology, lavora presso un importante business solution provider.
Nel tempo libero scrive per diverse riviste di informatica e ha scritto una decina di libri,
quasi tutti su Java, tra cui "Java e Open Source", Tecniche Nuove 2005.
Il suo sito personale è raggiungibile all‘indirizzo www.bigatti.it.

MokaByte

JSP (o WebWork?), riposa in pace…

Massimiliano Bigatti

Massimiliano Bigatti

  • Questo articolo parla di: Java, Programmazione & Linguaggi

Un recente scambio di opinioni su blog dedicati a Java hanno messo in luce alcuni aspetti negativi dell‘interazione tra specifiche JCP, comunità degli sviluppatori ed il mondo open source. Ed anche la possibile limitazione delle future evoluzioni di progetti open source.

Nel gruppo di sviluppo di OpenSymphony (http://www.opensymphony.com/) già  da qualche tempo serpeggia un po‘ di malumore. I programmatori hanno creato con fatica un completo framework per applicazioni Web, WebWork; lo stanno manutenendo, e forse vorebbero pianificarne liberamente l‘evoluzione.
Magari pensano di avere a disposizione una tecnologia degna di entrare a far parte delle specifiche Java EE. D‘altra parte, già  Struts sta collaborando strettamente con il JCP. E forse questo fatto può essere una fonte di risentimento. Ma come, si possono chiedere gli sviluppatori di OpenSymphony, perché loro si e noi no?
Già  in passato, con l‘introduzione della sintassi ${}, necessaria a EL e JSTL, gli sviluppatori di OpenSymphony hanno dovuto modificare il loro codice ed utilizzare la sintassi %{} al posto di ${} che utilizzavano in precedenza. Con relativo impatto sul progresso del progetto e la compatibilità  verso il passato per gli utenti.
Sostanzialmente le specifiche ufficiali di SUN non sembravano tenere in considerazione la presenza di un tool open source che già  utilizzava questa particolare sequenza di caratteri. Un fatto che può essere anche vissuto come “mancanza di rispetto” da parte degli sviluppatori, un mancato riconoscimento dell‘importanza che pensano di avere nella comunità  Java nel suo complesso.

L‘altra faccia del Web

Oggi, con le specifiche JSF (di cui abbiamo parlato in precedenza https://www.mokabyte.it/2005/04/faces.htm), una collisione di nomi si ripresenta, ma è più grave. La nuova sintassi #{} è già  infatti utilizzata dallo standard OGNL per rappresentare mappe in linea. E questo standard non è utilizzato solo da WebWork (http://www.opensymphony.com/webwork/), ma anche da progetti di Apache, come Tapestry (http://jakarta.apache.org/tapestry/).
Il gruppo di OpenSymphony ha dunque cercato di mediare con il gruppo di sviluppo JCP delle specifiche SUN, in modo da poter almeno disattivare il parsing di espressioni come ${} e #{}. La risposta, però, è stata un secco “no”.
Oggi Java EE 5 è in fase di rilascio per la revisione pubblica e alcuni timori di Patrick Lightbody, di OpenSymphony sono stati confermati. La nuova sintassi è stata inserita, ma pare si possano disabilitare in qualche modo, agendo su web.xml.
A questo punto il giudizio su JSP è diventato netto: come tecnologia generalista di pagine dinamiche per la piattaforma Java, JSP è finito.

Ulteriori evoluzioni?

Il dubbio è infatti quello che le possibili evoluzioni di JSP come tecnologia a se stante vengano fortemente limitate in futuro, nell‘ottica di una maggiore evoluzione di JSF.
Per fare un paragone con il passato, quando non esisteva JSP si doveva lavorare con le Servlet. Quando sono state introdotte le JSP, molto del lavoro che si faceva con le Servlet è stato passato a JSP. Con l‘introduzione di JSTL, si è cambiato decisamente approccio e molto di quello che si faceva in Java all‘interno di JSP è stato passato a JSTL. Ora la nuova frontiera è JSF, e sarà  questo il front-end degli utenti verso le tecnologie sottostanti, come JSP e Servlet.
Dal punto di vista di SUN, la maggiore integrazione tra JSP e JSF non è altro che un modo per ottenere una piattaforma più lineare. Dal punto di vista dei progetti open source, è invece una limitazione alla libertà  di azione.
In pratica, se prendi il pacchetto Java EE, devi prendere insieme Servlet, JSP, JSTL e JSF, mentre in precedenza l‘approccio era un poco più flessibile.
C‘è poi da considerare che JSF non è una tecnologia molto matura, come già  abbiamo avuto di sottolineare su queste pagine, ed una minor flessibilità  ad utilizzare strumenti diversi potrebbe diventare un problema.

Chi è il morto?

Ma la sostanza, probabilmente, è che con l‘evolversi della tecnologia Java EE gli spazi liberi che gli strumenti open source possono sfruttare diventano sempre meno. Prima si è persa la sintassi ${}, ora la #{}. Con JSF ora Struts e Tapestry hanno meno importanza. Come con JSTL si perse l‘utilità  della Apache Standard Tag Library.
Il malumore di OpenSympony è forse per l‘approccio del tipo “abbraccia ed estendi” che sta facendo SUN. Prende le idee migliori dal mondo open source e le integra come tecnologie standard. Di fatto uccidendo diversi progetti open source.
Infatti, con la disponibiltà  di Java EE 5, chi si accollerà  l‘onere di scaricare, installare e configurare tool open source come Struts o WebWork, visto che le stesse funzionalità  sono già  presenti nella piattaforma?
Forse solo gli utenti che devono supportare dei progetti legacy.
No mister Lightbody, forse il morto, se c‘è ne è uno, è WebWork, anche se posso capire che la cosa possa essere molto fastidiosa.
In realtà , probabilmente la partita è ancora aperta. Non penso che JSF oggi possa offrire quello che offre Spring o WebWork, che sono dei completi framework, e non solo una tecnologia. Ed è difficile che a breve SUN possa (e voglia) coprire in modo standard tutte le funzionalità  presenti in questi framework.

E la comunità  open source?

Ma se il problema può dirsi chiarito, ne rimane un altro, forse più sottile ed a lungo termine. Abbiamo avuto, nel corso dell‘evoluzione della piattaforma Java, una serie di epoche: quella pionieristica (JDK 1.0.2), quella del consolidamento (JDK 1.1), dell‘evoluzione (Java2 Standard Edition 1.2), quella dove ancora si credeva nelle Applet (Java2 Standard Edition 1.3). In parallelo abbiamo avuto un‘epoca di fioritura di strumenti e librerie open source. Oggi viviamo un‘epoca dove queste tecnologie, forse le migliori, o forse le più note, vengono integrate nella piattaforma. E durante questo processo, alcune devono morire. Altre devono cambiare.
È un fatto relativamente nuovo nella comunità  Java, mentre probabilmente in quella Unix/Linux si è già  avuta qualche esperienza (penso solo all‘enorme fork tra KDE e Gnome, con conseguente duplicazione di tutte le applicazioni, in nome della libertà  del software).
Come reagirà  la comunità  open source Java a questo nuovo modo di operare? Continueranno a supportare la piattaforma? Saranno disposti a cooperare con SUN anche vedendo ridurre il loro spazio di manovra?
Rimaniamo fiduciosi che questo accada, come suggerisce il progetto JSTL. È uno standard SUN, ma l‘implementazione di riferimento è un progetto open source di Apache.

Facebook
Twitter
LinkedIn
Avatar

Massimiliano Bigatti

Massimiliano Bigatti è sviluppatore senior, autore tecnico e appassionato di fotografia.
Certificato, tra le altre, come SUN Certified Enterprise Architect for Java2 Enterprise
Edition Technology, lavora presso un importante business solution provider.
Nel tempo libero scrive per diverse riviste di informatica e ha scritto una decina di libri,
quasi tutti su Java, tra cui "Java e Open Source", Tecniche Nuove 2005.
Il suo sito personale è raggiungibile all‘indirizzo www.bigatti.it.

Massimiliano Bigatti

Massimiliano Bigatti

Massimiliano Bigatti è sviluppatore senior, autore tecnico e appassionato di fotografia. Certificato, tra le altre, come SUN Certified Enterprise Architect for Java2 Enterprise Edition Technology, lavora presso un importante business solution provider. Nel tempo libero scrive per diverse riviste di informatica e ha scritto una decina di libri, quasi tutti su Java, tra cui "Java e Open Source", Tecniche Nuove 2005. Il suo sito personale è raggiungibile all‘indirizzo www.bigatti.it.
Tutti gli articoli
Nello stesso numero
Loading...

Il tunneling HTTP

Comunicare con un‘applicazione server

Soluzioni Oracle per la scalabilità e l‘affidabilità

III parte

Il networking in Java

III parte: UDP e Datagrammi

Process Oriented Development: il processo alla base dello sviluppo

I parte: un approccio diverso ai requisiti di business

Applicazioni Full-Text con Apache Lucene

Una libreria per la ricerca testuale

Java Business Integration

I parte

MJPF: micro Java Plugin Framework

Un framework per realizzare applicazioni estensibili

Java in pista!

Un sistema di telemetria per la Formula 1

Service Oriented Architecture: dalla teoria alla pratica

I parte: Introduzione

Architetture e tecniche di progettazione EJB

II parte: la comunicazione con client-session

Applicazioni Desktop

Parte I: toolbar in stile aqua

Integration Patterns

I parte

Nella stessa serie
Loading...

Digital revolution: trasformare le aziende in ecosistemi digitali

III parte: Dagli obiettivi strategici alle iniziative operative

Digital revolution: La teoria

Tema 2: Il framework OKR

Digital revolution: trasformare le aziende in ecosistemi digitali

II parte: Un workshop per definire la vision

Bitcoin, blockchain e criptovaluta

V parte: Come funziona Bitcoin. Transazioni e UTXO

Digital revolution: La teoria

Tema 1: Approccio Scrum-like alle trasformazioni organizzative

Digital revolution: trasformare le aziende in ecosistemi digitali

I parte: Primo incontro.

Bitcoin, blockchain e criptovaluta

IV parte: Come funziona Bitcoin. Chiavi, indirizzi e wallet

Che cosa significa fare una trasformazione agile?

II parte: Le buone pratiche

Bitcoin, blockchain e criptovaluta

III parte: Come funziona Bitcoin. Rete e crittografia

Che cosa significa fare una trasformazione agile?

I parte: Le indispensabili premesse

Oltre Google Maps?

Una nuova alleanza per le mappe digitali

“Babbo… Ma te che lavoro fai?”

Come spiegare a un bambino (e alla sua maestra) il mestiere dell'agile coach

Bitcoin, blockchain e criptovaluta

II parte: Perché è nato Bitcoin

Microservizi: non solo tecnologia

Quanto influiscono sul business?

LEGO® Serious Play®

Che cosa è il metodo LSP?

State of Agile 2022

Qualche considerazione sul 16° rapporto

Bitcoin, blockchain e criptovaluta

I parte: Breve storia del denaro

Stili di leadership per l’agilità

Oltre il comando e controllo

Effetto Forrester e dinamiche dei sistemi di produzione

La storiella di una birra per comprendere il Lean

Fare “il tagliando” a Scrum

A due anni dalla pubblicazione della nuova guida

Veicoli elettrici ed esperienza utente

II parte: Riflessioni su app e UX

OKR, cadenze in Kanban e Flight Levels

Uscire dalla trappola dell’agilità locale

Continuous Delivery per il proprio team di sviluppo

Principi e pratiche

Il contratto è agile!

Gli elementi del contratto e l'Agilità

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte