Wat is Java EE eigenlijk eigenlijk?

Java EE heeft deze “mysterieuze sluier” eromheen voor jongere Java-ontwikkelaars – een die ik al een tijdje probeer op te tillen met weinig succes.

Verwarring ontstaat door:

• Java EE lijkt zowel een bibliotheek als een platform te zijn – er zijn meerdere manieren om de Java EE-bibliotheek te “krijgen”, meestal van zoiets als de Java EE SDK-download van Oracle. De Java EE-bibliotheek zal echter niet werken, noch compileren, tenzij uw code wordt uitgevoerd op of toegang heeft tot een Java EE-toepassingsserver (zoals JBoss, GlassFish, Tomcat, enz.). Waarom? Kunnen de bibliotheken niet functioneren buiten de applicatieserveromgeving? Waarom heb ik iets enorms als JBoss nodig om eenvoudige code te compileren om een ​​e-mail te verzenden?

• Waarom zijn Java EE-bibliotheken niet “standaard” en opgenomen in de reguliere JVM-download en/of de SDK?

• Waarom zijn er zoveel Java EE-aanbiedingen als er eigenlijk maar twee hoofdvarianten van standaard Java zijn (Oracle JVM/SDK | OpenJDK JVM/JDK)?

• Wat kan men met Java EE wat men niet kan met standaard Java?

• Wat kan men met standaard Java dat men niet kan met Java EE?

• Wanneer besluit een ontwikkelaar dat ze Java EE “nodig” hebben?

• Wanneer besluit een ontwikkelaar dat ze Java EE niet nodig hebben?

• Waarom loopt de Java EE-bibliotheekversie niet synchroon met de standaard Java-bibliotheekreleases (Java EE 6 vs. Java 7)?

Bedankt voor je hulp bij het opruimen van de flog!

Antwoord 1, autoriteit 100%

Waarom kunnen de bibliotheken niet functioneren buiten de applicatieserveromgeving?

Eigenlijk kunnen ze dat wel. De meeste bibliotheken kunnen direct standalone worden gebruikt (in Java SE) of worden opgenomen in een .war (praktisch is dat bijna altijd Tomcat). Sommige delen van Java EE, zoals JPA, hebben expliciete secties in hun respectievelijke specificaties die vertellen hoe ze moeten werken en gebruikt moeten worden in Java SE.

Het gaat hier niet zozeer om een ​​applicatieserveromgeving op zich, maar om de aanwezigheid van alle andere bibliotheken en de integratiecode die hen verenigt.

Daarom worden annotaties slechts één keer gescand voor al je klassen in plaats van dat elke bibliotheek (EJB, JPA, enz.) dit steeds opnieuw scant. Mede daardoor kunnen CDI-annotaties worden toegepast op EJB-bonen en kunnen JPA-entiteitmanagers erin worden geïnjecteerd.

Waarom heb ik iets enorms als JBoss nodig om eenvoudige code te compileren om een ​​e-mail te verzenden?

Er zijn een paar dingen mis met deze vraag:

1. Voor het compileren heb je alleen de API-jar nodig, die kleiner is dan 1 MB voor het webprofiel en iets meer dan 1 MB voor het volledige profiel.
2. Voor hardlopen heb je natuurlijk een implementatie nodig, maar “massive” overdrijft dingen. De OpenJDK is bijvoorbeeld ongeveer 75 MB en TomEE (een Web Profile-implementatie met e-mailondersteuning) is slechts 25 MB. Zelfs GlassFish (een Full Profile-implementatie) is slechts 53 MB.
3. Mail werkt prima vanuit Java SE (en dus Tomcat) en ook met de standalone mail.jar en activatie.jar.

Waarom zijn Java EE-bibliotheken niet “standaard” en opgenomen in de reguliere JVM-download en/of de SDK?

Java EE was in zekere zin een van de eerste pogingen om de toch al enorme JDK op te splitsen in brokken die gemakkelijker te beheren en te downloaden zijn. Mensen klagen al dat de grafische klassen (AWT, Swing) en applets zich in de JRE bevinden, terwijl ze alleen wat commando’s uitvoeren op een headless server. En dan wil je ook alle Java EE-bibliotheken in de standaard JDK opnemen?

