Eclipse Java project folder organización

Piense en los paquetes de código fuente de Java como un gran espacio de nombres jerárquico. Las aplicaciones comerciales suelen vivir bajo " com.mycompany.myapp' (el sitio web de esta aplicación podría ser 'http://myapp.mycompany.com' aunque obviamente este no siempre es el caso).

Cómo organizar las cosas bajo su paquete myapp depende en gran medida de usted. La distinción que se hace para C# entre ejecutable (.exe), DLL y clases de bajo nivel no existen en la misma forma en Java. Todo el código fuente de Java está compilado .archivos de clase (cuyo contenido se llama 'bytecode') que pueden ser ejecutados por una Máquina Virtual Java (JVM) en muchas plataformas. Por lo tanto, no hay distinción inherente en las clases de alto/bajo nivel, a menos que atribuya dichos niveles a través de su empaque. Una forma común de envasado 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 : código de interfaz de usuario (presentación o vista)
• com.mycompany.myapp.service : servicios dentro de su aplicación, es decir, 'business logic'
• com.mycompany.myapp.util : clases auxiliares usadas en varios lugares

Esto sugiere una aplicación Java independiente, podría ser diferente si se trata de una aplicación web que utiliza uno de los muchos marcos.

Estos paquetes corresponden a un directorio jerarquía en su proyecto. Cuando se usa Eclipse, la raíz de dicha jerarquía se llama 'directorio de fuentes'. Un proyecto puede definir múltiples directorios de fuentes, comúnmente un directorio de fuentes' principal 'y un directorio de fuentes' de 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 dentro de utilities_1_0.jar:

com/acme/foo/BarUtils.class

BarUtils.clase esta es una clase java compilada, por lo que en forma de bytecode independiente de la plataforma que se puede ejecutar en cualquier JVM. Normalmente los jarfiles solo contienen las clases compiladas aunque a veces puede descargar una versión del jar que también contiene la fuente (.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 todos en el mismo paquete com.acme.foo pero físicamente residen en diferentes lugares 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é empresa y aplicación pertenece la clase y puede obtener conflictos de nombre si cualquier archivo jar que agregue a su classpath contiene una clase con el mismo nombre en el paquete predeterminado.

Ahora bien, si despliega esta aplicación, normalmente se compilará en .archivos de clase y agrupados en un .jar (que es básicamente un nombre elegante para a .archivo zip más información de manifiesto). Haciendo una .jar no es necesario para ejecutar la aplicación, pero es útil cuando implementación/distribución de su aplicación. Usando la información del manifiesto se puede hacer un .archivo jar 'ejecutable', para que un usuario pueda ejecutarlo fácilmente, ver [a].

Por lo general, también estará utilizando varias bibliotecas, es decir, existentes .archivos jar que obtuviste de Internet. Ejemplos muy comunes son log4j (un marco de registro) o bibliotecas JDBC para acceder a una base de datos, etc. También puede tener sus propios sub-módulos que se despliegan en jarfiles separados (como ' utilities_1_0.jar' arriba). Cómo son las cosas dividir sobre jarfiles es una cuestión de implementación / distribución, todavía todos comparten el espacio de nombres universal para el código fuente de Java. Así que en efecto, podrías descomprimir todos los jarfiles y poner el contenido en una estructura de directorios grande si quisieras (pero generalmente no lo haces).

Cuando se ejecuta una aplicación Java que utiliza/consta de varias bibliotecas, se ejecuta en lo que comúnmente se conoce como 'Classpath hell'. Uno de los mayores inconvenientes de Java como lo conocemos. (nota: la ayuda es supuestamente en el camino ). Para ejecutar una aplicación Java en la línea de comandos (es decir, no desde Eclipse) tiene que especificar cada uno .ubicación del archivo jar en la ruta de clase. Cuando estás usando uno de los muchos frameworks de Java (Maven, Spring, OSGi, Gradle) generalmente hay alguna forma de soporte para aliviar este dolor. Si está creando una aplicación web, generalmente solo tendría que adherirse a sus convenciones de capas/implementación para poder implementar fácilmente la cosa en el contenedor web de su elección (Tomcat, Jetty, Glassfish).

¡Espero que esto dé una idea general de cómo funcionan las cosas en Java!

[a] Para hacer un jar ejecutable de la aplicación MyApp necesita un JDK en su ruta. A continuación, utilice la siguiente línea de comandos en su directorio de compilación (bin o destino):

jar cvfe myapp.jar com.mycompany.myapp.MyApp com\mycompany\myapp

Luego puede ejecutarlo 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 Java en ese caso, por lo que 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 socket).