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

Question

Одной из самых больших функций Java 9 будет модульная система, определенная Project Jigsaw. При чтении слайдов из Project Jigsaw: Under the Hood на JavaOne 2015, я заметил, следующий исходный код:

// src/java.sql/module-info.java 
module java.sql { 
    exports java.sql; 
    exports javax.sql; 
    exports javax.transaction.xa; 
} 

Что интересно здесь для меня в том, что файл заканчивается в .java и, кажется, использует два новых ключевые слова: module и exports. Какие другие ключевые слова будут представлены в Java 9? Как будет выполняться обратная совместимость (т. Е. Функции или переменные с именем module)?

Answer 1

Ключевые слова, добавленные для деклараций модулей в Java 9, суммированы в §3.9 из Java Language Specification, Java SE 9 Edition:

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

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

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

Answer 2

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

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

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

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.

Answer 3

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

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

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

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

1. Сверху вниз подход
2. снизу вверх подход (много боли здесь, чтобы реализовать)

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

Answer 4

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

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

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

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

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

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

module com.consume { 
    requires com.a; 
} 

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