Met de uiteindelijke release van modulariteitsondersteuning hebben we slechts een kleine basis-JRE met veel dingen die afzonderlijk als pakketten kunnen worden geïnstalleerd. Misschien zullen op een dag veel of zelfs alle klassen die nu Java EE vormen, ook zo’n pakket zijn. De tijd zal het leren.

Waarom zijn er zoveel Java EE-aanbiedingen als er eigenlijk maar twee hoofdvarianten van standaard Java zijn (Oracle JVM/SDK | OpenJDK JVM/JDK)?

Er zijn meer dan alleen twee smaken van Java SE. Er is in ieder geval de IBM JDK, de vorige BEA-versie (JRocket, die vanwege de overname wordt samengevoegd met Oracle/Sun), verschillende andere open source-implementaties en een hele reeks implementaties voor embedded gebruik.

De reden waarom Java SE en EE een specificatie zijn, is dat veel leveranciers en organisaties het kunnen implementeren en dus concurrentie aanmoedigt en het risico van vendor lock-in vermindert.

Het is echt niet anders met C- en C++-compilers, waar je veel concurrerende aanbiedingen hebt en die allemaal voldoen aan de C++-standaard.

Waarom loopt de Java EE-bibliotheekversie niet synchroon met de standaard Java-bibliotheekreleases (Java EE 6 vs. Java 7)

Java EE bouwt voort op Java SE, dus het loopt achter. De versies komen wel overeen. Java EE 5 vereist Java SE 5. Java EE 6 vereist Java SE 6 enzovoort. Alleen als Java SE X actueel is, is Java EE X-1 meestal actueel.

Antwoord 2, autoriteit 29%

Hier zijn een paar snel samengestelde antwoorden op uw vragen…

• Waarom kunnen JavaEE-bibliotheken niet functioneren zonder een applicatieserver?
  De services die door JavaEE worden geleverd (containerbeheerde transacties, containerbeheerde afhankelijkheidsinjectie, timerservice, enz.) omvatten inherent JavaEE-compatibele Application Servers (bijvoorbeeld: GlassFish, JBoss, WebSphere, enz…). Daarom hebben de JavaEE-bibliotheken geen zin zonder een dergelijke container. “Waarom heb ik zoiets enorms als JBoss nodig om eenvoudige code te compileren om een ​​e-mail te verzenden?” Dat heb je niet. Er zijn manieren om een ​​e-mail te verzenden zonder JavaEE… Maar als je het op de JavaEE-manier wilt doen, heb je een JavaEE-container nodig.

• Waarom worden JavaEE-bibliotheken niet meegeleverd met JavaSE-download?
  Dezelfde reden waarom veel bibliotheken niet zijn opgenomen: het zou overkill zijn. Aangezien u de JavaEE-bibliotheken niet eens kunt gebruiken zonder een toepassingsserver, waarom zou u dan de moeite nemen om ze op te nemen? JavaEE moet worden gedownload als en wanneer een ontwikkelaar een applicatieserver installeert en besluit JavaEE te gebruiken.

• Waarom zijn er zoveel JavaEE-aanbiedingen?
  Zijn er echt “zoveel” JavaEE-aanbiedingen? Zo ja, vermeld er dan een paar. Nauwkeuriger gezegd, ik geloof dat er meerdere implementatieszijn van de dezelfde API’s.

• Wat kan men met JavaEE dat men niet kan zonder standaard Java?
  Veel. U kunt niet vertrouwen op een applicatieserver om transacties of persistentiecontexten te beheren zonder JavaEE. U kunt niet toestaan ​​dat een toepassingsserver EJB-afhankelijkheidsinjectie beheert zonder JavaEE. U kunt een door een applicatie beheerde timerservice niet gebruiken zonder JavaEE. Het antwoord op deze vraag zou het antwoord op de eerste vraag vrij duidelijk moeten maken… De meeste diensten die door JavaEE worden geleverd, vereisen een JavaEE-container.

• Wat kunt u met JavaSE wel wat u niet kunt met JavaEE?
  Eh… ik weet het niet.

• Wanneer besluit een ontwikkelaar dat ze JavaEE nodignodig hebben?
  Deze vraag is volledig subjectief… Maar als je een van de diensten van JavaEE nodig hebt, begin er dan over na te denken. Als je niet weet wat JavaEE is… heb je het waarschijnlijk niet nodig.

