3.1. Елементи пакету

Ще раз повторимо, що елементами пакету є вкладені пакети і типи (класи та

інтерфейси). Однойменні елементи заборонені, тобто не може бути однойменних

класу і інтерфейсу або вкладеного пакету і типу. В іншому випадку виникне помилка

компіляції.

Наприклад, в JDK 1.0 пакет java містив наступні пакети: applet, awt, io, lang, net, util;

і не містив жодного типу. Пакет java.awt містив вкладений пакет image і 46 класів

і інтерфейсів.

Складене ім'я якого елемента пакета складається з складного імені цього пакета

і простого імені елементу. Наприклад, для класу Object в пакеті java.lang складовим

ім'ям буде java.lang.Object, а для пакета image в пакеті java.awt - java.awt.image.

Ієрархічна структура пакетів була введена для зручності організації пов'язаних

пакетів, однак вкладені пакети або сусідні, тобто вкладені в один і той же пакет,

не мають ніяких додаткових зв'язків між собою, крім обмеження на розбіжність

імен. Наприклад, пакети space.sun, space.sun.ray, space.moon і factory.store зовсім

"Рівні" між собою, і типи з одного з цих пакетів не мають ніякого особливого

доступу до типів інших пакетів.

3.2. Платформна підтримка пакетів

Найпростішим способом організації пакетів і типів є звичайна файлова структура.

Розглянемо вироджений приклад, коли всі пакети, вихідний і бінарний код

розташовуються в одній директорії і її піддиректоріях.

У цій кореневої директорії повинна бути папка java, відповідна основного пакету

мови, а в ній, в свою чергу, вкладені папки applet, awt, io, lang, net, util.

Припустимо, розробник працює над моделлю сонячної системи, для чого створив

класи Sun, Moon і Test, і розташував їх у пакеті space.sunsystem. В такому випадку в

кореневої директорії буде папка space, яка буде відповідати однойменним

пакету, а в ній - папка sunsystem, в якій зберігаються класи цього розробника.

Як відомо, вихідний код розташовується в файлах з розширенням. Java, а бінарний - з

розширенням. class. Таким чином, вміст папки sunsystem може виглядати

наступним чином:

Moon.java

Moon.class

Sun.java

Sun.class

Test.java

Test.class

Іншими словами, початковий код класів

space.sunsystem.Moon

space.sunsystem.Sun

space.sunsystem.Test

space \ sunsystem \ Moon.java

space \ sunsystem \ Sun.java

space \ sunsystem \ Test.java

а бінарний код - у відповідних. class-файлах. Зверніть увагу, що перетворення

імен пакетів в файлові шляху зажадало заміни роздільника. (Точки) на символ-

роздільник файлів (для Windows це зворотний слеш \). Таке перетворення легко

зможе зробити як компілятор для пошуку вихідних текстів і бінарного коду, так і

віртуальна машина для завантаження класів та інтерфейсів.

Зверніть увагу, що було б помилкою запускати Java прямо з теки space \ sunsystem

і намагатися звертатися до класу Test, незважаючи на те, що файл-опис лежить саме

в ній. Необхідно піднятися на два рівні директорій вище, щоб Java, побудувавши шлях

з імені пакета, змогла виявити потрібний файл.

Крім того, важливо те, що Java завжди розрізняє регістр ідентифікаторів, а значить,

і назви файлів і директорій повинні точно відповідати запрограмованим іменах.

Хоча в деяких випадках операційна система може забезпечити доступ, не дивлячись на

регістр, але при зміні обставин розбіжності можуть привести до збоїв.

Існує спеціальне вираз, оголошує пакет (детально розглядається

нижче). Воно передує оголошенню типу і позначає, якому пакету буде належати

цей тип. Таким чином, набір доступних пакетів залежать від доступних

файлів, що містять оголошення типів і пакетів. Наприклад, якщо створити порожню

директорію, або заповнити її сторонніми файлами, то це аж ніяк не призведе до

появи пакету в Java.

Які файли доступні для утиліт Java SDK (компілятора, інтерпретатора і т.д.),

встановлюється на рівні операційної системи, адже утиліти - це звичайні програми,

які виконуються під управлінням ОС, і, звичайно, йдуть її правилам. Наприклад,

