Description
When LaunchedURLClassLoader loads a class, it preemptively defines the class's package. This ensures that a manifest in a nested jar is found and associated with the package. If the package is split across multiple locations, LaunchedURLClassLoader will currently use the manifest from the first location that it finds for the package. This can lead to a manifest from a location other than that of the class that triggered the package definition being used which is undesirable.
A notable example of the problem is the loader code which contains an empty org.springframework.boot package (as it's the parent of the org.springframework.loader package). It's repackaged into the root of the application jar and we don't want the application's manifest to be used for the org.springframework.boot package.
We need to ensure that the manifest from a jar that actually contains an org.springframework.boot class is used instead.