Структура папок проекта Java Eclipse

Думайте о пакетах исходного кода Java как об одном большом иерархическом пространстве имен. Коммерческие приложения обычно находятся под именем « com.mycompany.myapp » (веб-сайт этого приложения может быть « http://myapp.mycompany.com », хотя это, очевидно, не всегда case).

Как вы будете организовывать вещи в пакете myapp, во многом зависит от вас. Различие, которое вы проводите для C # между исполняемыми (.exe), DLL и низкоуровневыми классами, в Java не существует в той же форме. Весь исходный код Java компилируется в файлы .class (содержимое которых называется «байт-кодом»), которые могут выполняться виртуальной машиной Java (JVM) на многих платформах. Таким образом, нет неотъемлемого различия между классами высокого и низкого уровня, если вы не приписываете такие уровни через свою упаковку. Обычный способ упаковки:

• com.mycompany.myapp : основной класс; MyApp (с основным методом)
• com.mycompany.myapp.model : классы модели предметной области; Клиент, заказ и т. Д.
• com.mycompany.myapp.ui : код пользовательского интерфейса (презентации или представления)
• com.mycompany.myapp.service : ​​услуги в вашем приложении, т. Е. Бизнес логика '
• com.mycompany.myapp.util : вспомогательные классы, используемые в нескольких местах

, это предполагает автономное приложение Java, оно может быть другим, если это веб-приложение, использующее одну из многих сред.

] Эти пакеты соответствуют иерархии каталогов в вашем проекте. При использовании Eclipse корень такой иерархии называется «исходным каталогом». В проекте может быть определено несколько исходных каталогов, обычно это «основной» и «тестовый» исходный каталог.

Пример файлов в вашем проекте:

src/test/java/com/acme/foo/BarTest.java
src/main/java/com/acme/foo/Bar.java
lib/utilities_1_0.jar

И внутри utilities_1_0.jar:

com/acme/foo/BarUtils.class

BarUtils.class это скомпилированный Java-класс, поэтому в независимой от платформы форме байт-кода, который может быть запущен на любой JVM. Обычно файлы jar содержат только скомпилированные классы, хотя иногда вы можете загрузить версию jar, которая также содержит исходные файлы (.java). Это полезно, если вы хотите иметь возможность читать исходный исходный код файла jar, который вы используете.

В приведенном выше примере Bar, BarTest и BarUtils находятся в одном пакете com.acme.foo, но физически находятся в в разных местах на жестком диске.

Классы, которые находятся непосредственно в исходном каталоге, входят в «пакет по умолчанию», обычно не рекомендуется хранить классы там, потому что неясно, к какой компании и приложению принадлежит класс, и вы можете получить конфликты имен, если какой-либо файл jar, который вы добавляете в свой путь к классам, содержит класс с тем же именем в пакете по умолчанию .

Теперь, если вы развернете это приложение, оно обычно будет скомпилировано в файлы .class и объединено в .jar (который в основном представляет собой причудливое имя для файла .zip плюс некоторая информация о манифесте). Making a .jar is not necessary to run the application, but handy when deploying/distributing your application. Using the manifest info you can make a .jar file 'executable', so that a user can easily run it, see [a].

Usually you will also be using several libraries, i.e. existing .jar files you obtained from the Internet. Very common examples are log4j (a logging framework) or JDBC libraries for accessing a database etc. Also you might have your own sub-modules that are deployed in separate jarfiles (like 'utilities_1_0.jar' above). How things are split over jarfiles is a deployment/distribution matter, they still all share the universal namespace for Java source code. So in effect, you could unzip all the jarfiles and put the contents in one big directory structure if you wanted to (but you generally don't).

When running a Java application which uses/consists of multiple libraries, you run into what is commonly referred to as 'Classpath hell'. One of the biggest drawbacks of Java as we know it. (note: help is supposedly on the way). To run a Java application on the command line (i.e. not from Eclipse) you have to specify every single .jar file location on the classpath. When you are using one of Java's many frameworks (Maven, Spring, OSGi, Gradle) there is usually some form of support to alleviate this pain. If you are building a web application you would generally just have to adhere to its layering/deployment conventions to be able to easily deploy the thing in the web container of your choice (Tomcat, Jetty, Glassfish).

I hope this gives some general insight in how things work in Java!

[a] To make an executable jar of the MyApp application you need a JDK on your path. Then use the following command line in your compile (bin or target) directory:

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

You can then execute it from the command line with:

java -jar myapp.jar

or by double-clicking the jar file. Note you won't see the Java console in that case so this is only useful for applications that have their own GUI (like a Swing app) or that may run in the background (like a socket server).