Cos'è veramente Java EE? [chiuso]

Java EE ha questo "velo misterioso" intorno ad esso per i giovani sviluppatori Java - uno che ho cercato di sollevare da solo per un bel po 'di tempo con scarso successo.

La confusione nasce da:

• Java EE sembra essere sia una libreria che una piattaforma: ci sono diversi modi per "ottenere" la libreria Java EE, in genere da qualcosa come il download di Java EE SDK di Oracle. Tuttavia, la libreria Java EE non funzionerà e non verrà compilata a meno che il codice non venga eseguito o abbia accesso a un server delle applicazioni Java EE (come JBoss, GlassFish, Tomcat, ecc.). Perché? Le librerie non possono funzionare al di fuori dell'ambiente del server delle applicazioni? Perché ho bisogno di qualcosa di enorme come JBoss solo per compilare un semplice codice per inviare un'e-mail?

• Perché le librerie Java EE non sono "standard" e sono incluse nel normale download di JVM e / o nell'SDK?

• Perché ci sono così tante offerte Java EE quando esistono solo due versioni principali di Java standard (Oracle JVM / SDK | OpenJDK JVM / JDK)?

• Cosa si può fare con Java EE che non possono fare con Java standard?

• Cosa si può fare con Java standard che non possono fare con Java EE?

• Quando uno sviluppatore decide di "aver bisogno" di Java EE?

• Quando uno sviluppatore decide di non aver bisogno di Java EE?

• Perché la versione della libreria Java EE non è sincronizzata con le versioni della libreria Java standard (Java EE 6 e Java 7)?

Grazie per avermi aiutato a cancellare il flog!

Perché le librerie non possono funzionare al di fuori dell'ambiente del server delle applicazioni?

In realtà possono. La maggior parte delle librerie può essere utilizzata direttamente in modalità standalone (in Java SE) o inclusa in un file .war (praticamente è quasi sempre Tomcat). Alcune parti di Java EE, come JPA, hanno sezioni esplicite nelle rispettive specifiche che indicano come dovrebbero funzionare ed essere utilizzate in Java SE.

Semmai, non è tanto un ambiente di application server in sé che è in gioco qui, ma la presenza di tutte le altre librerie e il codice di integrazione che le unisce.

Per questo motivo, le annotazioni verranno scansionate solo una volta per tutte le classi invece di ogni libreria (EJB, JPA, ecc.) Che esegue questa scansione più e più volte. Anche per questo motivo, le annotazioni CDI possono essere applicate ai bean EJB e in essi possono essere iniettati i gestori di entità JPA.

Perché ho bisogno di qualcosa di enorme come JBoss solo per compilare un semplice codice per inviare un'e-mail?

Ci sono alcune cose che non vanno in questa domanda:

