{"id":573921,"date":"2025-07-01T12:05:32","date_gmt":"2025-07-01T11:05:32","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=idea&p=573921"},"modified":"2025-07-01T13:12:13","modified_gmt":"2025-07-01T12:12:13","slug":"module-import-declarations-no-more-import-hell","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/en\/idea\/2025\/07\/module-import-declarations-no-more-import-hell","title":{"rendered":"Module Import Declarations: No More Import Hell\u00a0"},"content":{"rendered":"\n

Imagine you are proud of yourself for creating an amazing Java application, framework, or a library. You open one of its source files to make some changes and this is what you see:<\/p>\n\n\n\n

import java.lang.reflect.*;\nimport java.nio.file.Path;\nimport java.io.BufferedReader;\nimport java.io.InputStreamReader;\nimport java.util.ArrayList;\nimport java.util.List;\nimport java.util.stream.Collector;\nimport java.util.concurrent.CompletableFuture;\nimport java.util.concurrent.locks.ReadWiteLock;\nimport java.time.LocalDateTime;\n\/\/ more import statements<\/pre>\n\n\n\n
While looking at this long list of imports, are you wondering why you need to know the name of every single class or interface used in your class (apart from its configuration)? It seems like a cognitive load to me. Most of the developers I know collapse this section in their IDE and don\u2019t bother expanding it.<\/p>\n\n\n\n
The business logic in this source file probably starts after line twenty. Can you do something about it because importing packages won\u2019t help much. Don\u2019t worry, Module Import Declarations<\/a> can help address this import hell for you.<\/p>\n\n\n\n
What is \u2018Module Import Declarations\u2019?<\/h2>\n\n\n\n
Introduced as a preview feature in Java 23 and a production feature in Java 25, Module import declarations<\/a> enable you to import an entire module using a single import statement. In the above example, you can replace all the import statements with the following line of code, since all those packages are defined as part of the java.base<\/code> module:<\/p>\n\n\n\n
import module java.base.*;<\/pre>\n\n\n\n
Yes, just one line of code. The source file can now use List<\/code>, Map<\/code>, Stream<\/code>, Path<\/code>, and many more classes. As a developer, you no longer need to think about which package they live in. With this single statement, you can import all of the packages exported by the module java.base<\/code>.<\/p>\n\n\n\n
Why should you care about this feature?<\/h2>\n\n\n\n
Apart from the obvious benefits of concise code and escaping from the import hell, this feature helps us developers focus on solving business problems<\/i> rather than finding the fully qualified names for classes or interfaces to use. Do you think it is worth your time to find out whether the interface Function<\/code> is defined in the package java.util.function<\/code> or java.util<\/code>?. An intelligent IDE such as IntelliJ IDEA helps you to get around it by adding the relevant imports as soon as you use a type in your code (more about it in a later section in this blog post).<\/p>\n\n\n\n
It offers convenience<\/i> for new developers. Imagine you are a new Java developer. Would you prefer having an umbrella import statement so that you need not be bothered about knowing which package defines the commonly used data structures, such as List, Map, or Stream? If you are teaching Java, talking about importing classes interfaces from packages before folks get comfortable using basic data structures could make them lose focus. It would be better for them to get started writing programs that use List and Stream, rather than having them figure out which Java package defines them. Module import declarations help beginners focus on learning Java without getting confused or frustrated by things they don’t need to worry about yet.<\/p>\n\n\n\n
It enables faster prototyping<\/i>. When we are prototyping, we try to get things to work as quickly as possible. In such cases, an umbrella import statement, such as the import module declaration, lets us jump straight into coding. It also keeps the code concise, cleaner and easier to read when we are using large APIs. But this doesn\u2019t imply that you should define your code in a module to use a module import statement.<\/p>\n\n\n\n
Before moving forward, let\u2019s cover the IntelliJ IDEA configurations for using this feature.<\/p>\n\n\n\n
IntelliJ IDEA Configuration<\/h2>\n\n\n\n
Import Module declaration was introduced as a preview feature in Java 23 and IntelliJ IDEA has supported this feature since version 2024.3. In soon to be released Java 25, it becomes a production feature (it is now a permanent language feature, and safe to use in your production code). <\/p>\n\n\n\n
Java 25 is scheduled to be released in September 2025. To use this feature as a production feature (without needing the --enable-preview<\/code> flag during compilation and runtime), you should download the early access version of JDK. You can also do this from IntelliJ IDEA\u2019s settings dialog (Yes! IntelliJ IDEA allows you to download and configure EA versions of the JDK):<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
In your Project Settings, set the SDK to Java 25. For the language level, select \u2018X – Experimental features\u2019 on both the Project and Modules tabs. This enables you to use all Java 25 features, including those currently under review. Java 25 is due to be released in September 2025, and we at JetBrains are working on adding more support. New language options will be accessible in IntelliJ IDEA soon.<\/p>\n\n\n\n
More about Module Import Declarations<\/h2>\n\n\n\n
Knowing why we need a feature is the first step to using it. Let\u2019s look at how to use it and also answer some frequently asked questions from developers about this feature.<\/p>\n\n\n\n
Syntax of Module Import Declarations<\/h3>\n\n\n\n
The syntax is simple. It starts with the keyword import<\/code>, followed by module and the name of the module (without a wildcard, that is, *<\/code>):<\/p>\n\n\n\n
import module java.base.*;<\/pre>\n\n\n\n
This feature doesn\u2019t work with unnamed modules. Revisit the syntax of this feature: it requires you to name the module you want to import. The example in this section imports the java.base<\/code> module. <\/p>\n\n\n\n
How to determine the fully qualified name of types in your source code?<\/h3>\n\n\n\n
Are you wondering how to determine the fully qualified name of a type or variable in your source code when using import module declarations? This was one of the main reasons for using individual imports in source files. This applies to all types of imports, including wildcard and static imports.<\/p>\n\n\n\n
Move your cursor to the type in a variable declaration and use the Quick Documentation feature (Ctrl+Q for Win\/Linux, or F1 on macOS) to view a documentation popup that shows the package name at the top, followed by the name and its documentation\u2014without having to open another source file in your editor window. You can also use the Quick Definition feature (Ctrl+Shift+I) to view the fully qualified name, along with the definitions of its members, in a popup window. Alternatively, you can hover over the type using your mouse to view the fully qualified name.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
On a separate note, if you don\u2019t like showing Quick Documentation popups on mouse hover, you can clear the \u2018Show quick documentation on hover\u2019 checkbox in the settings (find it using Shift+Shift). If you want to browse the source code of the used type, use the \u2018Go to Declaration or Usages\u2019 feature (Ctrl+B \/ Cmd+B), which opens the source code in a new editor window.<\/p>\n\n\n\n
In the next section, let’s see how to use the import module statement with different libraries or APIs.<\/p>\n\n\n\n
How to import JUnit 3.8.1 using import module declaration?<\/h3>\n\n\n\n
I know it is an old version, but it is still around and in use. How would you import classes and interfaces defined in JUnit 3.8.1 (if you had to) in your source files? To import it using an import module declaration, you must use its module name. The short answer is you cannot because there is no module name for it. JUnit 3.8.1 was created before Java 9 introduced modules.<\/p>\n\n\n\n
What about other libraries? How do we find their module names? We usually use build tools, such as Maven, to import dependencies as jar files. If a dependency supports modules, its jar file includes module-info.class (mandatory for modules), which contains the module name. You\u2019ll notice that the JUnit 3.8.1 jar doesn\u2019t include module-info.class.<\/p>\n\n\n\n
IntelliJ IDEA users can view module info in External libraries<\/em>, in the Project Structure <\/em>window, as  shown below:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Of course, you could ask the AI Chat window in IntelliJ IDEA how to find these module names.<\/p>\n\n\n\n
Which packages are exported by the modules you import?<\/h3>\n\n\n\n
Each module defines a module-info.java file that includes information about the packages that module exports to all modules or to specific other modules. <\/p>\n\n\n\n
Let\u2019s try to understand this by checking out what happens when you import the module java.base<\/code> using IntelliJ IDEA. Click on the module name in the editor or use the relevant shortcut (Go to Declaration<\/em> or Usages<\/em>) and you could view the definition of this module to find out all the modules exported by this module. This is shown in the following gif:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
The public API in these packages are available to source files that import these modules.<\/p>\n\n\n\n
What do you mean by on-demand import?<\/h3>\n\n\n\n
Developers often argue about importing a single class or interface versus importing all public entities by importing a package using a wildcard character. Which of these do you think is better?<\/p>\n\n\n\n
When you import a module or a package using a wildcard (*), you import types on demand<\/em>. This means you can use any public class, interface, or entity from a package or module without importing each one individually.<\/p>\n\n\n\n
Often, developers ask if importing a full module increases the size of their .class files. The short answer is no. On-demand imports make all public classes and interfaces in the module available to use in a source file, but the compiler includes only those that are actually used in your code.<\/p>\n\n\n\n
Name conflicts (compilation error)<\/h3>\n\n\n\n
When you import one or more modules, it is possible that packages within the same module or across modules define classes with the same name. For an example, in the example code below, code at line number 5 (Date date;) won\u2019t compile because importing java.base<\/code> module makes java.util.Date<\/code> class available, and importing the java.sql module makes java.sql.Date available:<\/p>\n\n\n\n
1.\u00a0 \u00a0 import module java.base;\u00a0 \/\/ Makes available java.util.Date\n2.\u00a0 \u00a0 import module java.sql; \u00a0 \/\/ Makes available java.sql.Date\n3.\u00a0\n4.\u00a0 \u00a0 public class NameConflicts {\n5.\u00a0 \u00a0 \u00a0 \u00a0 Date date;\u00a0 \/\/ compilation error\n6.\u00a0 \u00a0 }<\/pre>\n\n\n\n
Let\u2019s assume you want to use the Date class from module java.sql<\/em>. To address this issue, you could either add a single import statement, as follows:<\/p>\n\n\n\n
1.\u00a0 \u00a0 import module java.base;\u00a0 \/\/ Makes available java.util.Date\n2.\u00a0 \u00a0 import module java.sql; \u00a0 \/\/ Makes available java.sql.Date\n3.\u00a0 \u00a0 import java.sql.Date;\n4.\u00a0\u00a0\u00a0\u00a0\n5.\u00a0 \u00a0 public class NameConflicts {\n6.\u00a0 \u00a0 \u00a0 \u00a0 Date date;\u00a0\u00a0\n7.\u00a0 \u00a0 }<\/pre>\n\n\n\n
You could also resolve it by using a fully qualified class name, as follows:<\/p>\n\n\n\n
1.\u00a0 \u00a0 import module java.base;\u00a0 \/\/ Makes available java.util.Date\n2.\u00a0 \u00a0 import module java.sql; \u00a0 \/\/ Makes available java.sql.Date\n3.\u00a0\n4.\u00a0 \u00a0 public class NameConflicts {\n5.\u00a0 \u00a0 \u00a0 \u00a0 java.sql.Date date;\u00a0\u00a0\n6.\u00a0 \u00a0 }<\/pre>\n\n\n\n
IntelliJ IDEA can highlight name conflicts as you type your code. Invoke context actions to view a list of qualified class names (package name + class name) to choose from, as shown below:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
If you are wondering whether it is a good idea to import modules since it could lead to namespace conflicts, these issues can occur with importing packages too. Don\u2019t worry; it results in a compilation error and can be fixed easily.<\/p>\n\n\n\n
Also, a module and one of the packages it includes can have the same name. Notice that the module java.sql contains a package java.sql. The fully qualified name of a class or an interface includes its package name, not the name of the module the package is defined in.<\/p>\n\n\n\n
Compact Source Files integration<\/h3>\n\n\n\n
Gavin Bierman mentioned that the idea of this Import Module Declarations came up while the Java team was working on JEP Compact Source Files and Instance main Methods<\/a>, which aim to reduce the ceremony to learning Java. <\/p>\n\n\n\n
Compact source files implicitly import the module java.base<\/code>. It implies that the new developers can use any public class or interface from the multiple packages exported by the java.base module, without explicit import statements.<\/p>\n\n\n\n
JShell Integration<\/h3>\n\n\n\n
One of the main benefits of using JShell is that it allows you to quickly evaluate expressions, execute code statements or snippets (and much more) without the ceremony of defining classes.<\/p>\n\n\n\n
Prior to Import Module Declarations, JShell automatically imported the ten most used packages (and java.lang) so that developers could easily use those classes or interfaces without explicit import statements. However, you still need import statements for classes or interfaces not defined in these packages, such as the LocalDateTime<\/code> class from the package java.time<\/code>:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
With import module declarations, JShell automatically imports the module java.base. This helps developers use many more classes (such as LocalDateTime<\/code>), without needing explicit import statement, as shown in the following image:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
One import statement to use the entire standard Java API<\/h3>\n\n\n\n
By importing the java.se module you can use the entire standard Java API in your source file. Here\u2019s the module information for this module:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
The java.se module is an aggregator module. It does not export any package, but requires other modules transitively. In other words, source files importing java.se import the packages exported by modules that are marked required transitive in java.se<\/a>.<\/p>\n\n\n\n
Interview with creators of this feature<\/h3>\n\n\n\n
We also interviewed<\/a> the owner of this feature, Gavin Bierman<\/a>, Programming Language Designer at Oracle.<\/p>\n\n\n\n
\n