I stumbled upon the same issue; maybe we can, at the same time, avoid using hardcoded "version" in the expected String, e.g.?

 @Test
    void findWebJarResourcePath() {
        String path = "swagger-ui/swagger-initializer.js";

        String actual = abstractSwaggerResourceResolver.findWebJarResourcePath(path);
        String[] pathNames = {"swagger-ui", VERSION, "swagger-initializer.js"};
        String expected = String.join(File.separator, pathNames);

        assertEquals(expected, actual);
    }

Yeah...I knew I could go a little bit fancier using Paths.get (more semantics), but since I was lazy so I just fixed it using the same way of how actual was constructed. Quick change, all test passed, and I called it a day.

Now since you mentioned it, instead of using String.join, the assertion can be like:

assertEquals(Paths.get("swagger-ui" ,"4.18.2" ,"swagger-initializer.js").toString(), actual);

Additionally, I went back to see if I could clean it up more. So the method that constructs the actual path (org.springdoc.ui.AbstractSwaggerResourceResolver#findWebJarResourcePath) works like this:

1. Invokes the private method webjar to extract the very first 'component' of the given path. (TBH the name of the method is a bit confusing as it has nothing to do with webjar(?) but just plain logic to extract a path component.)
2. If there the first path component doesn't exist, or the component is the full path itself, return null.
3. Otherwise, returns a path by adding the SwaggerUI version number between the first path component and the rest.

I can further clean up the logic there by utilizing java.nio.file.Path.

So, as my last comment mentioned, the implementation of org.springdoc.ui.AbstractSwaggerResourceResolver#findWebJarResourcePath can be refactored to:

	protected String findWebJarResourcePath(String pathStr) {
		Path path = Paths.get(pathStr);
		if (path.getNameCount() < 2) return null;
		String version = swaggerUiConfigProperties.getVersion();
		if (version == null) return null;
		Path first = path.getName(0);
		Path rest = path.subpath(1, path.getNameCount());
		return first.resolve(version).resolve(rest).toString();
	}

Which eliminates the only references to the private methods webjar(String) and path(String, String), enabling me to cleanup even more lines of code. Though, I wonder if I am doing too much. If the maintainers are cool with it, I can push the change.

Thank you, @wnineg, for your answer.

I agree. I created a "fix" before I saw that you had already done it, so I just compared/commented solutions, also without going into details.
Maintainers will probably know best what is "good enough" to close this issue.

@wnineg and @vojkog,

Thank you for your contributions and interesting discussion.
Just merged your proposed changes.