• Главная
  • Карта сайта
Не найдено

Управління Java classpath (Windows)

  1. структура пакета
  2. Налаштування конфігурації Windows
  3. Малюнок 1. Властивості Windows Explorer
  4. структура директорії
  5. Малюнок 2. Структура директорій, що повторює структуру пакета
  6. компіляція
  7. Файл для компілювання
  8. Куди вирушає результат
  9. Малюнок 3. Паралельні вихідні та скомпільовані ієрархії
  10. Лістинг 1. Клас в одному пакеті може імпортувати клас в іншому пакеті
  11. Малюнок 4. Вихідна структура для декількох пакетів
  12. Лістинг 2. Компіляція MainFrame.java
  13. Малюнок 5. Мультіклассовий результат
  14. Налаштування classpath
  15. Запуск програми
  16. Інші місця зберігання класів
  17. Поточна робоча директорія
  18. CLASSPATH
  19. jre \ lib \ ext
  20. jre \ lib \ endorsed
  21. Автоматизація управління classpath
  22. IDE
  23. Малюнок 6. Швидка настройка для classpath в Eclipse
  24. Ant
  25. Maven
  26. Висновок
  27. Ресурси для скачування

Рекомендації по управлінню classpath в Windows

Сlasspath є сполучною ланкою між виконуваним модулем Java і файлової системою. Він описує, де компілятор і інтерпретатор шукають пакет файлів .class для завантаження. Основна ідея полягає в тому, що ієрархія файлової системи відображає ієрархію пакету Java, а classpath вказує, які директорії в файловій системі є кореневими для ієрархії пакету Java.

На жаль, файлові системи надзвичайно складні, залежать від платформи, і не дуже добре узгоджуються з пакетами Java. Дане твердження більшою мірою справедливо по відношенню до Windows. Java спроектований хакерами UNIX, а це означає, м'яко кажучи, далеко не ідеальну синхронізацію з угодами Windows. Отже, classpath протягом багатьох років був джерелом постійного роздратування, як у нових користувачів, так і у досвідчених Java-програмістів. Classpath - далеко не найприємніша частина платформи Java, а скоріше дратує перешкода, яка змушує вас затримуватися на роботі в спробах усунути маленьку проблему, яка вперто не хоче вирішуватися.

Якісна IDE, наприклад Eclipse, може захистити Вас від деяких труднощів управління classpath, але тільки частково, і тільки до тих пір, поки все гладко (а щось завжди виявляється шкереберть). Отже, абсолютно необхідно, щоб кожен програміст на Java розумів classpath в повному обсязі. Тільки при глибокому розумінні можна сподіватися на вирішення проблем, що виникають через classpath.

В даній статті описано все, що Вам необхідно знати про Java classpath (і супутньому sourcepath) в Windows. В відповідній статті продемонстровані аналогічні методи для UNIX і Mac OS X. Дотримання зазначеного алгоритму має не тільки запобігти виникненню зайвих труднощів з classpath, але і усунути більшість проблем, що виникають.

структура пакета

Освоєння classpath починається з вихідного коду. Кожен клас належить пакету, а цей пакет повинен відповідати стандартним угодами по іменування. Коротко: ім'я пакета починається з дворівневого реверсувати імені домена, наприклад com.example або edu.poly. За ним слідує як мінімум ще одне слово, яке описує вміст пакету. Наприклад, так як у мене є ім'я домену elharo.com, то якби я писав клас Fraction, то міг би розмістити його в одному з наступних пакетів:

  • com.elharo.math
  • com.elharo.numbers
  • com.elharo.math.algebra.fields

Після реверсувати імені домена використовуйте тільки імена підпакетів, що складаються з одного слова. Не використовуйте абревіатури і стежте за правописом слів. При необхідності використовуйте програми перевірки орфографії. Найбільше число проблем, пов'язаних з classpath, викликані використанням у вихідному коді одного слова, а в файлової системі - абревіатури цього слова, або того ж самого слова, але з незначно відрізняється орфографією. Єдиним розумним рішенням є постійне використання правильно написаних нескорочених імен.

