Новые ключевые слова в Java 9

Ответ 1

Ключевые слова, добавленные для объявлений модуля в Java 9, суммированы в §3.9 Спецификация языка Java, Java SE 9 Издание:

Еще десять символьных последовательностей - это ограниченные ключевые слова: open,   module, requires, transitive, exports, opens, to, uses,   provides и with. Эти последовательности символов обозначаются как   ключевых слов исключительно там, где они отображаются как терминалы в модуле.   и ProductionDirective (§7.7). Они обозначаются как   идентификаторы везде, для совместимости с написанными программами   до Java SE 9. Существует одно исключение: сразу справа   последовательности символов требуется в модуле ModuleDirective,   транзитная символьная последовательность обозначается как ключевое слово, если только   за которым следует разделитель, и в этом случае он обозначается как   Идентификатор.

Если у вас в настоящее время есть метод с именем module или любой другой ключевые слова, перечисленные здесь, будут продолжать компилироваться.

(view и permits были ключевыми словами в раннем прототипе Jigsaw, но они были упрощены из существования давно.)

Ответ 2

Скорее всего, это не полный список, и ничто из этого не было доработано, насколько мне известно, но я нашел несколько.

Мы также имеем module, exports, provides, uses, with, to и requires; объяснил здесь:

Система модулей могла идентифицировать использование сервисов путем сканирования файлов классов в артефактах модулей для вызовов методов ServiceLoader:: load, но это было бы медленным и ненадежным. То, что модуль использует определенную услугу, является фундаментальным аспектом определения этих модулей, поэтому для эффективности и ясности мы выражаем это в объявлении модулей с предложением uses:

module java.sql {
    requires public java.logging;
    requires public java.xml;
    exports java.sql;
    exports javax.sql;
    exports javax.transaction.xa;
    uses java.sql.Driver;
}

Система модулей может идентифицировать поставщиков услуг путем сканирования модулей артефактов для записей ресурсов META-INF/services, как это делает класс ServiceLoader. Тем не менее, модуль обеспечивает реализацию конкретной услуги, поэтому мы выражаем это в объявлении модулей с предложением предложения:

module com.mysql.jdbc {
    requires java.sql;
    requires org.slf4j;
    exports com.mysql.jdbc;
    provides java.sql.Driver with com.mysql.jdbc.Driver;
}

...

module java.base {
    ...
    exports sun.reflect to
        java.corba,
        java.logging,
        java.sql,
        java.sql.rowset,
        jdk.scripting.nashorn;
}

Также view и permits:

В больших программных системах часто бывает полезно определить несколько представлений одного и того же модуля. Один вид может быть объявлен для общего использования любым другим модулем, в то время как другой обеспечивает доступ к внутренним интерфейсам, предназначенным только для использования выбранным набором тесно связанных модулей.

Например, с JNDI мы хотим, чтобы com.sun.jndi.toolkit.url был видимым только для модулей cosnaming и kerberos, как указано в объявлении модуля.

view jdk.jndi.internal {
    exports com.sun.jndi.toolkit.url.*;
    exports sun.net.dns.*;
    permits jdk.cosnaming;
    permits jdk.kerberos;

}

Таким образом, мы можем более гибко определять границы модулей.

Я также слышал упоминание optional.

Ответ 3

модуль - это ключевое слово new, введенное для определения взаимозависимостей между пакетами. Почему нам нужны модули? Поскольку ранее

• инкапсуляция не была безупречной. С помощью отражения и с помощью подобных методов мы могли получить доступ даже к частному полю.
• Все классы во всех баночках были общедоступны.

• Если Classloader не получает класс, ему пришлось заглядывать во многие области и загружать множество связанных файлов, и даже после этого, если класс не найден, он будет запускать NoClassDefFoundErrors во время выполнения.

  Итак, по всем вышеперечисленным причинам нам нужен механизм, который позволяет JVM знать это во время выполнения. Для реализации модуля вам необходимо определить module-info.java. в этом пакете

      module com.exporter{
  
       exports com.a;
       provides com.b.M;
        with com.b.MImpl; }
  

В другом пакете

module com.consume {
    requires com.a;
}

Другие используемые атрибуты: " экспорт" и " требуется" для создания взаимозависимости (только транзитивная зависимость), " предоставляет" и " с" для отображения интерфейса и упоминания о реализации. Таким образом, это сильная инкапсуляция, возможно, поэтому java 9 более склонен к лучшей объектно-ориентированной функции.

Ответ 4

Для части обратной совместимости вопроса.

Я думаю, JAVA9/проект Jigsaw - это парадигма в Java-технологии. так что java9 не будет обратно совместимым, но вы можете легко преобразовать свою немодульную зависимость с модульной версией той же библиотеки. концепция "No-Pain, No-Gain" будет работать здесь. Каждый должен обновить/преобразовать, чтобы воспользоваться новой модульной Java. Разработчик IDE, разработчик плагинов, система сборки и, конечно же, разработчик Java-уровня groud для понимания новых java-систем.

JAVA9 выступает за чистую зависимость. он также обеспечивает совершенно новый способ защитить ваш код частными модулями. даже отражение не может получить доступ к модулям, которые не отображаются владельцем библиотеки /API.

Существует два подхода к использованию немодульных LIB/API.

• Подход "сверху вниз"
• Подход снизу вверх (много боли здесь для реализации)

второй подход делает очень чистую иерархию зависимостей модулей.