якщо пакет містить один тип, але файл-опис цього типу недоступний для читання

поточному користувачеві ОС, то для Java цей тип і цей пакет не будуть існувати.

Зрозуміло, що далеко не завжди зручно зберігати всі файли в одній директорії. Найчастіше

різні класи знаходяться в різних місцях, а деякі можуть навіть поширяться в

вигляді архівів, для прискорення завантаження через мережу. Вимога копіювати всі такі файли

в одну папку було б украй скрутним.

Тому Java використовує спеціальну змінну оточення, яка називається

classpath. Аналогічно тому, як мінлива path допомагає системі знаходити і завантажувати

динамічні бібліотеки, ця змінна допомагає працювати з Java-класами. Її значення

має складатися із шляхів до директорій або архівів, розділених крапкою з комою. З

версії 1.1 підтримуються архіви типів ZIP і JAR (Java ARchive) - спеціальний формат,

розроблений на основі ZIP для Java.

Наприклад, невелика classpath може мати таке значення:

.; C: \ java \ classes; d: \ lib \ 3Dengine.zip; d: \ lib \ fire.jar

В результаті всі зазначені директорії і вміст всіх архівів "додається" до

вихідної кореневої директорії. Java в пошуках класу буде шукати його за описаним

вище правилом у всіх зазначених папках і архівах по порядку. Зверніть увагу, що

першим в змінної вказана поточна директорія (представлена ​​точкою). Це робиться

для того, щоб пошук завжди починався з вихідною кореневої директорії. Звичайно, така

запис не є обов'язковою і робиться на розсуд розробника.

Незважаючи на явні зручності такої конструкції, вона таїть у собі і небезпеки. Якщо при

роботі трапилося так, що розробляються класи лежать в деякій директорії, і вона

вказана в classpath пізніше, ніж якась інша директорія, в якій виявляються

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

вноситися зміни, які ніяк не проявляються при запуску через те, що Java на

Насправді завантажує одні й ті ж файли з сторонньої папки.

Тому до цієї змінної середовища оточення необхідно ставиться з увагою. Корисно

пам'ятати, що необов'язково встановлювати її значення відразу для всієї операційної

системи. Його можна явно вказувати при кожному запуску компілятора або віртуальної

машини як опцію, що, по-перше, ніколи не вплине на інші Java-програми, а во-

друге, помітно спрощує пошук помилок, пов'язаних з некоректним значенням classpath.

Нарешті, можливо застосовувати і альтернативні підходи до зберігання пакетів і файлів

з вихідним і бінарним кодом. Наприклад, як такого сховища може бути

використана база даних. Більше того, існує обмеження на розміщення оголошень

класів в. java-файлах, що розглядається нижче, а при використанні БД будь-які

обмеження можна зняти. Проте, при такому підході рекомендується надавати

утиліти імпорту / експорту з урахуванням обмеження для переходів з / у файли.

3.3. Модуль компіляції

Модуль компіляції (complication unit) - зберігається в текстовому. Java-файлі і є

одиничною порцією вхідних даних для компілятора. Він складається з трьох частин:

• оголошення пакета;

• import-вираження;

• оголошення верхнього рівня.

Оголошення пакета одночасно вказує, якому пакету будуть належати всі

оголошуються нижче типи. Цей вираз може бути відсутнім, що означає, що ці

класи розташовуються в безіменному пакеті (інша назва - пакет за замовчуванням).

import-вирази дозволяють звертатися до типів з інших пакетів по їх простим іменах,

"Імпортувати" їх. Ці висловлювання також необов'язкові.

Нарешті, оголошення верхнього рівня містять оголошення одного або декількох типів.

Назва "верхнього рівня" протиставляє ці класи та інтерфейси, що розташовуються

в пакетах, внутрішнім типам, які є елементами і розташовуються всередині

інших типів. Як не дивно, але ця частина також є необов'язковою, в тому сенсі,

що компілятор не видасть помилки в разі її відсутності. Однак, ніяких. Class-файлів

Згенеровано теж не буде.

Доступність модулів компіляції визначається платформної підтримкою, тому що утиліти

Java є звичайними програмами, які виконуються операційною системою по

загальними правилами

Лекція 6. Оголошення класів