quarkusio/quarkus · error · IllegalArgumentException
You're not expected to use the unnamed module as identifier
Error message
You're not expected to use the unnamed module as identifier - please check the javadoc
What it means
ModuleEnableNativeAccessBuildItem requests JPMS native access for a named module. The unnamed module (the classpath, ModuleOpenBuildItem.ALL_UNNAMED) is not a valid identifier here — the javadoc restricts this item to named modules — so the constructor throws IllegalArgumentException when ALL_UNNAMED is passed. Assert also guarantees moduleName itself is non-empty.
Source
Thrown at core/deployment/src/main/java/io/quarkus/deployment/builditem/ModuleEnableNativeAccessBuildItem.java:28
* when generating a runnable Jar we can only generate an Enable-Native-Access entry in the Manifest
* for the modules normally identified by ALL-UNNAMED.
* This is considered acceptable at the time of writing as extensions are generally placed on the
* classpath for both fast-jar and uber-jar packaging formats. We expect this to evolve as further packaging
* formats are introduced which would better leverage the module system.
* We specifically don't allow enabling native access for "ALL-UNNAMED" explicitly while using this API to
* encourage using the module names that a library has or will have in the near future:
* for this reason, when a module name is provided which doesn't exist, we map it to the unnamed module.
* It is not possible to allow native code access to other modules via an agent, other approaches
* will need to be identified to reconfigure at runtime.
*/
public final class ModuleEnableNativeAccessBuildItem extends MultiBuildItem {
private final String moduleName;
public ModuleEnableNativeAccessBuildItem(final String moduleName) {
this.moduleName = Assert.checkNotEmptyParam("moduleName", moduleName);
if (ModuleOpenBuildItem.ALL_UNNAMED.equals(moduleName)) {
throw new IllegalArgumentException(
"You're not expected to use the unnamed module as identifier - please check the javadoc");
}
}
public String moduleName() {
return moduleName;
}
}
View on GitHub (pinned to e1c734241f)
Solutions
- Pass the actual named module, e.g. new ModuleEnableNativeAccessBuildItem("org.apache.commons.lang3"), matching the module-info name of the library.
- If the target code runs on the classpath (unnamed module), it already has no module restrictions for this purpose — remove the build item instead.
- If you need ALL-UNNAMED semantics, look at ModuleOpenBuildItem usage for opens where ALL_UNNAMED is valid as the opening module, and drop the native-access request.
Example fix
// before
buildProducer.produce(new ModuleEnableNativeAccessBuildItem(ModuleOpenBuildItem.ALL_UNNAMED));
// after
buildProducer.produce(new ModuleEnableNativeAccessBuildItem("org.graalvm.nativeimage")); Defensive patterns
Strategy: validation
Validate before calling
if (ModuleOpenBuildItem.ALL_UNNAMED.equals(moduleName)) {
throw new IllegalArgumentException("ModuleEnableNativeAccessBuildItem requires a named module, not ALL-UNNAMED");
}
produce(new ModuleEnableNativeAccessBuildItem(moduleName)); Type guard
boolean isValidNamedModule(String moduleName) {
return moduleName != null && !moduleName.isBlank() && !ModuleOpenBuildItem.ALL_UNNAMED.equals(moduleName);
} Try / catch
try {
produce(new ModuleEnableNativeAccessBuildItem(moduleName));
} catch (IllegalArgumentException e) {
if (e.getMessage().contains("unnamed module")) {
log.warnf("Skipping native-access request for unnamed module '%s'", moduleName);
return;
}
throw e;
} Prevention
- Only request native access for modules that actually have a module-info name
- Never use ALL_UNNAMED as a default for moduleName in config parsing
- Read the item's javadoc before building it programmatically
When it happens
Trigger: Constructing new ModuleEnableNativeAccessBuildItem(ModuleOpenBuildItem.ALL_UNNAMED) or new ModuleEnableNativeAccessBuildItem("ALL-UNNAMED"), i.e. passing the unnamed-module sentinel as moduleName.
Common situations: Extension code parameterizing module names from config and defaulting to ALL-UNNAMED; misunderstanding of the javadoc assuming the unnamed module can be targeted like with opens.
Related errors
- At least one package name must be specified
- Failed to redefine module ${moduleName}
- Failed to invoke implAddOpens
- Failed to open path tree with root %s
- Dev services for ${request.getName()} requires a startable s
AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05).
Data as JSON: /api/errors/4bc2cdb973e9a687.
Report an issue: GitHub.