• Wanneer besluit een ontwikkelaar dat ze JavaEE niet nodig hebben?
  Zie vorig antwoord.

• Waarom is de JavaEE-bibliotheekversie niet gesynchroniseerd met de JavaSE-versie?
  Goede vraag. Ik zal niet doen alsof ik weet hoe ik het moet beantwoorden… Maar ik denk dat het antwoord is: “omdat ze niet synchroon lopen”.

Antwoord 3, autoriteit 21%

In vogelvlucht is Java EE een platform, d.w.z. iets waar we op kunnen bouwen.

Vanuit een meer technisch perspectief definieert de Java Enterprise Edition-standaard een reeks API’s die vaak worden gebruikt voor het bouwen van bedrijfsapplicaties. Deze API’s worden geïmplementeerd door applicatieservers – en ja, verschillende applicatieservers zijn vrij om verschillende implementaties van de Java EE API’s te gebruiken.

De java ee-bibliotheek zal echter niet werken en ook niet compileren, tenzij uw code wordt uitgevoerd op of toegang heeft tot een Java EE-toepassingsserver (zoals JBoss, GlassFish, Tomcat, enz.).

Je compileert op basis van de Java EE API’s, dus je hebt die API’s alleen nodig tijdens het compileren. Tijdens runtime heb je ook een implementatie van deze API’s nodig, d.w.z. een applicatieserver.

Waarom heb ik iets enorms als JBoss nodig om eenvoudige code te compileren om een ​​e-mail te sturen?

Dat doe je niet. Als u echter de Java EE API wilt gebruiken voor het verzenden van e-mail, heeft u tijdens runtime een implementatie van die API nodig. Dit kan worden geleverd door een toepassingsserver of door een op zichzelf staande bibliotheek die u aan uw klassenpad toevoegt.

Waarom zijn Java EE-bibliotheken niet “standaard” en opgenomen in de reguliere JVM-download en/of de SDK?

Omdat alleen de API’s zijn gestandaardiseerd, niet de implementaties.

Waarom zijn er zoveel Java EE-aanbiedingen

Omdat mensen het oneens zijn over de juiste manier om bepaalde functies te implementeren. Omdat verschillende leveranciers strijden om marktaandeel.

Wat kan men met Java EE wat men niet kan met standaard Java?

Aangezien Java EE-implementaties zijn gebouwd met “standaard Java”: niets. Het benutten van de bestaande bibliotheken kan echter veel moeite besparen als u typische bedrijfsproblemen oplost, en het gebruik van een gestandaardiseerde API kan vendor lock-in voorkomen.

Wat kan men met standaard Java dat men niet kan met Java EE?

Niets, aangezien Java EE Java SE omvat.

Wanneer besluit een ontwikkelaar dat hij Java EE nodig heeft? Wanneer besluit een ontwikkelaar dat ze Java EE niet nodig hebben?

Over het algemeen lossen de Java EE API’s typische, terugkerende problemen in enterprise computing op. Als je dergelijke problemen hebt, is het meestal logisch om de standaardoplossingen te gebruiken – maar als je verschillende problemen hebt, kunnen andere oplossingen nodig zijn. Als u bijvoorbeeld met een relationele database moet praten, kunt u overwegen om JPA te gebruiken. Maar als je geen relationele database nodig hebt, zal JPA je niet helpen.

Antwoord 4, autoriteit 19%

Wat is Java EE?

Laten we beginnen met de definitie van canoniciteit op wiki:

Java Platform, Enterprise Edition of Java EE is de onderneming van Oracle
Java-computerplatform. Het platform biedt een API en runtime
omgeving voor het ontwikkelen en uitvoeren van bedrijfssoftware, inclusief:
netwerk- en webservices en andere grootschalige, meerlagige,
schaalbare, betrouwbare en veilige netwerkapplicaties.

Het belangrijkste punt hier is dat Java EE een platform is dat een API biedt, niet een concrete bibliotheek.

Wat voor Java EE nodig?

Het belangrijkste bereik van Java EE zijn de netwerkgebaseerde applicaties, in tegenstelling tot Java SE gericht op de ontwikkeling van desktopapplicaties met eenvoudige netwerkondersteuning. Dit is het belangrijkste verschil tussen hen.
Schaalbaarheid, messaging, transactieverwerking, DB-ondersteuning voor elke applicatie… de behoefte aan dit alles is toegenomen met de evolutie van het netwerk.
Natuurlijk zijn veel kant-en-klare oplossingen die Java SE biedt nuttig voor netwerkontwikkeling, dus Java EE breidt Java SE uit.

