It should be noted in the interests of fairness to all sides that while JBoss has been maligned for its classloading structure, every application server suffers from some degree of "classloader hell," partially because the J2EE specification itself only recommends a classloader structure, and there are many situations in which the recommendation isn't optimal.
...fix Java. Forget versioning by classloading and lets go versioning by compiler and by runtime profile definition.What do you think? How do you think the classloader structures in J2EE should work - if any differently than it does now? Should the specification mandate a classloader structure?
- When classes are compiled they get an auto "version" of the epoch time and a hash of the hostname. The form is FQN.epoch.machinehash. We will call this classversion.
- When a class references another class the FQN is replaced by FQN.classversion
- When the classloader looks for a class, it looks for one matching classversion. If it does not find one, it looks at the manifest of the requesting deployment for a matching pattern.
- Matching patterns may be FQN.(>12324567).*. That would mean any later epoch from any host.
- The whole declaration is "FQNOfRequestor.*.* : FQNOfRequested.*.*" For example: "org.jboss.example.Requestor.*.* : org.apache.commons.logging.CrashJava.(>1234567).*" - that would mean that if org.jboss.example.Requestor tries to load some specific version of CrashJava and it doesn't find it...load a version built on any host with an epoch time later than 1234567.
- Timezones don't matter because this isn't needing versions that are quite that fine grained
- Classes are defined solely by FQN.classversion. They are NEVER defined by Classloader instance.
- For backward compatibility this is implemented via compiler and a new classloader.
- For backward compatibility classes without version information are versioned at runtime with their classloader id (basically the same behavior as present). Linkages with no version are treated as FQN.*.*.