Повне ім'я пакета повинно складатися з малих літер, навіть для власних назв і абревіатур, які зазвичай пишуться великими літерами. Насправді Windows не розрізняє великі і малі літери, використовувані в іменах файлів, на відміну від Java і деяких файлових систем UNIX. Залежність від регістру - це вірний шлях до виникнення проблем при переміщенні файлів з однієї системи в іншу.

Ім'я пакета має складатися виключно з символів ASCII. Хоча компілятор і приймає написання назв пакунків на івриті, кирилиці, грецькому і інших шрифтах, але багато файлові системи цього не допускають і, як Ви незабаром побачите, ці імена пакетів матимуть подвійне призначення в якості імен директорій. Хоча імена класів і пакетів Java і пишуться в Unicode, багато файлові системи, включаючи FAT, поки не працюють з Unicode. Сумно, але в цьому списку все ще є багато файлових систем FAT. Просте копіювання файлу в систему з іншого кодуванням, заданої за замовчуванням, може перешкодити компілятору і інтерпретатора при пошуку правильних класів.

Якщо Ви пишете один єдиний клас, який будете використовувати тільки один раз, і більше він Вам не знадобиться, наприклад, клас, який створюється для перевірки своїх знань API - то Вам не треба поміщати його в пакет. Однак якщо який-небудь клас буде використовуватися більше одного разу, то він повинен знаходитися в пакеті.

Не економте на назву пакунка, а то це призведе до катастрофи! Якщо Вам необхідно доменне ім'я, то купите його. Якщо імена занадто довгі, то купіть коротший. (Одного разу я купив xom.nu, отже, префікс мого пакета складався всього лише з шести букв.) Ніколи не кладіть свої класи в пакеті, заданому за замовчуванням (в тому пакеті, який Ви отримуєте, якщо не включили вираз пакета в клас). Якщо доступ до пакету не дозволяє об'єктам взаємодіяти, додайте в класи більше загальних методів. Кожен клас, який Ви використовуєте більше одного разу, повинен знаходитися в пакеті.

Налаштування конфігурації Windows

Розширення файлів і шляхи доступу дуже важливі для Java і Windows. Однак перш ніж перейти до наступного етапу, переконайтеся, що Ви можете їх подивитися. Приховування частини імені файлу може бути прийнятним для кінцевого користувача (хоча у мене є сумніви з цього приводу), але це зовсім не годиться для розробника. Щоб це виправити, необхідно змінити деякі задані за замовчуванням в Windows Explorer.

Спочатку відкрийте папку на робочому столі Windows, не має значення яку. Зайдіть в меню Сервіс (Tools) і виберіть Властивості папки (Folder Options). У діалоговому вікні переконайтеся, що відзначені три наступних опції, як показано на малюнку 1:

  • "Виводити повний шлях в панелі адреси (Display the full path in the address bar)" має бути зазначено.
  • "Виводити повний шлях в рядку заголовка (Display the full path in title bar)" має бути зазначено.
  • "Приховувати розширення для зареєстрованих типів файлів (Hide file extensions for known file types)" має бути не відзначено.
Малюнок 1. Властивості Windows Explorer
Рекомендації по управлінню classpath в Windows   Сlasspath є сполучною ланкою між виконуваним модулем Java і файлової системою

Можливо, з'явиться бажання відзначити і пункт "Показувати приховані файли і папки (Show hidden files and folders)." Це не значно вплине на Вашу роботу з Java, але особисто я віддаю перевагу бачити, з чим я працюю. Налаштування даних властивостей надає більш детальну інформацію про те, що і де Ви робите, і допомагає набагато легше усувати будь-які потенційні проблеми.

структура директорії

