Diskussion:Jakarta EE
| Archiv |
| Wie wird ein Archiv angelegt? |
Bisherige Versionen
Die neue ungesichtete Version gibt an, das JakartaEE in diesem Artikel falsch wäre. Es ist jedoch richtig. JavaEE wird unter dem Namen JakartaEE weiterentwickelt. Siehe https://mmilinkov.wordpress.com/2018/02/26/and-the-name-is/ - auch in der Englischen Seite hat man diesem Namen zumindest mit untergebracht.
--Shoeper (Diskussion) 11:49, 8. Aug. 2018 (CEST)
- JakartaEE gehört klar hierher. Die Übergabe von Spezifikation und Referenzimplementierung an ein neues Gremium sollte doch wohl erwähnenswert sein?--Xf01213 (Diskussion) 22:16, 4. Apr. 2019 (CEST)
- Ich bereue JakartaEE als Nachfolger hier eingearbeitet zu haben. Siehe https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ oder https://www.heise.de/developer/artikel/Jakarta-EE-Der-Anfang-vom-Ende-oder-die-Chance-fuer-einen-Neuanfang-4413537.html Mit dieser Nummer wird JakartaEE ein eigenständiger Fork und kein "Nachfolger mit Umbennung". Zwei Möglichkeiten: Eigenständiger Artikel (Relevanzkriterien?) oder eigenständiges Kapitel ("Fork JakartaEE")--Xf01213 (Diskussion) 23:08, 8. Mai 2019 (CEST)
- Den Sachverhalt "Namensrechte" habe ich in den Artikel im bisherigen Kapitel aufgenommen. Schade, dass niemand eine Meinung zu Relevanz oder Struktur schreibt.--Xf01213 (Diskussion) 22:37, 14. Mai 2019 (CEST)
Abschnitt "Wichtige APIs"
was bedeuten "o" und "x" in der Tabelle. das ist nirgends erklärt! --MauriceKA 13:21, 31. Mai 2007 (CEST)
- In der Zwischenzeit war jemand so freundlich, die Symbole in "ja/nein" zu ändern - aber es bleibt ein kleines Trauerspiel... schau sich mal jemand die Punkte "JAX-WS, JSTL, JPA" etc. an... das ist mal grob durcheinandergehauen. cljk 11:59, 18. Jul. 2007 (CEST)
Soweit ich sehen kann ist der Abschnitt "Wichtige APIs" völlig falsch. JAX-WS gibts z.Bsp. erst seit JEE5 und JAX-RPC nicht mehr. JAXB gibts auch noch.
- JAX-RPC 1.1 (JSR 101) steht bei Sun noch, und JAXB wird genannt. Ich habe 3 Tabellenzeilen vervollständigt und die Sun-Übersicht zitiert, aber ich bin damit nicht zufrieden. Interessiert die Version 1.4 von 2003 wirklich noch so brennend, dass dafür die Spalte mit vielen "nein"-Einträgen gerechtfertigt ist? Wenn, dann lieber eine Kombi-Spalte "verfügbar in Version", und eine dafür eine davor mit den JSR-Nummern. Die erste Tabellenzeile für EJB missbraucht die Versionsspalten für andere Kommentare, und die Vollständigkeit und Haltbarkeit der zum Teil in der 5.0-Spalte angegebenen API-Versionen ist auch fraglich. Gfis 11:25, 14. Sep. 2008 (CEST)
- Ich habe Anfang Oktober die Versionen und aktualisiert, da ich selbst für wisenschaftliche Untersuchungen mal eine Tabelle mit den JSR's gemacht habe. Bitte auf Fehler prüfen! ;) -- Rloewe 13:27, 29. Okt. 2008 (CET)
JavaMail enthält keinen Code für die Behandlung von NNTP. Oder gibts dafür einen Beleg? (nicht signierter Beitrag von 192.9.112.196 (Diskussion | Beiträge) 11:11, 10. Mär. 2009 (CET))
- Die aktuelle Spezifikation in JSR 909 (JavaMail 1.4) erwähnt NNTP zweimal und fordert für die Nutzung des News-Protokolls eine Installation eines entsprechenden "Transport providers" (S. 28). Das scheint mir auch eine arg schwache Unterstützung, insbesondere, da keine Implementierung mitgeliefert wird und ich noch niemanden gesehen habe, der abweichende Mail-Service-Klassen eingesetzt hat. Eine Implementierung liefert zum Beispiel Apache Commons Net. Ich habe es mal rausgenommen.--Karsten Tinnefeld (Diskussion) 20:20, 2. Nov. 2012 (CET)
Hinweis und Änderungen am Artikel
In der Tabelle zu den JavaEE Frameworks in der Zeile zu EJB werden drei EJB Typen aufgezeigt. Session, MDB und Entity Beans was für EJB 2.x auch korrekt ist. Nur wenn in der Tabelle in Spalte Version Java EE 5 auf Möglichkeiten des Einsatz mit Detachment außerhalb des Container etc. eingegangen werden soll, sind hier ein paar Fehler drin.
- EJB 3.0 nutzt Session Beans, MDB und Persistence Entity lokal synchron, nicht remote - Detachment von Objekten?? Eine MDB kann von einem Client nicht direkt angesprochen geschweige detach. - Eine SLSB,SFSB (stateless, statefull) wird vom Container im Lifecycle behandelt. Ein Detach findet nur bei Serialisierung durch Remote Zugriffe statt. Solchen Kommentar in der Tabelle zu geben ist ungenau und verwirrend! Er gibt keine Info auf die Unterschiede von 2.x und 3.x ein und ist somit falsch bzw. ungenügend an Detailinfos ... Dann lieber weglassen :) Fazit: Entweder weniger inhaltliches zu den EJB Komponenten schreiben und unzureichende Infos weglassen. (nicht signierter Beitrag von 194.114.62.72 (Diskussion) 14:16, 10. Jun. 2010 (CEST))
Aktualität
Könnte jemand etwas schreiben zu java EE 8 ? Und zum Entfernen der Java EE API aus Java 11?
Es würde mich natürlich interessieren und ich halte es für unabdinglich, wenn diese Seite nicht merklich veraltet wirken soll...
Jay Jay (nicht signierter Beitrag von 195.37.177.70 (Diskussion) 17:40:28, 2018-12-17)
Neue Bezeichnung Jakarta
Jakarta EE. Dazu hier. --Duisburg 2021 (Diskussion) 09:32, 12. Feb. 2021 (CET)
- Auch heise.de Das macht auch einige Artikelverschiebungen nötig. --2A02:810D:8FC0:DC0:BCC5:6526:948F:E570 20:32, 20. Feb. 2021 (CET)
- Erledigt. Die offizielle Spezifikation wurde dazu benutzt: Eclipse Foundation, Specification: Jakarta EE Platform, Version 9, Final Release, November 6, 2020. --Fabian von Treuen (Diskussion) 22:40, 24. Feb. 2021 (CET)
- Hmm… aber jetzt findet man im Artikel aber nicht mehr, wieso und warum das jetzt von Java zu Jakarta umbenannt wurde. Ein kleiner erklärender Satz, der die Hintergründe dazu ggf. verlinkt, wäre hier sicher hilfreich. --RokerHRO (Diskussion) 01:35, 15. Dez. 2021 (CET)