1. Per la compilazione è necessario solo il jar API, che è inferiore a 1 MB per il profilo Web e poco più di 1 MB per il profilo completo.
2. Per correre hai ovviamente bisogno di un'implementazione, ma "massiccio" sta esagerando. OpenJDK, ad esempio, è di circa 75 MB e TomEE (un'implementazione del profilo Web contenente il supporto per la posta) è solo di 25 MB. Anche GlassFish (un'implementazione del profilo completo) è solo 53 MB.
3. Mail funziona perfettamente da Java SE (e quindi Tomcat) anche utilizzando mail.jar e activation.jar indipendenti .

Perché le librerie Java EE non sono "standard" e sono incluse nel normale download di JVM e / o nell'SDK?

Java EE in un certo senso è stato uno dei primi tentativi di suddividere il già enorme JDK in blocchi più facili da gestire e scaricare. Le persone si lamentano già del fatto che le classi grafiche (AWT, Swing) e le applet si trovano all'interno di JRE quando tutto ciò che fanno è eseguire alcuni comandi su un server headless. E poi vuoi includere anche tutte le librerie Java EE nel JDK standard?

Con l'eventuale rilascio del supporto per la modularità avremo solo un piccolo JRE di base con molte cose installabili separatamente come pacchetti. Forse un giorno molte o anche tutte le classi che ora compongono Java EE saranno anche tali pacchetti. Il tempo lo dirà.

Perché ci sono così tante offerte Java EE quando esistono solo due versioni principali di Java standard (Oracle JVM / SDK | OpenJDK JVM / JDK)?

Esistono più di due versioni di Java SE. C'è almeno l'IBM JDK, il precedente BEA (JRocket, che è stato fuso in Oracle / Sun a causa dell'acquisizione), varie altre implementazioni open source e una sfilza di implementazioni per uso embedded.

Il motivo per cui Java SE ed EE sono una specifica è che molti fornitori e organizzazioni possono implementarla e quindi incoraggia la concorrenza e mitiga il rischio di vincoli del fornitore.

Non è davvero diverso con i compilatori C e C ++, dove hai molte offerte concorrenti e tutte aderenti allo standard C ++.

Perché la versione della libreria Java EE non è sincronizzata con le versioni della libreria Java standard (Java EE 6 e Java 7)

Java EE si basa su Java SE, quindi rimane indietro. Le versioni però corrispondono. Java EE 5 richiede Java SE 5. Java EE 6 richiede Java SE 6 e così via. È solo che soprattutto quando Java SE X è aggiornato, Java EE X-1 è attuale.

Ecco alcune risposte rapidamente composte alle tue domande ...

• Perché le librerie JavaEE non possono funzionare senza un server delle applicazioni? I servizi forniti da JavaEE (transazioni gestite dal contenitore, iniezione delle dipendenze gestite dal contenitore, servizio timer, ecc.) Coinvolgono intrinsecamente Application Server conformi a JavaEE (ad esempio: GlassFish, JBoss, WebSphere, ecc ...). Pertanto le librerie JavaEE non servono a nulla senza un tale contenitore. " Perché ho bisogno di qualcosa di così grande come JBoss solo per compilare un semplice codice per inviare un'e-mail? " Non lo fai. Ci sono modi per inviare un'e-mail senza JavaEE ... Ma se vuoi farlo nel modo JavaEE, hai bisogno di un contenitore JavaEE.

• Perché le librerie JavaEE non sono incluse nel download di JavaSE? Lo stesso motivo per cui molte librerie non sono incluse: sarebbe eccessivo. Dato che non puoi nemmeno usare le librerie JavaEE senza un server delle applicazioni, perché preoccuparti di includerle? JavaEE deve essere scaricato se e quando uno sviluppatore installa un server delle applicazioni e decide di utilizzare JavaEE.

• Perché ci sono così tante offerte JavaEE? Ci sono davvero " così tante " offerte JavaEE? In tal caso, elencane alcuni. Più precisamente, credo che ci siano più implementazioni delle stesse API .

• Cosa si può fare con JavaEE che non possono fare senza Java standard? Molte. Non puoi fare affidamento su un server delle applicazioni per gestire transazioni o contesti di persistenza senza JavaEE. Non è possibile consentire a un server delle applicazioni di gestire l'inserimento delle dipendenze EJB senza JavaEE. Non è possibile utilizzare un servizio timer gestito dall'applicazione senza JavaEE. La risposta a questa domanda dovrebbe rendere la risposta alla prima domanda abbastanza chiara ... La maggior parte dei servizi forniti da JavaEE richiedono un contenitore JavaEE.

• Cosa puoi fare con JavaSE che non puoi fare con JavaEE? Ehm ... non lo so.

• Quando uno sviluppatore decide di aver bisogno di JavaEE? Questa domanda è del tutto soggettiva ... Ma se hai bisogno di uno dei servizi forniti da JavaEE, inizi a pensarci. Se non sai cosa sia JavaEE ... probabilmente non ne hai bisogno.

• Quando uno sviluppatore decide di non aver bisogno di JavaEE? Vedi risposta precedente.

• Perché la versione della libreria JavaEE non è sincronizzata con la versione JavaSE? Buona domanda. Non pretendo di sapere come rispondere ... Ma immagino che la risposta sia: "perché non sono sincronizzati".

A volo d'uccello, Java EE è una piattaforma, cioè qualcosa su cui possiamo costruire.

In una prospettiva più tecnica, lo standard Java Enterprise Edition definisce un insieme di API comunemente utilizzate per la creazione di applicazioni aziendali. Queste API sono implementate dai server delle applicazioni e, sì, diversi server delle applicazioni sono liberi di utilizzare differenti implementazioni delle API Java EE.

Tuttavia, la libreria java ee non funzionerà e non verrà compilata a meno che il codice non venga eseguito o abbia accesso a un server delle applicazioni Java EE (come JBoss, GlassFish, Tomcat, ecc.).

Compili con le API Java EE, quindi hai bisogno solo di quelle API in fase di compilazione. In fase di esecuzione, avrai anche bisogno di un'implementazione di queste API, cioè un server delle applicazioni.

Perché ho bisogno di qualcosa di enorme come JBoss solo per compilare un semplice codice per inviare un'e-mail?

Non lo fai. Tuttavia, se desideri utilizzare l'API Java EE per l'invio della posta, avrai bisogno di un'implementazione di tale API in fase di runtime. Questo può essere fornito da un server delle applicazioni o da una libreria autonoma che aggiungi al tuo classpath.

Perché le librerie Java EE non sono "standard" e sono incluse nel normale download di JVM e / o nell'SDK?

Perché solo le API sono standardizzate, non le implementazioni.

Perché ci sono così tante offerte Java EE

Perché le persone non sono d'accordo sul modo giusto per implementare determinate funzionalità. Perché diversi fornitori competono per la quota di mercato.

Cosa si può fare con Java EE che non possono fare con Java standard?

Poiché le implementazioni Java EE sono costruite con "Java standard": niente. Tuttavia, sfruttare le librerie esistenti può far risparmiare una grande quantità di sforzi se si risolvono i tipici problemi aziendali e l'utilizzo di un'API standardizzata può impedire il vincolo del fornitore.

Cosa si può fare con Java standard che non possono fare con Java EE?

Niente, poiché Java EE include Java SE.

Quando uno sviluppatore decide di "aver bisogno" di Java EE? Quando uno sviluppatore decide di non aver bisogno di Java EE?

In generale, le API Java EE risolvono problemi tipici e ricorrenti nell'informatica aziendale. Se hai problemi di questo tipo, di solito ha senso utilizzare le soluzioni standard, ma se hai problemi diversi, potrebbero essere necessarie soluzioni diverse. Ad esempio, se hai bisogno di parlare con un database relazionale, dovresti considerare l'utilizzo di JPA. Ma se non hai bisogno di un database relazionale, JPA non ti aiuterà.

Cos'è Java EE?

Partiamo dalla definizione di canonicità su wiki:

Java Platform, Enterprise Edition o Java EE è la piattaforma di elaborazione Java aziendale di Oracle. La piattaforma fornisce un'API e un ambiente di runtime per lo sviluppo e l'esecuzione di software aziendale, inclusi servizi di rete e Web e altre applicazioni di rete su larga scala, multilivello, scalabili, affidabili e sicure.

Il punto principale qui è che Java EE è una piattaforma che fornisce un'API, non una libreria concreta.

Cosa serve per Java EE?

Lo scopo principale di Java EE sono le applicazioni basate su rete, a differenza di Java SE orientato allo sviluppo di applicazioni desktop con semplice supporto di rete. Questa è la differenza principale tra loro. Scalabilità, messaggistica, transazioni, supporto DB per ogni applicazione ... la necessità in tutto questo è aumentata con l'evoluzione della rete. Ovviamente molte soluzioni pronte fornite da Java SE sono utili per lo sviluppo di rete, quindi Java EE estende Java SE.

Perché abbiamo bisogno dei server delle applicazioni per eseguire il nostro codice?

Perché abbiamo bisogno di sistemi operativi? Perché c'è molto lavoro doloroso con l'hardware che dobbiamo fare per rendere l'applicazione ancora più semplice. E senza OS devi farlo ancora e ancora. Il sistema operativo semplificato è solo un contenitore programmatico, che ci fornisce un contesto globale per eseguire le nostre applicazioni.

E questo è ciò che sono i server delle applicazioni. Ci consentono di eseguire le nostre applicazioni nel loro contesto e ci forniscono molte funzionalità di alto livello necessarie per le applicazioni di rete aziendali ad alto carico. E non vogliamo scrivere le nostre biciclette per risolvere questi problemi, vogliamo scrivere codice che soddisfi le nostre esigenze aziendali.

Un altro esempio qui potrebbe essere JVM per Java.

Perché Java EE non contiene app server a bordo?

Difficile da dire per me. Penso che sia stato fatto per una maggiore flessibilità. Java EE dice cosa dovrebbero fare, decidono come farlo.

Perché JVM non include Java EE?

Perché si sono rivolti a diversi settori di mercato. Java EE ha un sacco di funzionalità che non sono necessarie per i normali desktop.

Perché ci sono così tante offerte Java EE?

Perché Java EE descrive solo il comportamento. Tutti possono implementarlo.

Cosa si può fare con Java EE che non possono fare con Java SE?

Per conquistare Internet. È davvero difficile da fare con applet e socket Java SE :)

Cosa si può fare con Java SE che non possono fare con Java EE?

Come accennato in precedenza, Java EE estende Java SE, quindi con Java EE dovresti essere in grado di fare tutto ciò che è disponibile per Java SE.

Quando uno sviluppatore decide di "aver bisogno" di Java EE?

Quando hanno bisogno della potenza di Java EE. Tutto ciò che è menzionato sopra.

Quando uno sviluppatore decide di non aver bisogno di Java EE?

Quando scrivono una normale applicazione per console o desktop.

Perché le versioni di Java SE e Java EE non sono sincronizzate?

Java ha sempre avuto problemi con le sue tecnologie di denominazione e controllo delle versioni. Quindi questa situazione non fa eccezione.

Java EE si basa sul concetto di contenitore.
Il container è un contesto di esecuzione all'interno del quale verrà eseguita la tua applicazione e che fornirà a quest'ultima un insieme di servizi. Ogni tipo di servizio è definito da una specifica denominata JSR. Ad esempio JSR 907, JTA (Java Transaction Api) che fornisce un modo standard per gestire la transazione distribuita su diverse risorse.
Ci sono generalmente molte implementazioni diverse per un dato JSR, l'implementazione che utilizzerai dipende dal provider del contenitore, ma non ti dispiace davvero perché sei sicuro che il comportamento rispetti il ​​contratto predefinito: l'API JSR.
Quindi, per sfruttare Java EE, è necessario eseguire l'applicazione all'interno di un contenitore. I due principali sono EJB e servlet container, entrambi presenti su qualsiasi application server certificato Java EE.

Lo scopo di tutto ciò è definire un ambiente di esecuzione standard per consentire di impacchettare la propria applicazione solo con gli elementi essenziali, id.est. i tuoi affari. Evita di dipendere da un set sconosciuto e vario di librerie di terze parti che altrimenti dovresti impacchettare e fornire con la tua app e che potrebbero essere fonti di conflitto con altre app sul server. In Java EE sai che tutti i requisiti standard non funzionali come sicurezza, transazione, scalabilità, invocazione remota e molti altri saranno forniti dal contenitore (suddiviso in fattori per tutte le app in esecuzione al suo interno) e devi solo basare il tuo lavoro su di esso.