Наступним етапом є організація Ваших вихідних файлів відповідно до структури пакета. Створіть де-небудь порожню директорію. Для даної статті я назву її project. Зазвичай набагато легше розмістити її в кореневому каталозі, наприклад C: \ project. Можна розмістити її і на робочому столі або в папці Документи і Налаштування (Documents and Settings), але тільки в разі потреби, оскільки це призведе до того, що необхідні команди стануть довшими і складними. (Можливо, у Вас не буде вибору, якщо Ви працюєте в Windows XP або більш пізніми версіями і не маєте прав адміністратора. В одного користувача системі набагато легше працювати при наявності прав адміністратора.)

Щоб Ви не робили, не зберігайте дану директорію (або будь-яку іншу) в Вашій папці JDK (наприклад, C: \ jdk1.6.0 або C: \ Program Files \ Java \ j2sdk1.5.0_09). Після першої інсталяції директорії JDK і JRE повинні залишитися незайманими.

Всередині директорії project створіть ще дві директорії: bin і src. (Деякі називають їх build і source, відповідно.)

Потім, в директорії src створіть ієрархію, яка буде відображати ієрархію Вашого пакета. Наприклад, при наявності класу, іменованого com.elharo.math.Fraction, я б розмістив директорію com в директорії src. Потім в директорії com я б створив директорію elharo. Потім директорію math в директорії elharo. І, нарешті, помістив би Fraction.java всередині даної директорії math, як показано на малюнку 2:

Малюнок 2. Структура директорій, що повторює структуру пакета

Дуже важливо: Не ставте в своїй директорії src нічого, крім вихідного коду. Зазвичай в ній знаходяться тільки .java файли. Іноді в даній директорії можна розмістити .html файли (для JavaDoc) або інші типи файлів вихідного коду. Але ніколи не пишіть в даній структурі .class файли або інші скомпільовані, згенеровані артефакти. Це прямий шлях до катастрофи. На жаль, якщо Ви втратите пильність, то компілятор javac зробить саме це. У наступному розділі я покажу, як це подолати.

компіляція

Компіляція Java-коду - це дуже підступна процедура, оскільки Вам необхідно стежити за ходом декількох пов'язаних, але відмінних один від одного речей:

Програмісти UNIX, які винайшли мову Java, дозволили компілятору визнавати прямі Слеш, характерні для UNIX, замість використовуваних в Windows зворотних Слеш. Отже, наступна команда буде також працювати:

Однак деякі команди не допускають використання прямих Слеш і вимагають зворотні. При роботі в Windows найпростіше завжди використовувати зворотні Слеш.

  • Цільовий файл, який Ви компілюєте.
  • Директорія, де компілятор шукає .java файли, імпортовані цільовим файлом.
  • Директорія, де компілятор шукає .class файли, імпортовані цільовим файлом.
  • Директорія, куди компілятор поміщає скомпільований результат.

За замовчуванням компілятор javac вважає, що всі вони є поточної робочої Директорією, що майже ніколи не відповідає Вашим потребам. Отже, при компіляції Вам необхідно точно вказати кожен з цих елементів.

Файл для компілювання

Перше, що Ви вказуєте, це .java файл, який Ви збираєтеся скомпілювати. Необхідно вказати шлях до даного файлу з поточної робочої директорії. Наприклад, ви перебуваєте в директорії project, показаної на малюнку 1 . Дана директорія містить директорію src. Директорія src містить директорію com, в якій, в свою чергу, знаходиться директорія example, а в ній зберігається файл Fraction.java. Компіляція виконується наступною командним рядком:

C: \ project> javac src \ com \ elharo \ math \ Fraction.java

Якщо шлях є хибним, то Ви отримаєте повідомлення про помилку такого типу:

error: can not read: src \ com \ example \ mtah \ Fraction.java

Якщо у Вас з'явилося повідомлення про помилку, то перевірте правильність вказівки шлях. В даному випадку, помилка говорить про те, що переставлені місцями друга і третя букви в "math".

