Application classloaders define packages with the incorrect seal base and do not verify sealed packages

[tjwatson]

Describe the bug
When defining a package at:

open-liberty/dev/com.ibm.ws.classloading/src/com/ibm/ws/classloading/internal/ContainerClassLoader.java

Line 1500 in 60c9c79

resourceContainer.definePackage(packageName, loader, resourceEntry);

The resource URL is used for the Package seal base. The resource URL is the fully qualified URL to the .class file in the JAR. The seal base should instead be the code source location (a URL to the base JAR file itself). Otherwise the seal base of the defined Package becomes the resource URL of the first class defined in the package.

The way the seal base is set now, to the first resource URL, the API to check Package sealing like java.lang.Package.isSealed(URL) is broken. The Liberty loaders currently do not check package sealing at all when a class is defined. If it did then it would always fail on the second class defined in the sealed package because the seal base of the defined package would never match properly.

Options

1. Do nothing, nobody has ever complained about our implementation of sealed packages
2. Fix the seal base of the defined package, but do not actually verify the package seal when defining a new class in the sealed package
3. Fix the seal base of the defined package, and also verify the package seal when defining a new class in the sealed package
4. Stop setting the seal base altogether when defining the package.

I prefer option 4 because it reduces the need for us to create wsjar or jar resource URLs for every class that is defined at runtime.

Pros:

• Stop doing work to set the seal base when we do nothing to verify it
• Possible performance gain by reducing work of the URL handlers for every class load

Cons:

• May break applications if they are calling java.lang.Package.isSealed(URL) or java.lang.Package.isSealed()

Option 3 has some serious zero-migration issues because it will break zero migration of any application that happens to have a sealed JAR but also has other JARs that contribute to the same package as the sealed JAR.