Speaking of naming conventions, you might have noticed the different prefixes to the module names when you ran the java --list-modules command. The three prefixes to the platform modules are--java., javafx., and jdk.. The prefix indicates the nature of the module:

• java: Indicates the core Java platform module. These are what's referred to in the official documentation as standard modules.
• javafx: Indicates modules of Java FX, the platform for building desktop applications in Java.
• jdk: Indicates core JDK modules. These are not part of the language specification, but contain valuable APIs and tools for the Java developer, including the jdk.compiler and jdk.javadoc, as well as debugging and serviceability tools and APIs such as jdk.jdi and jdk.jconsole.
• oracle: If you've downloaded the Oracle Open JDK, you might see a couple of modules beginning with this prefix. Remember that these are non-standard modules that are specific to this flavor of the JDK implementation and they will not be available in other implementations. For this reason, it's a good idea to completely ignore these modules.

The java. prefixed modules themselves can be classified into three categories:

• Core Java modules: These are necessary for the Core Java functionality. Modules such as java.base, java.xml, and so on, which are APIs usually referred to as Core Java SE APIs. This is in contrast to Enterprise APIs, the next category.

• Enterprise modules: This category contains modules such as java.corba that contains APIs leveraging CORBA technology and java.transaction, which provide database transaction APIs usually required in an Enterprise application context. Note that this is different from Java EE, which is the completely different spec. However, there has always been a small overlap between what got bundled with the Java SE and Java EE SDKs. To avoid this overlap, as of Java 9, these Enterprise modules have been marked as deprecated and might be removed in a future Java version.
• Aggregator modules: These are modules that do not contain any APIs by themselves, but instead act as a convenient way to bundle multiple modules together. Specifying a requires dependency on the aggregator module is equivalent to individually specifying the requires dependency on all the individual modules that the aggregator module aggregates. You'll learn how to build your own custom aggregator modules in Chapter 6, Module Resolution, Accessibility, and Readability. For now, note that there are a couple of aggregator modules that come bundled with the platform. They are:
  • java.se: This is a convenient aggregator module that gathers all the standard Java SE modules together.
  • java.se.ee: This aggregator module gathers all the java.se modules and adds in the APIs that overlap with the Java EE specification.

While aggregator modules provide a level of convenience, I'd recommend using them with care. When writing a Java application, it can be tempting to just require the java.se module, for instance, to pull down the entire Java SE platform. That way, you don't have to bother with identifying which platform modules contain the APIs you want and thus need to import. With just one line--requires java.se, you have the whole platform at your disposal. But then, you are losing several advantages of the modularization of the platform. You then end up with a bulky Java platform with unnecessary classes, no different from Java 8 and earlier. The aggregator modules are provided for convenience to be used only when necessary. So, make sure you use them right.