Что такое модуль в java

13.7. Java – Метод Math.abs()

Метод Math.abs() – дает абсолютное значение аргумента, простыми словами – мы получаем модуль числа. Аргумент может быть int, float, long, double, short, byte.

Синтаксис

Варианты метода приведены ниже:

double abs(double d) float abs(float f) int abs(int i) long abs(long lng)

Параметры

Подробная информация о параметрах:

Любой примитивный тип данных.

Возвращаемое значение

В Java Math.abs() возвращает абсолютное значение аргумента (модуль числа).

Пример

public class Test < public static void main(String args[])< Integer a = -8; double d = -100; float f = -90; System.out.println(Math.abs(a)); System.out.println(Math.abs(d)); System.out.println(Math.abs(f)); >>

Получим следующий результат:

8 100.0 90.0

1. Java – Самоучитель для начинающих
2. Java – Обзор языка
3. Java – Установка и настройка
4. Java – Синтаксис
5. Java – Классы и объекты
6. Java – Конструкторы
7. Java – Типы данных и литералы
8. Java – Типы переменных
9. Java – Модификаторы
10. Java – Операторы
11. Java – Циклы и операторы цикла
11.1. Java – Цикл while
11.2. Java – Цикл for
11.3. Java – Улучшенный цикл for
11.4. Java – Цикл do..while
11.5. Java – Оператор break
11.6. Java – Оператор continue
12. Java – Операторы принятия решений
12.1. Java – Оператор if
12.2. Java – Оператор if..else
12.3. Java – Вложенный оператор if
12.4. Java – Оператор switch..case
12.5. Java – Условный оператор (? 🙂
13. Java – Числа
13.1. Java – Методы byteValue(), shortValue(), intValue(), longValue(), floatValue(), doubleValue()
13.2. Java – Метод compareTo()
13.3. Java – Метод equals()
13.4. Java – Метод valueOf()
13.5. Java – Метод toString()
13.6. Java – Метод parseInt()
13.7. Java – Метод Math.abs()
13.8. Java – Метод Math.ceil()
13.9. Java – Метод Math.floor()
13.10. Java – Метод Math.rint()
13.11. Java – Метод Math.round()
13.12. Java – Метод Math.min()
13.13. Java – Метод Math.max()
13.14. Java – Метод Math.exp()
13.15. Java – Метод Math.log()
13.16. Java – Метод Math.pow()
13.17. Java – Метод Math.sqrt()
13.18. Java – Метод Math.sin()
13.19. Java – Метод Math.cos()
13.20. Java – Метод Math.tan()
13.21. Java – Метод Math.asin()
13.22. Java – Метод Math.acos()
13.23. Java – Метод Math.atan()
13.24. Java – Метод Math.atan2()
13.25. Java – Метод Math.toDegrees()
13.26. Java – Метод Math.toRadians()
13.27. Java – Метод Math.random()
14. Java – Символы
14.1. Java – Метод Character.isLetter()
14.2. Java – Метод Character.isDigit()
14.3. Java – Метод Character.isWhitespace()
14.4. Java – Метод Character.isUpperCase()
14.5. Java – Метод Character.isLowerCase()
14.6. Java – Метод Character.toUpperCase()
14.7. Java – Метод Character.toLowerCase()
14.8. Java – Метод Character.toString()
15. Java – Строки
15.1. Java – Метод charAt()
15.2. Java – Метод compareTo()
15.3. Java – Метод compareToIgnoreCase()
15.4. Java – Метод concat()
15.5. Java – Метод contentEquals()
15.6. Java – Метод copyValueOf()
15.7. Java – Метод endsWith()
15.8. Java – Метод equals()
15.9. Java – Метод equalsIgnoreCase()
15.10. Java – Метод getBytes()
15.11. Java – Метод getChars()
15.12. Java – Метод hashCode()
15.13. Java – Метод indexOf()
15.14. Java – Метод intern()
15.15. Java – Метод lastIndexOf()
15.16. Java – Метод length()
15.17. Java – Метод matches()
15.18. Java – Метод regionMatches()
15.19. Java – Метод replace()
15.20. Java – Метод replaceAll()
15.21. Java – Метод replaceFirst()
15.22. Java – Метод split()
15.23. Java – Метод startsWith()
15.24. Java – Метод subSequence()
15.25. Java – Метод substring()
15.26. Java – Метод toCharArray()
15.27. Java – Метод toLowerCase()
15.28. Java – Метод toString()
15.29. Java – Метод toUpperCase()
15.30. Java – Метод trim()
15.31. Java – Метод valueOf()
15.32. Java – Классы StringBuilder и StringBuffer
15.32.1. Java – Метод append()
15.32.2. Java – Метод reverse()
15.32.3. Java – Метод delete()
15.32.4. Java – Метод insert()
15.32.5. Java – Метод replace()
16. Java – Массивы
17. Java – Дата и время
18. Java – Регулярные выражения
19. Java – Методы
20. Java – Потоки ввода/вывода, файлы и каталоги
20.1. Java – Класс ByteArrayInputStream
20.2. Java – Класс DataInputStream
20.3. Java – Класс ByteArrayOutputStream
20.4. Java – Класс DataOutputStream
20.5. Java – Класс File
20.6. Java – Класс FileReader
20.7. Java – Класс FileWriter
21. Java – Исключения
21.1. Java – Встроенные исключения
22. Java – Вложенные и внутренние классы
23. Java – Наследование
24. Java – Переопределение
25. Java – Полиморфизм
26. Java – Абстракция
27. Java – Инкапсуляция
28. Java – Интерфейсы
29. Java – Пакеты
30. Java – Структуры данных
30.1. Java – Интерфейс Enumeration
30.2. Java – Класс BitSet
30.3. Java – Класс Vector
30.4. Java – Класс Stack
30.5. Java – Класс Dictionary
30.6. Java – Класс Hashtable
30.7. Java – Класс Properties
31. Java – Коллекции
31.1. Java – Интерфейс Collection
31.2. Java – Интерфейс List
31.3. Java – Интерфейс Set
31.4. Java – Интерфейс SortedSet
31.5. Java – Интерфейс Map
31.6. Java – Интерфейс Map.Entry
31.7. Java – Интерфейс SortedMap
31.8. Java – Класс LinkedList
31.9. Java – Класс ArrayList
31.10. Java – Класс HashSet
31.11. Java – Класс LinkedHashSet
31.12. Java – Класс TreeSet
31.13. Java – Класс HashMap
31.14. Java – Класс TreeMap
31.15. Java – Класс WeakHashMap
31.16. Java – Класс LinkedHashMap
31.17. Java – Класс IdentityHashMap
31.18. Java – Алгоритмы Collection
31.19. Java – Iterator и ListIterator
31.20. Java – Comparator
32. Java – Дженерики
33. Java – Сериализация
34. Java – Сеть
34.1. Java – Обработка URL
35. Java – Отправка Email
36. Java – Многопоточность
36.1. Java – Синхронизация потоков
36.2. Java – Межпоточная связь
36.3. Java – Взаимная блокировка потоков
36.4. Java – Управление потоками
37. Java – Основы работы с апплетами
38. Java – Javadoc

Общие сведения о модулях Java | Java для начинающих

Главный инженер программного обеспечения Майкрософт для Java и чемпион Java Кирк Пеппедин представляет нам модули Java, функцию в Java 9 и более познакомит с ней. Модуль Java — это набор пакетов и определенных типов Java, включая классы, интерфейсы и многое другое, упакованные с файлами данных и статическими ресурсами.

Модульность

С выходом JDK 9 в языке Java появилась новая возможность — модульность. Модульность позволяет разбить код на отдельные структурные единицы — модули. Фактически модуль представляет группу пакетов или ресурсов, объединенных в одно целое и к которым можно обращаться по имени модуля.

До Java 9 было несколько уровней инкапсуляции функционала. Первый уровень представлял класс, в котором мы могли определить переменные и методы с различным уровнем доступа. Следующий уровень представлял пакет, который, в свою очередь, представлял коллекцию классов. Однако со временем этих уровней оказалось недостаточно. И модуль стал следующим уровнем инкапсуляции, который объединял несколько пакетов.

Модуль состоит из группы пакетов. Также модуль включает список все пакетов, которые входят в модуль, и список всех модулей, от которых зависит данный модуль. Дополнительно (но необязательно) он может включать файлы ресурсов или файлы нативных библиотек.

В качестве названия модуля может использоваться произвольный идентификатор из алфавитно-цифровых символов и знаков подчеркивания. Но рекомендуется, чтобы название модуля соответствовало названию, которого начинаются пакеты этого модуля.

Определим и используем простейший модуль. Допустим, файлы с исходными кодами помещаются в папку C:\java (либо какую-нибудь другую папку на жестком диске). Создадим в этой папке каталог, который назовем demo . Этот каталог будет представлять модуль.

В каталоге demo определим новый файл module-info.java со следующим кодом:

module demo

Этот файл представляет дескриптор модуля (module descriptor). Этот файл может содержать только определение модуля.

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

Далее в каталоге demo создадим папку com . В папке com создадим папку metanit , а в папке com/metanit — папку hello .

В папке com/metanit/hello определим новый файл Hello.java :

package com.metanit.hello; public class Hello < public static void main(String[] args)< System.out.println("Hello Demo Module!"); >>

Название пакета файла — com.metanit.hello отражает структуру папок, в которых расположен файл. Сам файл определяет класс Hello, который в методе main выводит на консоль строку.

В итоге у нас получится следующая стуктура проекта:

Теперь скомпилируем все это. Для этого вначале перейдем в командной строке/терминале к папке, в которой находится модуль demo.

Затем для компиляции модуля выполним следующую команду:

javac demo/module-info.java demo/com/metanit/hello/Hello.java

После компиляции модуля demo выполним программу с помощью следующей команды:

java --module-path demo --module demo/com.metanit.hello.Hello

Параметр —module-path указывает на путь к модулю, а —module — на главный класс модуля.

При наборе команды вместо параметра —module-path можно указать его сокращение -p , а вместо параметра —module — сокращение -m .

И на консоли отобразится сообщение «Hello Demo Module!»

Модульность в Java 9

Основным нововведением Java 9 было именно введение модульности. Про эту фичу было много разговоров, дата релиза несколько раз переносилась, чтобы допилить все должным образом. В этом посте речь пойдет о том, что дает механизм модулей, и чего полезного Java 9 принесла в целом. Основой для поста послужил доклад моего коллеги — Сергея Малькевича.

Читать:

Как создать бд в oracle sql developer

Для реализации модулей в этой версии Java был выделен целый проект — Project Jigsaw — который включает в себя несколько JEP и JSR.

Для любителей официальной документации, ознакомиться более подробно с каждым JEP можно здесь.

Подробнее о Project Jigsaw

Project Jigsaw, который реализует модульность, начал разрабатываться в далеком 2005: сначала вышел JSR 277, а уже в 2008 началась непосредственная работа над проектом. Релиз состоялся только в 2017 году. То есть, для того, чтобы докрутить модули в Java, понадобилось почти 10 лет. Что, собственно, подчеркивает весь масштаб работы и изменений, которые были внесены в ходе реализации модульности.

Какие цели ставили перед собой разработчики:

облегчить разработку больших приложений и библиотек;
улучшить безопасность Java SE в целом, и JDK в частности;
увеличить производительность приложений;
создать возможность уменьшения размера JRE для запуска на небольших девайсах, чтобы не потреблять слишком много памяти;
JAR HELL (об этом чуть позже).

Чего полезного принесла Java 9

До 9 версии, JDK и JRE были монолитными. Их размер рос с каждым релизом. Java 8 занимала уже сотни мегабайт, и все это разработчикам приходилось “таскать с собой” каждый раз, чтобы иметь возможность запускать Java приложения. Один только rt.jar весит порядка 60 Mb. Ну и сюда еще добавляем медленный старт и высокое потребление памяти. Тут на помощь пришла Java 9.

В JDK 9 было введено разделение на модули, а именно, JDK была разделена на 73 модуля. И с каждой новой версией количество этих модулей растет. В 11 версии это число близится к 100. Это разделение позволило разработчикам создать утилиту JLINK. С помощью JLINK можно создавать кастомные наборы JRE, которые будут включают только «нужные» модули, которые реально необходимы вашему приложению. Таким образом, простое приложение и какой-либо customJRE с минимальным (или небольшим) набором модулей в итоге может уместиться в 20 Mb, что не может не радовать.

Список модулей можно посмотреть здесь.

С приходом Java 9 поменялась структура JDK: теперь она идентична структуре JRE. Если раньше JDK включала папку JRE, где снова имеется bin и дублируются файлы, то теперь все выглядит следующим образом:

Модули

Собственно. что такое модуль? Модуль — это новый уровень агрегации пакетов и ресурсов (ориг. “a uniquely named, reusable group of related packages, as well as resources and a module descriptor”).

Модули поставляются в JAR файлах с пакетами и дескриптором модуля
module-info.java. Файл module-info.java содержит описание модуля:
имя, зависимости, экспортируемые пакеты, потребляемые и предоставляемые сервисы, разрешения для reflection доступа.

Примеры описания дескриптора модуля:

module java.sql

module jdk.javadoc

После ключевого слова module у нас идет имя пакета jdk.javadoc, который зависит от другого пакета java.xml и транзитивно зависит от других пакетов.

Давайте подробнее пройдемся по каждому из ключевых слов:

requires указывает модули, от которых зависит текущий модуль;

requires transitive — транзитивная зависимость — означает следующее: если модуль m1 транзитивно зависит от модуля m2, и мы имеем какой-то третий модуль mX, который зависит от m1 — модуль mX будет иметь доступ также и к m2;

requires static позволяет указать compile-time зависимости;

exports указывает пакеты, которые экспортирует текущий модуль (не включая “подпакеты”);

exports. to… позволяет ограничить доступ: export com.my.package.name to com.specific.package; то есть можно открыть доступ к пакету нашего модуля только для какого-то другого(их) пакета(ов) другого модуля;

uses java.sql.Driver;

provides javax.tools.Tool with jdk.javadoc.internal.api.JavadocTool;

Допустим, у нас подключено несколько модулей, которые реализуют абстрактный сервис — MyService. При сборке приложения у нас есть возможность решить, какую реализацию сервиса использовать, “перетащив” нужные нам модули реализации сервиса на —module-path:

Iterable services = ServiceLoader.load(MyService.class);

Таким образом, возвращенный Iterator содержит список реализаций интерфейса MyService. Фактически, он будет содержать все реализации, найденные в модулях, найденных на —module-path.

Зачем в принципе были введены сервисы? Они нужны для того, чтобы показать, как наш код будет использован. То есть, здесь заключена семантическая роль. Также, модульность — это про инкапсуляцию и безопасность, так как мы можем сделать реализацию private и исключить возможность несанкционированного доступа через reflection.

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

Вернемся к синтаксису описания модулей:

До 9ки через reflection мы имели доступ практически ко всему и могли делать все, что хотим и с чем хотим. А 9-ая версия, как уже упоминалось, позволяет обезопасить себя от “нелегального” reflection доступа.

Мы можем полностью открыть модуль для reflection доступа, объявив open:

open module my.module

Либо, мы можем указать какие либо пакеты для reflection доступа, объявив opens:

module my.module

Здесь же есть возможность использовать opens com.my.coolpackage to…, таким образом предоставляя reflection доступ пакету com.my.coolpackage из пакета, который укажем после to.

Типы модулей

Project Jigsaw классифицирует модули следующим образом:

System Modules — Java SE и JDK модули. Полный список можно посмотреть, используя команду java —list-modules.

Application Modules — модули нашего приложения, которые мы написали, а также те зависимости (от сторонних библиотек), которые использует наше приложение.

Automatic Modules — это модули с открытым доступом, создаваемые Java автоматически из JAR-файлов. Допустим, мы хотим запустить наше приложение в модульном режиме, но оно использует какую-то библиотеку. В этом случае мы помещаем JAR-файл на —module-path и Java автоматически создает модуль с именем, унаследованным от имени JAR-файла.

Unnamed Module — безымянный модуль, автоматически создаваемый из всех JAR-файлов, которые загружены на —class-path. Это универсальный модуль для обеспечения обратной совместимости с ранее написанным Java кодом.

Class-path vs module-path

С появлением модулей появилось новое понятие — module-path. По сути, это тот же class-path, но для модулей.

Запуск модульного приложения выглядит следующим образом:

В обычном режиме запуска мы указываем опции и полный путь к мейн классу. В случае, если мы хотим работать с модулями, мы также указываем опции и параметр -m либо -module, который как раз указывает на то, что мы будем запускать модули. То есть, мы автоматически переводим наше приложение в модульный режим. Далее мы указываем имя модуля и путь к мейн классу из модуля.

Также, если в обычном режиме мы привыкли работать с параметром -cp и —class-path, в режиме модульности мы прописываем новый параметр -p и —module-path, который указывает пути к используемым в приложении модулям.

Часто встречаюсь с тем, что разработчики не переходят на версии 9+, так как считают, что им придется работать с модулями. Хотя на самом деле, мы можем запускать наши приложения в старом режиме, попросту не прописывая параметр и не используя модули, а используя только другие новые фишки.

JAR HELL

Хочу также по диагонали остановится на проблеме Jar Hell.

Что такое Jar Hell в двух словах? Например, у нас есть какое-то наше приложение и оно зависит от библиотеки X и библиотеки Y. При этом, обе эти библиотеки зависят от библиотеки Z, но от разных версий: X зависит от версии 1, Y — от версии 2. Хорошо, если версия 2 обратно совместима с версией 1, тогда никаких проблем не возникнет. А если нет — очевидно, что мы получаем конфликт версий, то есть одна и та же библиотека не может быть загружена в память одним и тем же загрузчиком классов.

Как в этом случае выходят из ситуации? Есть стандартные методы, которые разработчики используют со времен самой первой Java, например, exclude, кто-то использует плагины для Maven, которые переименовывают названия корневых пакетов библиотеки. Либо же, разработчики ищут разные версии библиотеки X, чтобы подобрать совместимый вариант.

К чему это я: первые прототипы Jigsaw подразумевали наличие версии у модуля и позволяли загрузку нескольких версий через разные ClassLoader’ы, но позже от это отказались. В итоге, “серебряной пули”, которую многие ждали, не вышло.

Но, “прямо-из-коробки” нас немного обезопасили от подобных проблем. В Java 9 запрещены Split Packages — пакеты, которые разделены на несколько модулей. То есть, если у нас есть пакет com.my.coolpackage в одном модуле, мы не можем его использовать в другом модуле в рамках одного приложения. При запуске приложения с модулями, содержащими одинаковые пакеты, мы просто упадем. Это небольшое улучшение исключает возможность непредсказуемого поведения в связи с загрузкой Split пакетов.

Также, помимо самих модулей, есть еще механизм слоев или Jigsaw Layers, который также помогает справится с проблемой Jar Hell.

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

Выглядит это следующим образом:

При старте приложения создается слой boot, куда входят модули платформы, загружаемые Bootstrap, добавочные модули платформы, загружаемые платформенным загрузчиком и модули нашего приложения, загружаемые Application загрузчиком.

В любой момент, мы можем создать свои слои и “положить” туда модули разных версий и при этом не упасть.

Есть отличный подробный доклад на YouTube на эту тему: Спасение от Jar Hell с помощью Jigsaw Layers

Заключение

Механизм модулей из Java 9 открывает нам новые возможности, при этом поддержка библиотек на сегодняшний день довольно небольшая. Да, люди запускают Spring, Spring Boot и так далее. Но большинство библиотек так и не перешло на полное использование модулей. Видимо поэтому, все эти изменения были восприняты довольно скептически техничесим сообществом. Модули предоставляют нам новые возможности, но вопрос востребованности остаётся открытым.

Ну и напоследок, предлагаю подборку материалов на эту тему: