Algunas preguntas básicas sobre javax vs java packages

Question

Cuando voy a JavaDocs encuentro algunas clases en el paquete java, mientras que algunas están en javax. Luego me encontré con javax vs java package.

Lo que obtengo de este enlace casi de todas las respuestas es que el paquete javax es solo una extensión de la biblioteca java. Me refiero a que el primer Java debe haber venido con las bibliotecas de Java centrales I.E. java pero cuando se desarrolló un paquete más se lanzaron con javax. ¿Derecha?

Alguna pregunta que inmediatamente me viene a la mente como desarrollador. ¿Cuáles son las implicaciones de estos paquetes de nombre diferente para un desarrollador de Java? Aquí están las preguntas y análisis: -

1. Incluso si estoy de acuerdo javax es solo una extensión de core java. Pero, de nuevo, veo paquetes totalmente diferentes, como org.omg.CORBA, etc. ¿Por qué se llama javax.omg.CORBA?
2. ¿Estos paquetes como javax, org, vienen con la descarga estándar de JDK y JRE? ¿Deben descargarse estos por separado de JSE 1.6?
3. ¿El cargador de clases de bootstrap intenta encontrar las clases en estos paquetes de forma predeterminada como lo hace en el caso de las clases centrales de Java (como java.lang).

Answer 1

Creo que es bastante arbitrario. Como dice Jon Skeet en su respuesta a la pregunta a la que se vincula, mucha de ella histórica. Un buen ejemplo de esto es javax.sql: contiene clases relacionadas con JDBC que originalmente formaban parte de J2EE, pero que se incorporaron a J2SE en 1.4. Entonces ahora hay una división de clases inútil entre java.sql y javax.sql. No hay un significado particular asociado a la división java/javax dentro del JDK.

1. Las clases CORBA están donde están porque no están definidas por el estándar Java; son traducciones de interfaces definidas en las especificaciones de CORBA.
2. Hay muchos paquetes javax. * Que vienen con J2SE JDK/JRE estándar (javax.sql, javax.xml). También hay paquetes javax. * Que no (javax.inject, javax.servlet, etc.). Pero no hay paquetes java. * Que no estén en el JDK.
3. Creo que el cargador de clases bootstrap carga las clases java. * Y javax. * Por igual.

Answer 2

1. A menudo provienen de las partes que no son de Sun/Oracle. P.EJ. El paquete org.omg fue creado (aparentemente) por personas en http://omg.org/ ¿Ves la conexión entre el nombre del paquete y el nombre de dominio?
2. No, si se enumeran en J2SE JavaDocs para una versión en particular, vienen de serie con esa versión. Estos son los paquetes disponibles (incluidos por defecto) J2SE versiones 6 & 7.
3. Sí, están en la ruta de clase automáticamente. Intente importar una de las clases y compilarla/ejecutarla para confirmarlo. Otoh en cuenta que son como las clases de AWT (Color, Font etc.), donde pueden ser importados, en contraposición a java.lang paquete, cuyas clases hacerlo no necesita tener una declaración de importación en el código.

---

java.lang no tiene que ser importado ..es porque las clases de idiomas, se utilizan con más frecuencia?

Básicamente, sí. Tenga en cuenta que solo tiene relevancia para el compilador. Los archivos de clase contienen el nombre de clase totalmente calificado, AFAIU.

Answer 3

Históricamente, la idea era que los paquetes java. * Serían los que se enviaron con el JDK, y los paquetes javax. * Serían los que se deben descargar por separado. Todavía funciona de esta manera, hasta cierto punto; todos los paquetes java. * vienen con el JDK, y hay muchos paquetes javax. *, como los servlets, que deben descargarse por separado.

Una llave inglesa fue lanzada en este esquema cuando Sun decidió mover algunos paquetes javax *, como Swing, al JDK principal. De hecho iban a cambiar el nombre del paquete de javax.swing a java.swing, pero cuando se hizo evidente que esto rompería la compatibilidad con versiones anteriores para una gran cantidad de código, decidieron mover los paquetes, pero conservaron el javax. nombre de swing Entonces el nombre ya no es indicativo, pero está ahí por razones históricas.

No me sorprendería que ocurriera lo mismo con los paquetes org.omg y org.w3c (eran bibliotecas de terceros que se movieron al núcleo JDK y no se pudieron cambiar los nombres). De todos modos, si está en los documentos de la API de JDK, puede usarlo sin descargar nada aparte del JDK principal, y el cargador de clases lo encontrará muy bien.