javax vs java paket

Question

Was ist der Grund für das javax-Paket? Was gehört zu java und was zu javax?

Ich weiß, dass viele Enterprise-Pakete in Javax enthalten sind, aber das gilt auch für Swing, die neue Datums- und Zeit-API (JSR-310) und andere J2SE-Pakete.

Answer 1

Ursprünglich javax war für Erweiterungen gedacht, und manchmal wurden Dinge aus dem javax in Java.

Ein Problem war, dass Netscape (und wahrscheinlich auch der IE) die Klassen, die im Java-Paket enthalten sein konnten, einschränkte.

Als Swing "graduiert" werden sollte, um java de javax gab es eine Art Mini-Blamage, weil die Leute merkten, dass sie alle ihre Importe ändern mussten. Da die Abwärtskompatibilität eines der Hauptziele von Java ist, änderten sie ihre Meinung.

Zu diesem Zeitpunkt ist, zumindest für die Gemeinschaft (vielleicht nicht für Sun), der ganze Sinn von javax war verloren. Jetzt haben wir also einige Dinge in javax, die wahrscheinlich in java ... aber abgesehen von den Leuten, die die Paketnamen ausgewählt haben, weiß ich nicht, ob irgendjemand herausfinden kann, was im Einzelfall der Grund dafür ist.

Answer 2

Ich denke, es ist eine historische Sache - wenn ein Paket als Zusatz zu einer bestehenden JRE eingeführt wird, kommt es als javax . Wenn es zunächst als Teil einer JRE (wie es NIO war, glaube ich), dann kommt es als java . Ich bin mir nicht sicher, warum die neue Datums- und Zeit-API am Ende als javax dieser Logik folgend, aber... es sei denn, es wird auch separat als Bibliothek verfügbar sein, um mit früheren Versionen zu arbeiten (was nützlich wäre). Anmerkung von vielen Jahren später: es (Datum und Zeit API) endete in der Tat in java schließlich.

Ich glaube, es gibt Einschränkungen für die java Paket - ich denke, Classloader sind so eingestellt, dass sie nur erlauben Klassen innerhalb java.* die geladen werden sollen von rt.jar oder etwas Ähnliches. (Es gibt sicherlich eine Prüfung in ClassLoader.preDefineClass .)

EDIT: Während eine offizielle Erklärung (die von orbfish vorgeschlagene Suche ergab keine auf der ersten Seite oder so) zweifellos "Kern" vs. "Erweiterung" ist, vermute ich dennoch, dass in vielen Fällen die Entscheidung für ein bestimmtes Paket auch einen historischen Grund hat. Ist java.beans wirklich das "Herzstück" von Java, zum Beispiel?

Answer 3

java Pakete sind Basis y javax Pakete sind Erweiterungen.

Swing war eine Erweiterung, denn AWT war die ursprüngliche UI-API. Swing kam später, in Version 1.1.

Answer 4

Der javax-Namensraum ist in der Regel (das ist ein belastetes Wort), das für Standard-Erweiterungen verwendet wird, derzeit bekannt als optionale Pakete . Die Standarderweiterungen sind eine Teilmenge der Nicht-Kern-APIs; das andere Segment der Nicht-Kern-APIs wird offensichtlich als Nicht-Standarderweiterungen bezeichnet und belegt Namensräume wie com.sun.* oder com.ibm. . Die Kern-APIs nehmen den Java. Namensraum.

Nicht alles in der Java-API-Welt beginnt im Kern, weshalb Erweiterungen in der Regel aus JSR-Anfragen hervorgehen. Sie werden schließlich auf der Grundlage "weiser Ratschläge" in den Kernbereich überführt.

Das Interesse an dieser Nomenklatur resultierte aus einem Fauxpas von Sun - Erweiterungen hätten in den Kernbereich verschoben werden können, d.h. von javax.* zu java.*, wodurch das Versprechen der Abwärtskompatibilität gebrochen worden wäre. Die Programmierer schrien sich die Seele aus dem Leib, und die Vernunft hat gesiegt. Aus diesem Grund verbleibt die Swing-API, obwohl sie Teil des Kerns ist, weiterhin im javax.*-Namensraum. Und so werden auch die Pakete von den Erweiterungen zum Kern befördert - sie werden einfach als Teil des JDK und der JRE zum Download bereitgestellt.

Answer 5

Java.*-Pakete sind die Kernpakete der Java-Sprache, was bedeutet, dass Programmierer, die die Java-Sprache verwenden, diese Pakete verwenden müssen, um die Java-Sprache überhaupt sinnvoll nutzen zu können.

javax.*-Pakete sind optionale Pakete, die eine standardisierte, skalierbare Möglichkeit bieten, benutzerdefinierte APIs für alle auf der Java-Plattform laufenden Anwendungen verfügbar zu machen.