2009-11-10 10 views
5

Siamo al limite di ottenere Java EE6 (con Glassfish v3 come implementazione di riferimento). Il rilascio pianificato è il 9 dicembre. Mentre ancora un buon numero di aziende stanno faticando a spostare il codice base in EE5 (dalle versioni precedenti), siamo nella situazione di lusso per iniziare lo sviluppo di un nuovo prodotto e potremmo scegliere di farlo con EE6 come piattaforma . Ciò potenzialmente evita lo sforzo migratorio in una fase successiva e beneficia di tutte le funzionalità previste in EE6.Java EE6 su EE5?

Contra o alcuni dei problemi (quando fare le cose al bordo sanguinamento, alias utilizzando EE6):

    non
  • molta esperienza in giro ancora (blog, libri, forum, da soli, ..)
  • non ci sarà nessun altro application server EE6 presto (beta forse all'inizio/metà dell'anno prossimo?)
  • Le librerie/framework di terze parti potrebbero non essere ancora verificate o testate contro EE6.

Una domanda generica che non darebbe una risposta specifica, ma forse la tua opinione sull'argomento?

Sven

+2

importarlo o migliorarlo? :-) –

+2

s/import/improve/g – flybywire

+1

a volte la varietà di risposte (come in questo caso) è LA risposta. – javadude

risposta

3

Se si è in una situazione di lusso per avviare un progetto con EE6, quindi suggerirei di pioniere.

Non solo l'esperienza complessiva sarà importante in breve tempo (diciamo che EE6 sarà maturo e ampiamente utilizzato in meno di due anni, immagina un gruppo di esperti Java EE6 quando tutte le aziende passeranno), ma EE6 è solo semplicemente più semplice di EE5, quindi se hai membri del team che hanno solo una piccola esperienza in Java EE, probabilmente farai il tuo lavoro più velocemente.

C'è già un libro su Java EE6 con Glassfish v3, e le nozioni di base non è che diversa dalla versione precedente (es. Se si tiene fede a ciò che si sa da EE5, andrà tutto bene per un lungo periodo). Glassfish v3 va bene se hai bisogno del RI per Java EE6.

Che tipo di librerie di terze parti avete bisogno?

+0

Stiamo usando ZK (http://zkoss.org/) come framework web/ajax, Shiro (http://cwiki.apache.org/confluence/display/SHIRO/Index) come framework di sicurezza, SLF4J (http://www.slf4j.org/) più logback per la registrazione, EJB3Unit per i test e Oval per la libreria di convalida. Tutto funziona bene nelle precedenti versioni basate su EE5, anche se non abbiamo ancora testato tutto per EE6. – javadude

+0

ZK dovrebbe funzionare in gran parte sul lato client e se si utilizza il componente di ricerca bean di sessione, deve restituire oggetti validi (i bean di sessione sono solo bean di sessione). SLF4J e logback dovrebbero funzionare anche, hanno poco a che fare con cose EE. Ovale anche bene. Non sono sicuro di Shiro, ma sembra che non abbia bisogno di molto dai componenti EJB. Non ho ancora controllato EJB3Unit per EE6. –

+0

EJB3UNIT si rivolge a EJB3. Non funzionerà con un semplice codice 3.1. Abbiamo provato, richiede es. un'interfaccia locale La libreria potrebbe non essere più richiesta (nel contesto EE6) perché è possibile utilizzare glassfish incorporabile per i test di junit. (http://java.dzone.com/articles/ejb-31-%E2%80%93-ejb-new-and-improved-?page=1) – javadude

0

Prima si è fatto Java EE 7 sarà comunque. Vai a farlo e impara nel processo.

+1

Sei sicuro? JEE6 è ancora nello stato di 'anteprima' e rilascerà JEE7 prima del 9 dicembre (è la data in cui ho catturato la domanda devdude;))? –

+1

Prima che venga effettuato _YOU_ ... –

+0

Indovina che hai combinato Java EE6 e JDK/JRE 7? – javadude

3

Quanto è grande e importante il progetto? Avete delle scadenze? Sono molto desideroso di nuove tecnologie o framework, ma suggerisco piuttosto di iniziare con Java EE 5 e migrare gradualmente a Java EE 6. Java EE è un grande stack di tecnologie e in fase di rilascio alcune di esse non avranno abbastanza supporto da parte di terzi venditori di feste. Quindi il mio consiglio è: utilizzare queste parti di Java EE 6 che sono mature in questo momento e che hanno un forte supporto da parte di altri fornitori.

+0

Certo, è possibile iniziare a distribuire l'applicazione EE5 su GF V3, ma non sottovaluterei lo sforzo di migrare un codebase su EE6 completo. Sì, certamente più facile da spostare da EE5 a EE6 che da versioni precedenti ("dall'era senza annotazioni"). Quale capo approva tempo e denaro per migrare in seguito senza vantaggi "visibili"? Un esempio: la convenzione di denominazione JNDI è stata modificata (http://blogs.sun.com/kensaks/entry/portable_global_jndi_names) – javadude

+0

@devdude. Molti strumenti e librerie ofrano oggi molti miglioramenti a JEE5 che faranno parte di JEE6 (ad es. Miglioramenti di Seam JSF 2.0, Weld (implementazione JSR-299) - così oggi puoi usare mamy di JEE6 fetures e ulteriore migrazione ad altre parti di JEE6 lo stack sarà meno doloroso. – cetnar