Home > Software > Navigating “are in unnamed module of loader ‘app'” in Java: Insights and Solutions

Navigating “are in unnamed module of loader ‘app'” in Java: Insights and Solutions

Anastasios Antoniadis

Explore solutions for the “are in unnamed module of loader ‘app'” warning in Java, related to the module system and class loaders. This article demystifies the warning, explains its causes, and provides strategies for migrating to modules, adjusting reflective access, or assessing the need for action, ensuring your Java applications are up-to-date with modularization best practices.


As Java continues to evolve, developers may encounter new types of runtime errors and warnings, especially with the advent of the module system in Java 9. One such warning that might be confusing at first relates to the module system and class loaders. It usually appears as “classes are in unnamed module of loader ‘app’.” This message often pops up when reflecting on classes in a modular application, causing confusion about its cause and implications. This article aims to clarify this message, explain its underlying causes, and suggest practical solutions for related issues.

Understanding the Context

To grasp the essence of this warning, it’s essential to understand two key concepts introduced with Java’s module system: modules and class loaders.

Modules in Java

Modules were introduced in Java 9 as part of JEP 261 to enhance the scalability and maintainability of large applications. A module is essentially a named, self-describing collection of code and data. The module system allows for explicit declaration of dependencies, encapsulation of internal packages, and explicit exports of public APIs, thereby structuring the application more cleanly than a mere collection of JAR files.

Class Loaders

Class loaders, a foundational concept in Java, are responsible for dynamically loading classes at runtime. The JVM comes with several built-in class loaders, and developers can also define their own. In the context of the module system, class loaders play a crucial role in loading modules and managing their namespaces.

The Unnamed Module

Every class in a Java application belongs to some module. If a class does not belong to a named module, it’s part of the unnamed module. The unnamed module is a catch-all module that exists for backward compatibility with pre-Java 9 applications. It allows classes on the classpath (as opposed to the module path) to be treated as part of a module, albeit an unnamed one.

When the warning mentions that classes are in unnamed module of loader ‘app’, it indicates that the classes are loaded by the application class loader ('app') into the unnamed module. This situation typically arises when:

  1. Classes are placed on the classpath instead of the module path, making them part of the unnamed module by default.
  2. Reflection or dynamic class loading is used, and the classes involved are not part of any named module.

Resolving the Warning

Addressing this warning involves understanding its implications for your application and taking appropriate steps to mitigate any potential issues. Here are strategies to consider:

Migrating to Modules

The most forward-looking solution is to migrate your application to use modules, placing your classes on the module path instead of the classpath. This migration involves:

  1. Creating module descriptors (module-info.java) for your application’s components, explicitly declaring modules, their dependencies, and exported packages.
  2. Adjusting build and run configurations to use the module path (--module-path) instead of the classpath.

Reflective Access Adjustments

If the warning is a result of reflective operations on classes:

  • Ensure reflective access is necessary and correctly implemented: Review your use of reflection to ensure it’s needed and properly handles module boundaries.
  • Use opens directives in module-info.java: If your modules need to allow reflective access to their internals from other modules, use the opens directive in the module descriptor to open specific packages.

Assessing the Need for Action

In many cases, especially for smaller or non-modular applications, this warning may not have practical implications on the functionality of your application. If the warning does not lead to runtime errors or other issues, and if modularization does not align with your project’s goals or constraints, you might choose to acknowledge the warning without immediate action.


The warning about classes being in an unnamed module of loader ‘app’ in Java is rooted in the intricacies of the module system and class loading mechanisms. While it can initially seem daunting, understanding the context and implications allows developers to make informed decisions on addressing it. Whether through migrating to modules, adjusting reflective access, or deciding that immediate action is unnecessary, the key is to ensure that the approach aligns with your application’s architecture and long-term maintenance goals.

Anastasios Antoniadis
Follow me
0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments
Would love your thoughts, please comment.x