Организация папок проекта Eclipse Java

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

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

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

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

эти пакеты соответствуют иерархии каталогов проекта. При использовании 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.класс это скомпилированный класс java, поэтому в независимой от платформы форме байт-кода, которая может быть запущена на любом JVM. Обычно jarfiles содержат только скомпилированные классы, хотя иногда вы можете загрузить версию jar, которая также содержит источник (.Java-файл. Это полезно, если вы хотите иметь возможность читать исходный код файла jar, который вы используете.

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

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

теперь, если вы развернете это приложение, оно обычно будет скомпилировано .файлы классов и в комплекте .банку (что в принципе красивое название .zip-файл плюс некоторая информация о манифесте). Делать .jar не требуется для запуска приложения, но удобен при развертывании/распространении приложения. Используя информацию манифеста, вы можете сделать a .jar-файл "исполняемый", так что пользователь может легко запустить его, см. [a].

как правило, вы также будете использовать несколько библиотек, т. е. существующие .файлы jar вы получили из интернета. Очень распространенными примерами являются log4j (структура ведения журнала) или JDBC библиотеки для доступа к базе данных и т. д. Также у вас могут быть свои собственные подмодули, которые развертываются в отдельных jarfiles (например, 'utilities_1_0.jar ' above). Как вещи разделены на jarfiles-это вопрос развертывания/распространения, все они по-прежнему разделяют универсальное пространство имен для исходного кода Java. Таким образом, вы можете распаковать все jarfiles и поместить содержимое в одну большую структуру каталогов, если хотите (но вы обычно этого не делаете).

при запуске приложения Java использует / состоит из нескольких библиотек, вы сталкиваетесь с тем, что обычно называют "Classpath hell". Один из самых больших недостатков Java, как мы его знаем. (Примечание: помощь предположительно на пути). Чтобы запустить Java-приложение в командной строке (т. е. не из Eclipse), вы должны указать каждый .расположение файла jar на пути к классам. Когда вы используете одну из многих фреймворков Java (Maven, Spring, OSGi, Gradle), обычно существует некоторая форма поддержки для облегчения этой боли. Если вы создаете веб-приложение, которое вам, как правило, просто нужно придерживаться его соглашений о слоении/развертывании, чтобы иметь возможность легко развернуть вещь в веб-контейнере по вашему выбору (Tomcat, Jetty, Glassfish).

Я надеюсь, что это дает общее представление о том, как все работает на Java!

[a] чтобы сделать исполняемый jar приложения MyApp, вам нужен JDK на вашем пути. Затем используйте следующую командную строку в компиляции (bin или target) каталог:

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

затем вы можете выполнить из командной строки:

java -jar myapp.jar

или дважды щелкнув файл jar. Примечание. Вы не увидите консоль Java в этом случае, так что это полезно только для приложений, которые имеют свой собственный графический интерфейс (например, приложение Swing) или которые могут работать в фоновом режиме (например, сервер сокетов).