Un paquete opcional es una implementación de una API abierta, estándar (ejemplos de paquetes opcionales JavaServlet, Java3D). La mayoría de los paquetes opcionales están enraizados en el javax.*espacio de nombres, aunque puede haber excepciones.
Lucky
Respuestas:
212
Creo que es algo histórico: si un paquete se presenta como una adición a un JRE existente, aparece como javax. Si se presenta por primera vez como parte de un JRE (como NIO, creo), entonces aparece como java. Sin javaxembargo, no estoy seguro de por qué la nueva API de fecha y hora terminará 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ó javadespués de todo.
Creo que hay restricciones en el javapaquete: creo que los cargadores de clases están configurados para permitir que solojava.* se carguen las clases rt.jaro algo similar. (Ciertamente hay un check in ClassLoader.preDefineClass).
EDITAR: Si bien una explicación oficial (la búsqueda de orbfish sugerido no arrojó una en la primera página más o menos) no tiene dudas sobre "núcleo" frente a "extensión", todavía sospecho que en muchos casos la decisión de un paquete en particular tiene un razón histórica detrás de esto también. ¿Es java.beansrealmente ese "núcleo" de Java, por ejemplo?
¿Porque es más fácil para un lector presionar alt-t y escribirlo que para mí cortar y pegar usando iPad? ;). Sin embargo, tiene razón, creo que quise decir download.oracle.com/javase/tutorial/ext/index.html . Sin ofender, por cierto, generalmente encuentro sus respuestas útiles. Me sorprende que esta haya sido aceptada.
pez orb
1
El término "javax" no aparece en ninguna parte del enlace sugerido anteriormente en este hilo de comentarios.
folleto
La nueva API de fecha y hora realmente terminará como java.timedespués de todo.
Michael Piefel
234
Originalmente javaxestaba destinado a ser para extensiones, y a veces las cosas se promocionan fuera de javaxJava.
Un problema fue Netscape (y probablemente IE) que limita las clases que podrían estar en el paquete de Java.
Cuando Swing se preparó para "graduarse" a javapartir de javaxallí, hubo una especie de mini-explosión porque la gente se dio cuenta de que tendrían que modificar todas sus importaciones. Dado que la compatibilidad con versiones anteriores es uno de los objetivos principales de Java, cambiaron de opinión.
En ese momento, al menos para la comunidad (quizás no para Sun) javaxse perdió todo el punto . Así que ahora tenemos algunas cosas en javax que probablemente deberían estar java... pero aparte de las personas que eligieron los nombres de los paquetes, no sé si alguien puede descubrir cuál es la razón caso por caso.
"Cuando Swing se preparó para" graduarse "de Java a Java, hubo una especie de mini-explosión porque la gente se dio cuenta de que tendrían que modificar todas sus importaciones". ¿La gente se quejaba de algo que podía lograrse con una expresión regular que era el resultado de usar código de calidad de preproducción?
Trineo
10
Sip. Escribí una herramienta en Visual Cafe para convertir entre los dos (javax y java) antes de que Sun decidiera mantenerlo en el paquete javax.
TofuBeer
51
javalos paquetes son básicos y los javaxpaquetes son extensiones.
Swing era una extensión porque AWT era la API de IU original. Swing vino después, en la versión 1.1.
Swing no era parte de 1.1. Hubo una versión de Swing que se ejecutó en 1.1 como una biblioteca.
Tom Hawtin - tackline el
Ahí está la clave: "biblioteca", que no forma parte del JDK. ¿Tengo la versión incorrecta? Mis javadocs sugieren que JButton ha estado desde 1.3, por lo que quizás mi memoria me falló.
duffymo
1
Entonces, ¿por qué la nueva API de fecha y hora en javax .. fecha y hora no es "base"?
Pacerier
1
"... la nueva API de fecha y hora (JSR-310) ..." - alguien en Oracle / Sun decidió que era mejor ponerlo en Java, porque es una extensión más nueva de las bibliotecas principales. Si no está de acuerdo, es mejor llevarlo con ellos.
El espacio de nombres de Java generalmente se usa (es una palabra cargada) para extensiones estándar, actualmente conocidas como paquetes opcionales . Las extensiones estándar son un subconjunto de las API no principales; el otro segmento de las API no centrales obviamente llamó extensiones no estándar, ocupando los espacios de nombres como com.sun. * o com.ibm. . Las API principales ocupan Java. espacio de nombres
No todo en el mundo de la API Java comienza en el núcleo, por lo que las extensiones generalmente nacen de solicitudes JSR. Eventualmente son promovidos a núcleo basado en 'consejo sabio'.
El interés en esta nomenclatura surgió de un paso en falso por parte de Sun: las extensiones podrían haber sido promovidas al núcleo, es decir, movidas de javax. * A java. * Rompiendo la promesa de compatibilidad con versiones anteriores. Los programadores lloraron roncos y prevaleció el sentido común. Es por eso que la API Swing, aunque es parte del núcleo, continúa permaneciendo en el espacio de nombres javax. *. Y así es como los paquetes se promocionan 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 Sun lo agregó a la biblioteca de Java olvidando eliminar la x. Los desarrolladores comenzaron a hacer código con javax. Sin embargo, más tarde, los soles decidieron cambiarlo a Java. A los desarrolladores no les gustó la idea porque su código se arruinaría ... por lo que se guardó Java.
Los paquetes java. * son los paquetes principales del 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 forma estándar y escalable de hacer que las API personalizadas estén disponibles para todas las aplicaciones que se ejecutan en la plataforma Java.
Algunos paquetes como javax.swingno se incluyeron en la biblioteca estándar de Java al principio. La compañía Sun decidió considerarlos oficiales y los incluyó en las primeras versiones de Java como bibliotecas estándar o extensiones estándar.
Por convención, todas las extensiones estándar comienzan con un Xtiempo en que pueden ser promovidas a primera clase con el tiempo, como sucedió javax.swing.
java.timeahora en download.java.net/jdk8/docs/api/java/time/package-summary.htmlJavaServlet,Java3D). La mayoría de los paquetes opcionales están enraizados en eljavax.*espacio de nombres, aunque puede haber excepciones.Respuestas:
Creo que es algo histórico: si un paquete se presenta como una adición a un JRE existente, aparece como
javax. Si se presenta por primera vez como parte de un JRE (como NIO, creo), entonces aparece comojava. Sinjavaxembargo, no estoy seguro de por qué la nueva API de fecha y hora terminará 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ójavadespués de todo.Creo que hay restricciones en el
javapaquete: creo que los cargadores de clases están configurados para permitir que solojava.*se carguen las clasesrt.jaro algo similar. (Ciertamente hay un check inClassLoader.preDefineClass).EDITAR: Si bien una explicación oficial (la búsqueda de orbfish sugerido no arrojó una en la primera página más o menos) no tiene dudas sobre "núcleo" frente a "extensión", todavía sospecho que en muchos casos la decisión de un paquete en particular tiene un razón histórica detrás de esto también. ¿Es
java.beansrealmente ese "núcleo" de Java, por ejemplo?fuente
java.timedespués de todo.Originalmente
javaxestaba destinado a ser para extensiones, y a veces las cosas se promocionan fuera dejavaxJava.Un problema fue Netscape (y probablemente IE) que limita las clases que podrían estar en el paquete de Java.
Cuando Swing se preparó para "graduarse" a
javapartir dejavaxallí, hubo una especie de mini-explosión porque la gente se dio cuenta de que tendrían que modificar todas sus importaciones. Dado que la compatibilidad con versiones anteriores es uno de los objetivos principales de Java, cambiaron de opinión.En ese momento, al menos para la comunidad (quizás no para Sun)
javaxse perdió todo el punto . Así que ahora tenemos algunas cosas en javax que probablemente deberían estarjava... pero aparte de las personas que eligieron los nombres de los paquetes, no sé si alguien puede descubrir cuál es la razón caso por caso.fuente
javalos paquetes son básicos y losjavaxpaquetes son extensiones.Swing era una extensión porque AWT era la API de IU original. Swing vino después, en la versión 1.1.
fuente
java.time: docs.oracle.com/javase/8/docs/api/java/time/…El espacio de nombres de Java generalmente se usa (es una palabra cargada) para extensiones estándar, actualmente conocidas como paquetes opcionales . Las extensiones estándar son un subconjunto de las API no principales; el otro segmento de las API no centrales obviamente llamó extensiones no estándar, ocupando los espacios de nombres como com.sun. * o com.ibm. . Las API principales ocupan Java. espacio de nombres
No todo en el mundo de la API Java comienza en el núcleo, por lo que las extensiones generalmente nacen de solicitudes JSR. Eventualmente son promovidos a núcleo basado en 'consejo sabio'.
El interés en esta nomenclatura surgió de un paso en falso por parte de Sun: las extensiones podrían haber sido promovidas al núcleo, es decir, movidas de javax. * A java. * Rompiendo la promesa de compatibilidad con versiones anteriores. Los programadores lloraron roncos y prevaleció el sentido común. Es por eso que la API Swing, aunque es parte del núcleo, continúa permaneciendo en el espacio de nombres javax. *. Y así es como los paquetes se promocionan de las extensiones al núcleo: simplemente están disponibles para descargar como parte de JDK y JRE.
fuente
Javax solía ser solo para extensiones. Sin embargo, más tarde Sun lo agregó a la biblioteca de Java olvidando eliminar la x. Los desarrolladores comenzaron a hacer código con javax. Sin embargo, más tarde, los soles decidieron cambiarlo a Java. A los desarrolladores no les gustó la idea porque su código se arruinaría ... por lo que se guardó Java.
fuente
Los paquetes java. * son los paquetes principales del 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 forma estándar y escalable de hacer que las API personalizadas estén disponibles para todas las aplicaciones que se ejecutan en la plataforma Java.
fuente
Algunos paquetes como
javax.swingno se incluyeron en la biblioteca estándar de Java al principio. La compañía Sun decidió considerarlos oficiales y los incluyó en las primeras versiones de Java como bibliotecas estándar o extensiones estándar.Por convención, todas las extensiones estándar comienzan con un
Xtiempo en que pueden ser promovidas a primera clase con el tiempo, como sucediójavax.swing.fuente