OberonCore

...
В спецификации JMS модуль представляется как «единица инкапсуляции» (encapsulation unit). Он разрабатывается как отдельная единица на языке, поддерживаемом платформой Java, а затем компилируется в отдельный модуль сборки, содержащий файлы классов, ресурсы и метаданные модуля.

В JMS также различаются определение модуля (module definition) и экземпляр модуля (module instance).

Определение модуля – это логическая единица, определяющая, какие классы и ресурсы содержит модуль, какие классы модуль экспортирует и какие импортирует. В общем смысле определение модуля – это и есть сам модуль: оно имеет номер версии, упаковывается в единый модуль сборки (deployment module).
....
Эти метаданные состоят из следующих элементов:

* Имя модуля (Name) – полное имя модуля. Задается по аналогии с именем пакетов в java и должно соответствовать Sections 6.2 и 6.7 JLS
* Версия (Version) – каждый модуль имеет версию. Версия указана в метаданных и является частью идентификации модуля. По-умолчанию модуль имеет версию «0.0.0.0-default»
* Члены (Members) – классы, входящие в состав модуля
* Экспортируемые элементы (Exports) – информация о тех классах, которые могут быть доступны остальным модулям. Это аналогично тому, что некоторые классы являются public, а остальные – private в контексте модулей
* Импортируемые модули – аналогично с импортом классов
....

* Версия (Version) – каждый модуль имеет версию. Версия указана в метаданных и является частью идентификации модуля. По-умолчанию модуль имеет версию «0.0.0.0-default»
* Члены (Members) – классы, входящие в состав модуля

в статье подробнее

модульность на мэйнстримовый лад?

Классы своей инкапсуляцией подрывают "авторитет" модулей

Вот, теперь, на описание преимуществ ББ многие будут отвечать - "Да ну, это есть в последней ЯВЕ!".