I doubt this was intentional change, if anything it could be a regression.

Can you create jira and attach simple reproducer for this?

Tomaz, the person handling the JIRA (David) noted that we take the discussion to the forum and not treat it as a bug. His last comment on the JIRA is "We will not fix this to be exactly how it was before, because the way we assemble modules makes this difficult/impractical"

This mechanism of using class-path for class loading different versions of the same class has worked for us in all previous versions of JBoss. It has worked not only in previous versions of JBoss but also other application servers we support. David mentions that both the old and new behaviors comply with Java EE spec. If that is the case, I would have thought that a particular feature not be taken away just like that in a new release...

The Java EE 6 specification, section 8.2 Library Support and in it sub section 8.2.1 Bundled Libraries clearly states a JAR file may reference another JAR file using the Class-Path header in the manifest.

The above is what we have done in previous versions too of JBoss and other vendor products and it works as noted.

Here is an excerpt from the Wildfly documentation from the Developer's Guide, section on "Class Loading in Wildfly",

"If the ear-subdeployments-isolated is set to true then no automatic module dependencies between the sub-deployments are set up. User must manually setup the dependency with Class-Path entries, or by setting up explicit module dependencies."

Further it goes on to state

"

Portability

The Java EE specification says that portable applications should not rely on sub deployments having access to other sub deployments unless an explicit Class-Path entry is set in the MANIFEST.MF. So portable applications should always use Class-Path entry to explicitly state their dependencies.

"

So I am not sure how for Wildfly it can be stated that it meets EE specs (and your own documentation).

To be clear, is the the use of package-private (default visibility) that related to the main complaint? If so, I believe David is correct.

There are two different things which you may be conflating - visibility and accessibility. The EE specification sections that you are referring to are about visibility, and the classes are visible (unless shadowed by a class of the same name). If they were not visible, you would see a ClassNotFoundException rather than an IllegalAccessException.

The IllegalAccessException is occurring because although the classes are visible, they and/or specific fields are not accessible to the other classes in the deployment. The specification covering that says that package-private things are only accessible to code in the same package, where package is defined as the pair of package name and classloader. That means if you have two classes belonging to a package of the same name but a different classloader, they will not be able to access each other's package-private things.

The EE specification says very little about the set up of classloaders, it instead talks about what must and must not be visible to various components (but also leaves a lot of that either undefined, or explicitly noted as being allowed to vary between implementations). When you have multiple jars in your EAR which refer to each other by Class-Path references, there is nothing which says they have to belong to the same classloader, and so have access to package-private items. This means that you cannot rely on package-private access outside of an individual jar[0].

The Java EE specification purposely d es not define the exact types and arrangements of class loaders that must be used by a Java EE product. Instead, the specification defines requirements in terms of what classes must or must not be visible to components. A Java EE product is free to use whatever class loaders it chooses to meet these requirements. Portable applications must not depend on the types of class loaders used or the hierarchical arrangement of class loaders, if any.

Many servers simply collect the transitive closure of jars and put them all into the same classloader, especially common for servers that had the "traditional" hierarchical classloader setup, but there is no requirement to do that. There are some down sides to that as well, since it means they can all see each other even if you don't want them to. You cannot for example put two different versions of the same library at the EAR level.

It is also worth noting that the EE spec says:

Portable applications must not depend on the order in which classes and resources are loaded.

and refers to the JAR File Specification, which does not as far as I can tell say that the ordering of entries in Class-Path headers actually has an effect. So when you say that you put the patch jar in front of the other one in the Class-Path reference, I'm not sure that it is actually portable to rely on that.