Waarom hebben we applicatieservers nodig om onze code uit te voeren?

Waarom hebben we besturingssystemen nodig? Omdat er veel pijnlijk werk met hardware is dat we moeten doen om zelfs de eenvoudigste applicatie te maken. En zonder OS moet je het steeds opnieuw doen. Oververeenvoudigd besturingssysteem is slechts een programmatische container, die ons een wereldwijde context biedt om onze applicaties uit te voeren.

En dit zijn de applicatieservers. Ze stellen ons in staat om onze applicaties in hun context uit te voeren en bieden ons veel functionaliteit op hoog niveau die nodig is voor hoogbelaste bedrijfsnetwerkapplicaties. En we willen niet onze eigen fietsen schrijven om deze problemen op te lossen, we willen code schrijven die aan onze zakelijke behoeften zal voldoen.

Een ander voorbeeld hier zou JVM voor Java kunnen zijn.

Waarom bevat Java EE geen app-server aan boord?

Moeilijk te zeggen voor mij. Ik denk dat het is gedaan voor meer flexibiliteit. Java EE zegt wat ze moeten doen, zij beslissen hoe ze het doen.

Waarom bevat JVM geen Java EE?

Omdat ze gericht waren op verschillende marktsectoren. Java EE heeft een heleboel functionaliteit die niet nodig is voor gewone desktops.

Waarom zijn er zoveel Java EE-aanbiedingen?

Omdat Java EE alleen het gedrag beschrijft. Iedereen kan het implementeren.

Wat kan men met Java EE wat men niet kan met Java SE?

Om het internet te veroveren. Het is echt moeilijk om te doen met Java SE-applets en sockets 🙂

Wat kan men met Java SE dat men niet kan met Java EE?

Zoals hierboven vermeld, breidt Java EE Java SE uit, dus met Java EE zou u alles moeten kunnen doen wat beschikbaar is voor Java SE.

Wanneer besluit een ontwikkelaar dat ze Java EE “nodig” hebben?

Als ze de kracht van Java EE nodig hebben. Alles wat hierboven is vermeld.

Wanneer besluit een ontwikkelaar dat ze Java EE niet nodig hebben?

Als ze een gebruikelijke console of desktoptoepassing schrijven.

Waarom zijn versies van Java SE en Java EE niet gesynchroniseerd?

Java had altijd problemen met de naamgeving en versiebeheer van zijn technologieën. Deze situatie is dus geen uitzondering.

Antwoord 5, autoriteit 14%

Java EE heeft alles te maken met containerconcept.
Container is een uitvoeringscontext waarin uw toepassing wordt uitgevoerd en die deze laatste een reeks services biedt. Elk soort service wordt gedefinieerd door een specificatie met de naam JSR. Bijvoorbeeld JSR 907, JTA (Java Transaction Api) die een standaardmanier bieden om gedistribueerde transacties tegen verschillende bronnen te beheren.
Er zijn over het algemeen veel verschillende implementaties voor een bepaalde JSR, de implementatie die u zult gebruiken hangt af van de containerprovider, maar dat vind je niet erg omdat je zeker weet dat het gedrag het vooraf gedefinieerde contract respecteert: de JSR API.
Dus om te profiteren van Java EE, moet je je applicatie in een container draaien. De twee belangrijkste zijn EJB en servlet-container die beide aanwezig zijn op elke Java EE-gecertificeerde applicatieserver.

Het doel van dit alles is om een ​​standaard uitvoeringsomgeving te definiëren om uw applicatie te verpakken met alleen de essentiële zaken, id.est. jouw zaken. Het voorkomt dat u afhankelijk bent van een onbekende en verschillende reeks bibliotheken van derden die u anders zou moeten verpakken en bij uw app zou moeten leveren, en die bronnen van conflicten kunnen zijn met andere apps op de server. In Java EE weet je dat alle standaard niet-functionele vereisten zoals beveiliging, transactie, schaalbaarheid, aanroepen op afstand en nog veel meer zullen worden geleverd door de container (gefactoriseerd voor alle apps die erin draaien) en je hoeft je werk er gewoon op te baseren.