Considere los paquetes de código fuente de Java como un gran espacio de nombres jerárquico. Las aplicaciones comerciales generalmente viven bajo 'com.mycompany.myapp' (el sitio web para esta aplicación podría ser 'http://myapp.mycompany.com' aunque obviamente este no es siempre el caso).
Cómo se organizan las cosas en su paquete de myapp depende de usted. La distinción que hace para C# entre ejecutable (.exe), DLL y clases de bajo nivel no existe en la misma forma en Java. Todo el código fuente de Java se compila en archivos .class (cuyo contenido se llama 'bytecode') que puede ser ejecutado por una Máquina Virtual Java (JVM) en muchas plataformas. Por lo tanto, no existe una distinción inherente en las clases de alto nivel/bajo nivel, a menos que usted atribuya dichos niveles a través de su paquete. Una forma común de envase es:
- com.mycompany.myapp: clase principal; MyApp (con un método principal)
- com.mycompany.myapp.model: clases de modelo de dominio; Cliente, orden, etc.
- com.mycompany.myapp.ui: interfaz de usuario (presentación o vista) código
- com.mycompany.myapp.service: servicios dentro de su aplicación, es decir, 'la lógica de negocio'
- com. mycompany.myapp.util: clases auxiliares utilizados en varios lugares
esto sugiere una aplicación Java independiente, podría ser diferente si se trata de una aplicación web usando uno de los muchos marcos.
Estos paquetes corresponden a una jerarquía de directorios en su proyecto. Cuando se utiliza Eclipse, la raíz de dicha jerarquía se denomina 'directorio de origen'. Un proyecto puede definir múltiples directorios fuente, comúnmente un directorio fuente 'principal' y 'prueba'.
Ejemplo de archivos en su proyecto:
src/test/java/com/acme/foo/BarTest.java
src/main/java/com/acme/foo/Bar.java
lib/utilities_1_0.jar
Y utilities_1_0.jar interior:
com/acme/foo/BarUtils.class
BarUtils.class esta es una clase Java compilado, por lo que en forma de código de bytes plataforma independiente que puede ser ejecutar en cualquier JVM. Por lo general, los archivos jar solo contienen las clases compiladas, aunque a veces puede descargar una versión del archivo jar que también contiene los archivos de origen (.java). Esto es útil si desea poder leer el código fuente original de un archivo jar que está utilizando.
En el ejemplo anterior Bar, BarTest y BarUtils están todas en el mismo paquete com.acme.foo pero residen físicamente en diferentes ubicaciones en su disco duro.
Las clases que residen directamente en un directorio fuente están en el 'paquete predeterminado', por lo general no es una buena idea mantener las clases allí porque no está claro a qué compañía y aplicación pertenece la clase y puede obtener conflictos de nombres si algún archivo jar que agregue a su classpath contiene una clase con el mismo nombre en el paquete predeterminado.
Ahora, si implementa esta aplicación, normalmente se compilará en archivos .class y se incluirá en .jar (que es básicamente un nombre elegante para un archivo .zip más cierta información de manifiesto). Hacer un .jar no es necesario para ejecutar la aplicación, pero es útil cuando despliega/distribuye su aplicación. Usando la información del manifiesto, puede hacer que un archivo .jar sea 'ejecutable', para que un usuario pueda ejecutarlo fácilmente, consulte [a].
Por lo general, también utilizará varias bibliotecas, es decir, archivos .jar existentes que obtuvo de Internet. Ejemplos muy comunes son log4j (un logging framework) o bibliotecas JDBC para acceder a una base de datos, etc. También podría tener sus propios submódulos que se implementan en archivos jar separados (como 'utilities_1_0.jar' arriba). Cómo se dividen las cosas en archivos jar es una cuestión de implementación/distribución, todas comparten el espacio de nombres universal para el código fuente de Java. Entonces, en efecto, podría descomprimir todos los archivos jar y poner los contenidos en una estructura de directorios grande si quisiera (pero generalmente no lo hace).
Cuando se ejecuta una aplicación Java que usa/consiste en múltiples bibliotecas, se encuentra con lo que comúnmente se conoce como 'infierno Classpath'. Uno de los mayores inconvenientes de Java tal como lo conocemos. (nota: se supone que la ayuda es on the way). Para ejecutar una aplicación Java en la línea de comandos (es decir, no desde Eclipse), debe especificar cada ubicación de archivo .jar en la ruta de clases. Cuando está utilizando uno de los muchos frameworks de Java (Maven, Spring, OSGi, Gradle) generalmente hay algún tipo de soporte para aliviar este dolor.Si está compilando una aplicación web, generalmente solo debe cumplir sus convenciones de estratificación/implementación para poder implementar fácilmente la cosa en el contenedor web que elija (Tomcat, Jetty, Glassfish).
Espero que esto dé una idea general de cómo funcionan las cosas en Java.
[a] Para crear un archivo ejecutable de la aplicación MyApp, necesita un JDK en su ruta. A continuación, utilice la siguiente línea de comandos en su compilación (bin u objetivo) guía:
jar cvfe myapp.jar com.mycompany.myapp.MyApp com\mycompany\myapp
continuación, se puede ejecutar desde la línea de comandos con:
java -jar myapp.jar
o haciendo doble clic en el archivo jar. Tenga en cuenta que no verá la consola de Java en ese caso, por lo que esto solo es útil para aplicaciones que tienen su propia GUI (como una aplicación Swing) o que pueden ejecutarse en segundo plano (como un servidor de socket).
Entonces, todo lo que dices tiene sentido, pero justo cuando configuro Eclipse con una jerarquía de carpetas de esta manera: com \ mydomain \ myapp \ util luego agregue un archivo fuente con la declaración: paquete com.mydomain.myapp.util; luego Eclipse crea una gran cantidad de nuevas carpetas en la carpeta de utilidades: com \ mydomain \ myapp \ util \ com \ mydomain \ myapp \ util \ src \ myclass.java –
Está confundiendo la jerarquía de su paquete con la carpeta de origen de Eclipse. La carpeta de origen de Eclipse debería ser algo así como 'src/main/java /' (si sigues las convenciones de Maven). Este es simplemente el punto de partida para su jerarquía de paquetes; la carpeta 'src/main/java' apuntará al paquete predeterminado. Debajo de esta carpeta, Eclipse generará carpetas para unir paquetes, por lo que su clase de ejemplo terminará en /src/main/java/com/mydomain/myapp/util/myclass.java –
¿Hay algún proyecto de Java en GitHub con esta estructura de carpetas para un ejemplo del mundo real? –