Якщо Ви не знайшли орфографічною помилки, то переконаєтеся, що файл дійсно знаходиться там, де він повинен бути, виконавши команду dir, як показано нижче:

C: \ project \ src> dir src \ com \ example \ math ls: src / com / example / math: No such file or directory

Дане повідомлення зазвичай вказує на помилку в зазначенні шляху, але вона також може означати, що Ви перебуваєте не в тій директорії, в якій припускаєте. В даному прикладі Вам необхідно упевнитися, що поточної робочої Директорією є саме директорія project. Перевірте текст між C: і> в командному рядку, щоб упевнитися, що Ви перебуваєте там, де повинні бути. В даному прикладі Ви побачите, що в дійсності я перебуваю в C: \ project \ src, хоча повинен бути в C: \ project.

Куди вирушає результат

Якщо припустити, що немає ніяких синтаксичних помилок, то javac розмістить скомпільований .class файл в тій же директорії, що і відповідний .java файл. Вам це не потрібно. Розміщення .class і .java файлів в одній директорії створює великі труднощі при очищенні скомпільованих файлів без випадкового видалення .java файлів, які Ви б хотіли зберегти. Це створює проблеми при створенні чистих збірок і часто призводить до проблеми появи версій, а також ускладнює узгодження тільки що скомпільованих .class файлів при розподілі довічних файлів. Вам необхідно вказати компілятору, щоб він помістив скомпільований результат в абсолютно іншу директорію. Параметр -d вказує кінцеву директорію (зазвичай звану bin, build або classes):

C: \ project> javac -d bin src \ com \ elharo \ math \ Fraction.java

Тепер результат виглядає так, як показано на малюнку 3. Зверніть увагу, що javac створив повну ієрархію директорій com \ elharo \ math. Вам не треба робити цього вручну.

Малюнок 3. Паралельні вихідні та скомпільовані ієрархії

Sourcepath

Директорія, в якій Java шукає вихідні файли, називається sourcepath. У показаної тут схемою це директорія src. Це директорія, яка містить ієрархію вихідних файлів, розташованих в своїх власних директоріях. Це не директорія com або src \ com \ elharo \ math.

Більшість проектів використовує більше одного класу і більш одного пакета. Вони пов'язані з допомогою операторів import і повністю пакетно-класифікованих імен класу. Наприклад, припустимо, що Ви створюєте новий клас MainFrame в пакеті com.elharo.gui, як показано в лістингу 1:

Лістинг 1. Клас в одному пакеті може імпортувати клас в іншому пакеті

