The Java platform has a couple of aggregator modules to represent the complete JRE, at least as we knew it in Java 8 and earlier. The java.se module essentially re-exports the entire Java SE platform. The java.se.ee module contains the subset of the platform that overlaps with Java EE and contains APIs such as web services, transactions, and the legacy CORBA APIs.

Running java -d on the java.se module shows us how it's implemented:

$ java -d java.se
  java.se@9
  requires java.scripting transitive
  requires java.xml transitive
  requires java.management.rmi transitive
  requires java.logging transitive
  requires java.sql transitive
  requires java.base mandated
  ...

Again, I hope you resist the temptation to use these aggregator modules in any new modules you create in your Java 9 code. You could practically throw in requires java.se in all your module definitions and not have to worry about doing any other requires ever again! But that again defeats the purpose of modularity and you are back to using the Java platform the way we did in Java 8 and earlier--by depending on the entirety of the platform APIs irrespective of what part of them you really need. These aggregator modules are mainly to be used for legacy code migration purposes, and that too as a temporary measure, in an attempt to get to more fine-grained dependencies eventually.

Although the java.se.ee module is deprecated and is not encouraged for use, there's an interesting observation to be made by examining it. While java.se.ee is a super set that includes all modules in java.se and then some more, its module definition doesn't re-declare a entire list of all the modules in the platform. What it does is simply require transitive the java.se module:

$ java -d java.se.ee
  java.se.ee@9
  requires java.corba transitive
  requires java.base mandated
  ...
  requires java.se transitive

You can use this approach in your own modules to create aggregator modules of other aggregator modules! Pretty powerful stuff!