В книге, которую я читаю для квалификации SCJP, есть утверждение, в ней говорится:
Файлы без открытых классов не имеют ограничения имен
Это заставило меня спросить: , почему бы вам это сделать?
Если нет открытых классов, то как другие классы могли импортировать и использовать файл? Единственная цель, которую я вижу, - это если файл работает автономно сам по себе, что также может быть нечетным, например, иметь все приложение в одном файле
Это справедливо для классов package-private. И вы можете использовать классы private-private в одном пакете. (И в этом случае вам не нужно импортировать его, потому что он в том же пакете.)
Например, класс JapaneseImperialCalendar является закрытым пакетом, потому что он используется только из Calendar.createCalendar(..) - он не является частью общедоступного API. Вы не можете напрямую создавать японский календарь, но вы все равно можете использовать его по своему интерфейсу. То же самое касается всех немодифицируемых коллекций, которые получены с помощью таких методов, как Collections.unmodifiableList(..) - они являются частями пакета.
Таким образом, файл .java JapaneseImperialCalendar мог быть произвольным. Тем не менее, рекомендуется не отклоняться от установленной практики именования даже пакетов-частных файлов после имени класса.
Вы можете создать файл с именем package-info.java, который содержит только оператор package. Инструмент javadoc 1.5+ рассматривает комментарий javadoc для этого оператора пакета точно так же, как и файл package.html. Кроме того, вы можете добавлять аннотации на уровне пакетов, такие как @Generated к этому утверждению, чего вы не можете сделать в package.html.
Поскольку package-info не является допустимым идентификатором Java, нет никакого риска, что этот файл столкнулся бы с существующим Java-классом (то есть обратная совместимость).
Из Java Classes вы имеете общедоступные классы и классы пакетов. Классы классов считаются "private", поэтому вы можете использовать их только в самом пакете. Это значение по умолчанию, то есть публикация не указана.
Публичные классы - это, конечно же, классы, которые можно создавать где угодно.
Хотя я очень поздно отвечаю на вопрос, но это, безусловно, поможет. Если я не ошибаюсь, ваш конкретный вопрос сводится к следующему: каково значение класса, объявленного без без явного модификатора?
Посмотрите на этот класс, присутствующий в пакете java.util -
class JumboEnumSet<E extends Enum<E>> extends EnumSet<E>
Также смотрите в том же пакете -
class RegularEnumSet<E extends Enum<E>> extends EnumSet<E>
Вы видите, что оба из них объявлены с помощью без явного модификатора. Вы задавались вопросом, почему ограничение пакетное? Здесь причина из удивительной книги Эффективное Java 2nd Edition от Джошуа Блоха # Item1
Класс java.util.EnumSet(элемент 32), введенный в выпуске 1.5, нет общественных конструкторов, только статических фабрик. Они возвращают одну из двух реализаций, в зависимости от размера базового типа перечисления: если у него шестьдесят четыре или меньше элементов, большинство типов перечислений, статические фабрики возвращают RegularEnumSet экземпляр, который поддерживается один длинный; если тип перечисления имеет шестьдесят пять или более элементов, фабрики возвращают экземпляр JumboEnumSet, поддерживаемый длинным массив.
Двигайтесь быстро, добавляет он далее -
Существование этих двух классов реализации невидимо для клиентов. Если RegularEnumSet перестает предлагать преимущества производительности для небольшие типы перечислений, он может быть исключен из будущего выпуска без плохие последствия. Аналогичным образом, в следующем выпуске можно добавить третий или четвертый внедрение EnumSet, если оно окажется полезным для производительности. Клиенты не знают и не заботятся о классе объекта, который они получают назад из factory; они заботятся только о том, что это некоторый подкласс EnumSet.
Я не согласен с не-ограничением. Каждый java файл должен содержать только один класс верхнего уровня, а имя файла должно совпадать с именем класса, открытым или нет. Я не думаю, что Джавак хотел бы этого очень (или любого человека)
A.java
class B
B.java
class A
http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.3
7.2 Поддержка хостов для пакетов
Каждый хост определяет, как пакеты, единицы компиляции и подпакеты создан и сохранен, и единицы компиляции наблюдаются (§7.3) в конкретной компиляции.
7.2.1 Хранение пакетов в файловой системе
В качестве чрезвычайно простого примера,
http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html
оба файла источника и класса должны иметь имена корней, которые идентифицируют класс. Например, класс MyClass будет записана в исходном файле MyClass.java и скомпилирован в файл класса байт-кода, называемый MyClass.class.