package com.elharo.gui; import com.elharo.math. *; public class MainFrame {public static void main (String [] args) {Fraction f = new Fraction (); // ...}}

Цей клас використовує клас com.elharo.math.Fraction в пакеті, відмінному від класу MainFrame. Початкове налаштування показана на малюнку 4. (я видалив скомпільований результат, отриманий на попередньому етапі, так як завжди можу скомпілювати його знову.)

Малюнок 4. Вихідна структура для декількох пакетів

Тепер давайте подивимося, що станеться, якщо я спробую скомпілювати MainFrame.java так, як я робив це раніше.

Лістинг 2. Компіляція MainFrame.java

C: \ project> javac -d bin src \ com \ elharo \ gui \ MainFrame.java src \ com \ elharo \ gui \ MainFrame.java: 3: package com.elharo.math does not exist import com.elharo.math. *; ^ Src \ com \ elharo \ gui \ MainFrame.java: 7: can not find symbol symbol: class Fraction location: class com.elharo.gui.MainFrame private Fraction f = new Fraction (); ^ Src \ com \ elharo \ gui \ MainFrame.java: 7: can not find symbol symbol: class Fraction location: class com.elharo.gui.MainFrame private Fraction f = new Fraction (); ^ 3 errors

Помилки в лістингу 2 відбулися через те, що хоча javac і знав, де знайти MainFrame.java, але він не знав, де знаходиться Fraction.java. (Ви думаєте, що було б цілком розумно помітити збігаються ієрархії пакета, але це не так.) Щоб прояснити це, мені потрібно задати значення sourcepath, яке вказує директорії, в яких компілятор повинен шукати ієрархію вихідних файлів. У лістингу 2, це src. Отже, я використовую -sourcepath ось таким чином:

C: \ project> javac -d bin -sourcepath src src \ com \ elharo \ gui \ MainFrame.java

Тепер програма компілюється без помилок і видає результат, показаний на малюнку 5. Зверніть увагу, що javac також скомпілював файл Fraction.java, на який посилається скомпільований мною файл.

Малюнок 5. Мультіклассовий результат

Компіляція декількох директорій в sourcepath

У Вашому sourcepath може бути кілька директорій, відокремлених крапкою з комою, хоча зазвичай в цьому немає необхідності. Наприклад, якщо Ви хочете включити як локальну директорію src, так і директорію C: \ Projects \ XOM \ src, де зберігається вихідний код для іншого проекту, то можна скомпілювати наступне:

C: \ project> javac -d bin -sourcepath src; C: \ Projects \ XOM \ src src / com / elharo / gui / MainFrame.java

Дана команда не компілює кожен файл, знайдений в будь-якої з цих ієрархій. Вона компілює тільки файли, на які прямо або побічно посилається один файл .java, який я і попросив скомпілювати.

Ні імена класів Java, ні назви пакунків не можуть містити пробілів. Однак іноді директорія, що містить вихідний файл або директорію пакету Java все-таки містить пробіл. Найбільш наочним прикладом служить Documents and Settings. Якщо Вам необхідно включити одну з директорій в шлях, то необхідно вказати відповідний аргумент командного рядка в подвійних лапках. Наприклад, якщо Ви перебуваєте в кореневій директорії C :, а папка src знаходиться в C: \ Documents and Settings \ Administrator \ project, то необхідно виконувати компіляцію наступним чином:

C: \> javac -d bin - sourcepath "C: \ Documents and Settings \ Administrator \ project" -classpath C: \ lib \ classes "C: \ Documents and Settings \ Administrator \ project \ src \ com \ elharo \ gui \ MainFrame.java "

У більшості випадків цього можна уникнути, перейшовши в директорію project, до компіляції або запуску програми.

Набагато частіше у Вас буде єдина вихідна директорія для .java файлів, і різні директорії для класів або JAR-архівів, де розміщуються попередньо скомпільовані сторонні бібліотеки. В цьому і полягає роль classpath.

Налаштування classpath

У великих проектах повторна компіляція кожного файлу може бути досить витратною з точки зору часу. Ви можете полегшити навантаження шляхом роздільного компіляції та зберігання окремих частин одного і того ж проекту в різних директоріях bin. Дані директорії додаються в classpath.

Існує кілька способів додавання класу в classpath. Однак слід використовувати тільки перемикач командного рядка -classpath. Наприклад, припустимо, що я хочу імпортувати файли з іншого проекту, які я попередньо скомпілював в директорії C: \ lib \ classes. Тоді я додам -classpath C: \ lib \ classes в командний рядок наступним чином:

C: \ project> javac -d bin -sourcepath src -classpath C: \ lib \ classes src \ com \ elharo \ gui \ MainFrame.java

Тепер припустимо, що мені необхідно додати дві директорії, C: \ project1 \ classes і C: \ project2 \ classes. Тоді вкажемо їх, розділивши крапкою з комою в такий спосіб:

C: \ project> javac -d bin -sourcepath src -classpath C: \ project1 \ classes; C: \ project2 \ classes src \ com \ elharo \ gui \ MainFrame.java

Звичайно, при бажанні Ви можете використовувати різні варіанти відносного шляху. Наприклад, якщо project1 і project2 є однорівневими вузлами поточної робочої директорії (тобто, у них одна і та ж батьківська директорія), то можна вказати їх наступним чином:

C: \ project> javac -d bin -sourcepath src -classpath .. \ project1 \ classes; .. \ project2 \ classes src \ com \ elharo \ gui \ MainFrame.java

До сих пір я припускав, что програма є сама по Собі повну и не вікорістовує ніякіх окремо скомпільовані сторонніх бібліотек. А якщо використовує, то Вам буде потрібно також вказати їх в classpath. Зазвичай бібліотеки класифікуються як JAR-файли, наприклад, junit.jar або icu4j.jar. В даному випадку, в classpath Ви вказуєте безпосередньо JAR-файл, а не містить їх директорію. (По суті, JAR-файл працює як директорія, що містить скомпільовані .class файли.) Наприклад, наступна команда додає в classpath директорію C: \ classes, файл icu4j.jar в поточній робочій директорії, і файл junit.jar in E: \ lib :

C: \ project> javac -d bin -sourcepath src -classpath C: \ classes; icu4j.jar; E: \ lib \ junit.jar src \ com \ elharo \ gui \ MainFrame.java

JAR-файли використовуються тільки для .class файлів і classpath, а не для .java файлів і sourcepath.

Зверніть увагу, що всі згадані тут директорії є директоріями верхнього рівня, що містять ієрархію пакета. Директорії, імена яких збігаються з іменами пакетів (com, elharo, math і т.д.) ніколи не вказуються в sourcepath або classpath безпосередньо.

Запуск програми

Отже, тепер Ви успішно скомпілювали програму і готові її запустити. Це схоже на компіляцію, але набагато простіше. При запуску програми необхідно вказати тільки:

  • Сlasspath.
  • Повний пакетно-класифіковане ім'я класу, що містить Ваш метод main ().

Не потрібно вказувати sourcepath.

Зазвичай classpath є тим же самим classpath, який Ви використовували для компіляції програми, з додаванням директорії, де був розміщений скомпільований результат. Наприклад, якщо команда компіляції була наступною:

C: \ project> javac -d bin -sourcepath src -classpath C: \ classes; E: \ lib \ junit.jar src \ com \ elharo \ gui \ MainFrame.java

а метод main () перебував в класі the class com.elharo.gui.MainFrame, то необхідно запустити програму в такий спосіб:

C: \ project> java -classpath bin; C: \ classes; E: \ lib \ junit.jar com.elharo.gui.MainFrame

Зверніть особливу увагу на те, що останній елемент командного рядка є ім'ям класу, а не ім'ям файлу. Воно не закінчується на .java або .class. Даний клас повинен бути знайдений де-небудь в classpath.

Інші місця зберігання класів

Я настійно рекомендую Вам завжди чітко вказувати classpath, і при компіляції, і при запуску. Є й інші місця, де Ви можете розмістити файли, так щоб вони додавалися в classpath і перебували як javac компілятором, так і інтерпретатором java. Однак дані варіанти скорочують обсяг набираемой з клавіатури інформації і роблять це за рахунок великої кількості отладок, коли - а не якщо - Ви випадково помістіть в classpath стару версію класу.

В даному розділі я покажу Вам кілька місць, де можна знайти приховані файли, які раптово з'являються у Вашому classpath і створюють проблеми. Найчастіше це відбувається на тих комп'ютерах, які Ви не контролюєте, наприклад на сервері.

Поточна робоча директорія

Компілятор завжди вносить поточну робочу директорію (.) В classpath, незалежно від того, просите Ви про це в явній формі чи ні. Занадто легко забути, що знаходиться чи не знаходиться в тій же директорії, що і Ви. Однак намагайтеся уникати розміщення будь-яких класів або ієрархій в своїх директоріях project або home. Замість цього, завжди акуратно зберігайте все для .java файлів в директорії src і для .class файлів - в директоріях bin.

CLASSPATH

Через деякий час Ви втомитеся від набору вручну директорій bin і JAR-архівів. Використовуйте змінну середовища CLASSPATH, в якій можна один раз вказати директорії і JAR-архіви. Тоді Вам не доведеться щоразу під час запуску javac або java вказувати їх шляху.

Не піддавайтеся спокусі, так як це може призвести до виникнення проблем при завантаженні неправильного класу або невірної версії класу. В результаті Ви витратите в сотні разів більше часу на усунення неполадок, викликаних випадкової завантаженням невірних класів, ніж заощадите на наборі. Існують і кращі способи автоматизації classpaths і позбавлення від введення з клавіатури.

jre \ lib \ ext

JAR-архіви, розміщені в директорії jre \ lib \ ext, додаються в classpath всіх додатків, запущених на даній віртуальній машині. Хоча це і здається зручним, але також є і помилкою, аналогічної додаванню директорій в змінну середовища CLASSPATH. Рано чи пізно (а швидше за все рано), Ви завантажте невірну версію класу з такого місця, про який Ви навіть і не думали, і витратите багато часу на налагодження.

Ця проблема може виявитися особливо серйозною при розгортанні серверних додатків. Будьте особливо уважні до того, щоб на тому сервері, на якому Ви розвертаєте, не було будь-яких додаткових JAR в директорії jre \ lib \ ext. Проблеми, викликані неправильною версією JAR-архіву в classpath, можуть виявитися дуже складними з точки зору усунення, якщо Ви не розпізнаєте симптоми і не будете знати, що шукати. Щоб уникнути таких проблем, деякі середовища розробки просунулися так далеко, як написання своїх власних загрузчиков класу, які обходять звичайні завантажувальні механізми класу коду Java.

jre \ lib \ endorsed

JAR-файли в директорії jre \ lib \ endorsed також додаються в classpath всіх додатків, що працюють на даній віртуальній машині. Відмінність полягає в тому, що дані файли фактично додаються швидше в bootclasspath, ніж в звичайний classpath і можуть замінити стандартні класи, наявні в JDK. Даний підхід виявляється особливо корисним для модернізації аналізатора XML і усунення неполадок в VM.

Ще раз повторю, що хоча і цей підхід і здається зручним, але з цієї ж причини є досить тривалу з точки зору усунення помилку. Якщо Вам необхідно замінити класи JDK, то при запуску використовуйте опцію -Xbootclasspath / p щоб уникнути випадкової завантаження невірної версії класу:

C: \ project> java -classpath C: \ classes -Xbootclasspath / p: xercesImpl.jar com.elharo.gui.MainFrame

Автоматизація управління classpath

Ви повинні навчитися користуватися звичайним молотком, перш ніж хапатися за пневматичний "пістолет". Аналогічно, Ви повинні впевнено керувати класами вручну, перш ніж починати користуватися більш потужними інструментами. Хоча, як тільки Ви освоїте набір інструментів командного рядка, Ви захочете використовувати інструмент, що автоматизує частину рутинної роботи з sourcepath і classpath. В основному дані інструменти виконують роботу по організації файлів згідно лініях, які я вже проклав в даній статті.

IDE

Більшість інтегрованих середовищ розробки, таких як Eclipse і NetBeans, автоматизують і надають допомогу в деяких аспектах управління classpath. Наприклад, коли Ви змінюєте ім'я пакета, Eclipse пропонує перемістити відповідний .java файл для узгодження, як показано на малюнку 6:

Малюнок 6. Швидка настройка для classpath в Eclipse

Майте на увазі, що дані IDE все ще знаходяться на вершині файлової системи, яка повинна бути задана належним способом, особливо якщо Вам необхідно інтегрувати в інші інструменти та інші IDE. Основна перевага даних інструментів полягає в тому, що деревовидні списки, таблиці і діалогові вікна GUI замінюють перемикачі командного рядка, але основна файлова структура залишається такою ж.

Ant

Ant є де-факто стандартним інструментом для автоматизації процесу конструювання. Замість розміщення директорій в jre \ lib \ ext або у змінній середовища CLASSPATH, Ant дійсно дозволяє створити одноетапні процеси конструювання. Однак все одно потрібно налаштувати classpath в Вашому файлі Ant build.xml і вручну розмістити вихідні файли в вірних директоріях. Однак хоча б не потрібно повторно вводити їх кожен раз при компіляції.

Maven

Maven пішов ще далі, ніж Ant в організації та автоматизації процесу конструювання classpath і пов'язаних з ним завдань. Maven за замовчуванням пропонує раціональну настройку, яка дозволяє конструювати прості проекти за допомогою всього лише кількох рядків коду, якщо тільки Ви розмістили вихідні файли там, де Maven буде їх шукати. Вам все ще доведеться координувати ієрархію файлової системи і ієрархію пакета. Maven особливо хороший для управління взаємозалежностями сторонніх бібліотек, хоча він і не так легко пристосовується, як Ant.

Висновок

Хоча використання classpath і є дуже важким, але Ви можете приручити його за допомогою декількох нехитрих правил. А самє:

  • Розміщуйте кожен клас в пакеті.
  • Суворо дотримуйтеся правил найменування пакетів і класів, і використання прописних символів.
  • Переконайтеся, що Ваша ієрархія пакета відповідає ієрархії директорії.
  • Завжди використовуйте опцію -d в javac.
  • Ніколи нічого не розміщуйте в jre \ lib \ ext.
  • Ніколи нічого не розміщуйте в jre \ lib \ endorsed.
  • Не ставте .java файли в тій же директорії, що і .class файли.
  • Не ставте будь-які .java або .class файли в поточній робочій директорії.

І остання рекомендація: більшість забирає багато часу проблем з classpath обертаються навколо таких простих помилок, як помилкове написання імені директорії або компіляція з невірною директорії. Якщо Ви не можете відразу визначити, в чому проблема, зверніться до друзів або колег, щоб вони на неї подивилися. Найчастіше я перебуваю занадто близько до проблеми, щоб розгледіти неполадку в моїй налаштуванні, яка є очевидною комусь ще. Друга пара очей виявляється дуже ефективним методом налагодження.

Звичайно, classpath зовсім не простий, але є управа і на його божевілля, яка робить його слухняним. Трохи акуратності й уваги, витрачених на угоду з присвоєння імен, аргументи командного рядка і структури директорій дозволять Вам скомпілювати і запустити програми при мінімумі суєти.

Ресурси для скачування

Схожі тими

  • Оригінал статті: Managing the Java classpath (Windows) .
  • " Управління Java classpath в UNIX "(Еліот Херолд, developerWorks, грудень 2006 р): стаття, в якій описується, як встановити classpath і sourcepath в UNIX, Linux і Mac OS X.
  • " Управління проектом: Maven полегшує завдання "(Чарльз Чен, developerWorks, квітень 2003 г.): стисло описані управління проектом з використанням Maven.
  • " IBM Cloudscape: розуміння Java classpath "(Джин Андерсон і Сьюзан Клайн, developerWorks, вересень 2004 року): роз'яснює, як встановити Java classpath для Cloudscape і Derby.
  • " Передова практика: структура Classpath для сервера додатків WebSphere "(Колектив WebSphere Best Practices, developerWorks, серпень 2001 г.): рекомендації по управлінню classpath в WebSphere Application Server.
  • завантажте Ant : Тепер є проектом високого рівня в Apache.
  • завантажте Maven : Програма управління компоновкою Apache для Java-проектів.
  • Бібліотека технічної літератури по Java на developerWorks : Великий перелік технічних статей і рекомендацій, навчальних посібників, стандартів і "червоних книг" IBM, по платформі Java.

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів

Новости
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью