javax vs package java

Question

Quel est le raisonnement derrière le package javax? Ce qui se passe en java et ce dans javax?

Je sais que beaucoup d'entreprise-y les paquets sont dans javax, mais c'est le Swing, la nouvelle date et l'heure de l'api (JSR 310) et d'autres J2SE paquets.

Answer 1

à l'origine javax était destiné à être pour les extensions, et parfois, les choses seraient promus sur javax en java.

Une question était Netscape (et probablement IE) limitant les classes qui pourrait être dans le package java.

Quand le Swing était "supérieures" à la java à partir de javax il y avait une sorte de mini-blow up parce que les gens ont réalisé qu'ils auraient à modifier l'ensemble de leurs importations. Étant donné que la rétro-compatibilité est l'un des principaux objectifs de Java, ils ont changé leur esprit.

À ce point dans le temps, au moins pour la communauté (peut-être pas pour le Soleil) le point de l'ensemble de javax a été perdu. Alors maintenant, nous avons certaines choses dans javax qui devrait probablement être en java... mais mis à part les personnes qui ont opté pour le package de noms, je ne sais pas si quelqu'un peut comprendre ce que la justification est au cas par cas.

Answer 2

Je pense que c'est un fait historique - si un paquet est présenté comme un ajout à un JRE, il s'agit en javax. Si c'est d'abord présenté comme une partie d'un JRE (comme NIO a été, je crois) ensuite, il s'agit en java. Pas sûr pourquoi, la nouvelle date et l'heure de l'API finira javax suivant cette logique que... à moins qu'il sera également disponible séparément comme une bibliothèque pour travailler avec les versions antérieures (ce qui serait utile).

Je crois qu'il y a des restrictions sur l' java - paquet je pense que les chargeurs de classe sont mis en place pour seulement permettent à des classes au sein d' java.* à être chargé à partir d' rt.jar ou quelque chose de similaire. (Il y a certainement un chèque en ClassLoader.preDefineClass.)

EDIT: Alors qu'une explication officielle (la recherche orbfish a suggéré de ne pas donner l'un dans la première page) est sans doute à propos de "base" vs "extension", j'ai toujours suspect que, dans de nombreux cas, la décision pour tout ensemble a une raison historique derrière elle. Est - java.beans vraiment que le "noyau" de Java, par exemple?

Answer 3

les packages java sont "de base", et les packages javax sont des extensions.

Swing est une extension car AWT a été à l'origine de l'INTERFACE utilisateur de l'API. Le Swing n'est venu qu'après, dans la version 1.1.

Answer 4

Le javax espace de noms est généralement (c'est un chargé de mot) utilisé pour les extensions du standard, connue sous le nom de paquets optionnels. Les extensions standard sont un sous-ensemble de la base non-Api; l'autre segment de la non-core Api évidemment appelé les extensions non standard, occupant les espaces de noms comme com.soleil.* ou com.ibm.. Le core Api prendre la java. espace de noms.

Tout n'est pas dans l'API Java monde commence dans le coeur, qui est pourquoi les extensions sont généralement nés hors de la JSR demandes. Ils sont finalement promu core basé sur le "sage conseil".

L'intérêt de cette nomenclature, venait de sortir d'un faux pas du Soleil une partie de l'extension pourrait avoir été promu à la base, c'est à dire déplacé de javax.* pour java.* casser la compatibilité ascendante de la promesse. Les programmeurs s'écria la voix rauque, et plus de sens a prévalu. C'est pourquoi, l'API Swing bien qu'une partie de la base, continue à rester dans le javax.* espace de noms. Et c'est aussi la façon dont les paquets sont promues à partir d'une extension de base - ils sont tout simplement mis à disposition pour télécharger le JDK et le JRE.