From local testing, it seems the problem is in JarMetadata#computeNameAndVersion, once the code has matched the potential version:

securejarhandler/src/main/java/cpw/mods/jarhandling/JarMetadata.java

Lines 104 to 112 in 8382e57

    
           var mat = DASH_VERSION.matcher(fn); 
        
           if (mat.find()) { 
        
               var potential = fn.substring(mat.start() + 1); 
        
               var ver = safeParseVersion(potential, path.getFileName().toString()); 
        
               var name = mat.replaceAll(""); 
        
               return new NameAndVersion(cleanModuleName(name), ver); 
        
           } else { 
        
               return new NameAndVersion(cleanModuleName(fn), null); 
        
           }

As you can see, the mat.replaceAll line removes the version as matched by the pattern (which may not include the full version), not the version as found and detected by safeParseVersion.

Changing the line to fn.replaceAll(ver, "") seems to fix this issue, and brings it more in line with the parsing code in ModulePath#deriveModuleDescriptor which removes from the module name the matched version and everything after it, although I am unsure what other effects it might have.

	var mat = DASH_VERSION.matcher(fn);
	if (mat.find()) {
	var potential = fn.substring(mat.start() + 1);
	var ver = safeParseVersion(potential, path.getFileName().toString());
	var name = mat.replaceAll("");
	return new NameAndVersion(cleanModuleName(name), ver);
	} else {
	return new NameAndVersion(cleanModuleName(fn), null);
	}

Automatic module name computation has weird behavior #77

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions