library - javax maven
paquete javax vs java (6)
¿Cuál es la razón detrás del paquete javax? ¿Qué entra en java y qué en javax?
Sé que muchos paquetes empresariales-y están en javax, pero también lo están Swing, la nueva fecha y hora api (JSR-310) y otros paquetes J2SE.
Creo que es algo histórico: si se introduce un paquete como una adición a un JRE existente, se presenta como javax . Si se presenta por primera vez como parte de un JRE (como creo que fue NIO, creo), entonces se presenta como java . Aunque no estoy seguro de por qué la nueva API de fecha y hora terminará como javax siguiendo esta lógica ... a menos que también esté disponible por separado como una biblioteca para trabajar con versiones anteriores (lo que sería útil). Nota de muchos años después: en realidad terminó siendo java después de todo.
Creo que hay restricciones en el paquete java . Creo que los cargadores de clases están configurados para permitir solo que las clases dentro de java.* Se carguen desde rt.jar o algo similar. (Ciertamente hay un cheque en ClassLoader.preDefineClass ).
EDITAR: Si bien una explicación oficial (la búsqueda que orbfish sugirió no arrojó una en la primera página o algo así) es sin duda acerca de "núcleo" frente a "extensión", aún sospecho que en muchos casos la decisión para un paquete en particular tiene un Razón histórica detrás de esto también. ¿Es java.beans realmente ese "núcleo" para Java, por ejemplo?
El espacio de nombres javax generalmente se usa (eso es una palabra cargada) para las extensiones estándar, que actualmente se conocen como paquetes opcionales . Las extensiones estándar son un subconjunto de las API no centrales; el otro segmento de las API no centrales obviamente se llama extensiones no estándar, y ocupa los espacios de nombres como com.sun. * o com.ibm. . Las APIs básicas toman el java. espacio de nombres.
No todo en el mundo de la API de Java comienza en el núcleo, razón por la cual las extensiones generalmente nacen de solicitudes JSR. Eventualmente, son promovidos a núcleo basado en "consejos sabios".
El interés en esta nomenclatura surgió de un paso en falso por parte de Sun: las extensiones podrían haberse promovido a núcleo, es decir, haber pasado de javax. * A java. * Romper la promesa de compatibilidad hacia atrás. Los programadores gritaban roncos, y prevalecía el mejor sentido. Por esta razón, la API de Swing, aunque forma parte del núcleo, continúa permaneciendo en el espacio de nombres javax. *. Y así es como los paquetes pasan de las extensiones al núcleo: simplemente están disponibles para descargar como parte de JDK y JRE.
Javax solía ser solo para extensiones. Sin embargo, más tarde el sol lo agregó a la biblioteca de Java, olvidando quitar la x. Los desarrolladores comenzaron a hacer código con javax. Sin embargo, más tarde en el tiempo, Suns decidió cambiarlo a Java. A los desarrolladores no les gustó la idea porque su código se arruinaría ... así que se mantuvo javax.
Los paquetes java. * son los paquetes centrales de lenguaje Java, lo que significa que los programadores que usan el lenguaje Java tuvieron que usarlos para hacer un uso valioso del lenguaje java.
Los paquetes javax. * son paquetes opcionales, que proporcionan una manera estándar y escalable de hacer que las API personalizadas estén disponibles para todas las aplicaciones que se ejecutan en la plataforma Java.
los paquetes java son "base", y los paquetes javax son extensiones.
Swing era una extensión porque AWT era la API de interfaz de usuario original. Swing vino después, en la versión 1.1.
originalmente se pretendía que javax fuera para extensiones, y algunas veces las cosas se promovían de javax a java.
Un problema fue que Netscape (y probablemente IE) limitó las clases que podrían estar en el paquete java.
Cuando Swing estaba configurado para "graduarse" a java de javax, hubo una especie de mini-estallido porque la gente se dio cuenta de que tendrían que modificar todas sus importaciones. Dado que la compatibilidad hacia atrás es uno de los objetivos principales de Java, cambiaron de opinión.
En ese momento, al menos para la comunidad (tal vez no para Sun) se perdió todo el punto de javax. Así que ahora tenemos algunas cosas en javax que probablemente deberían estar en java ... pero aparte de las personas que eligieron los nombres de los paquetes, no sé si alguien puede averiguar cuál es la razón en cada caso.