Use the same classpath ordering for an exploded jar and an archive

[hengyunabc]

demo.zip

Print classloader urls in main method:

	public static void main(String[] args) {
		URLClassLoader classLoader = (URLClassLoader) Thread.currentThread().getContextClassLoader();
		for(URL url : classLoader.getURLs()) {
			System.err.println(url);
		}
		SpringApplication.run(DemoApplication.class, args);
	}

• Run as jar

mvn clean package -DskipTests
$ java -jar target/demo-0.0.1-SNAPSHOT.jar

output:

jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-starter-1.5.3.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-1.5.3.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-context-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-aop-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-beans-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-expression-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-autoconfigure-1.5.3.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-starter-logging-1.5.3.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/logback-classic-1.1.11.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/logback-core-1.1.11.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/jcl-over-slf4j-1.7.25.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/jul-to-slf4j-1.7.25.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/log4j-over-slf4j-1.7.25.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-core-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/snakeyaml-1.17.jar!/
jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/slf4j-api-1.7.25.jar!/

• Run in directory

cd target
unzip demo-0.0.1-SNAPSHOT.jar -d demo
cd demo
java org.springframework.boot.loader.PropertiesLauncher

output:

file:/private/tmp/demo/target/demo/BOOT-INF/classes/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/jcl-over-slf4j-1.7.25.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/jul-to-slf4j-1.7.25.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/log4j-over-slf4j-1.7.25.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/logback-classic-1.1.11.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/logback-core-1.1.11.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/slf4j-api-1.7.25.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/snakeyaml-1.17.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-aop-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-beans-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-boot-1.5.3.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-boot-autoconfigure-1.5.3.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-boot-starter-1.5.3.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-boot-starter-logging-1.5.3.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-context-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-core-4.3.8.RELEASE.jar!/
jar:file:/private/tmp/demo/target/demo/BOOT-INF/lib/spring-expression-4.3.8.RELEASE.jar!/

---

The order of classLoader urls is very important.

When run app in exploded directory, the order of jars is different.

I recommend add a index file BOOT-INF/INDEX.LIST to save the order of jars.

See also:

• http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Index_File_Specification
• When the spring-boot-maven-plugin performs the repackage goal the POM order of the libraries is not maintained #8397

[almeidaah]

I see, i think is important too. But why need to run the exploded class? When you run, you run the jar artifact, right?

[hengyunabc]

@almeidaah

When run as fat jar, the jar url looks like :

jar:file:/private/tmp/demo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/slf4j-api-1.7.25.jar!/`

It is not the standard jar file url, will have compatibility issues. So we run spring boot app in an exploded directory.

[wilkinsona]

It is not the standard jar file url, will have compatibility issues

What compatibility issues have you seen? In the vast majority of cases, the nested jars do not cause any problems. When they do, you can configure specific dependencies to be unpacked to a temporary directory on launch. In other words, while it's not an unreasonable thing to do, there should be no need to unpack the jar as you are currently doing.

[hengyunabc]

@wilkinsona
Thanks, I know the unpacked to a temporary directory on launch feature.
But the user's scene is complex, some code will get all ClassLoader urls, process themself.

[wilkinsona]

I've reworked the issue title as I don't want to jump straight to a particular implementation. The problem's also more complex than it would appear to be at first. One reason for exploding an archive is to add extra jars to the classpath (CloudFoundry's Java buildpack does this, for example) at that point any list that orders the classpath becomes stale and we'd need to decide what to do. Some options include:

1. Fail
2. Place any extra jars at the start of the classpath
3. Place any extra jars at the end of the classpath

[brenuart]

Isn't enough to simply sort the entries alphabetically to have a predictable classpath construction?
I would expect BOOT-INF/classes to always appear first, followed by entries in BOOT-INF/lib sorted on their name. This would give a classpath similar to what Maven and most servlet container do (afaik).

The same logic would apply when running on an exploded jar. If people want to add extra jars, then they would know they have to pay special attention to their names if they want them to appear first/last in the classpath.

Regarding the additional paths specified by loader.path, I would add them first just like the current behaviour. To me, this feature is a way to override part of what is in the original fat jar.

Side question: is there any guarantee today that BOOT-INF/classes ALWAYS appears before BOOT-INF/lib ?

[wilkinsona]

Isn't enough to simply sort the entries alphabetically to have a predictable classpath construction?

No. As described above, even with a determined order, we need to preserve that order when a jar is exploded and also allow jars to be added somehow.

I would expect BOOT-INF/classes to always appear first, followed by entries in BOOT-INF/lib sorted on their name. This would give a classpath similar to what Maven and most servlet container do (afaik).

Maven orders the class path based on the order in which dependencies are declared in the pom. I believe Gradle does something similar.

is there any guarantee today that BOOT-INF/classes ALWAYS appears before BOOT-INF/lib ?

No. It's determined by the order of the entries in the jar file, or, if it's been exploded, by the ordering of the files on the filesystem.