Recently on Ted Neward's weblog there was a discussion about the limitations of the ClassLoader architecture: http://neward.net/ted/weblog/index.jsp?date=20030215 Ted offers some suggestion for improving the architecture, and it got me to thinking about a few related changes that I think might make the classloading more powerful and allow for quicker, cleaner updates of Java while giving you more control over how the updates affect your existing code. Now bear with me on this, it's not too well thought out, but I figured I'd start it and see what you guys all think. (There are Three Changes) The first change would be to build version-checking/loading directly into the classloader architecture. With version-checked loading, Sun (and developers) can deploy incremental updates without the need for delivery of an entirely new jdk/jre (e.g. rt.jar). The second change is what could come out of using a version-checked loading method: You could set your code to use specific versions. Example: In the new Isolate API, it will be necessary to update java.lang.System to work differently than the current version. Let's say I want to run old apps as I always did, and some new apps using the new version of System. Simply start the JVM with -Djava.runtime.version=1.3 (or whatever) for runtime packages and -Djava.version.package=com.mycompany.data[1.3+] for third party packages. With this information the classloader automatically loads the proper version. The third change (again drawing from the previous two): Allow the System ClassLoader to redefine classes (not just arbitrarily, bear with me here). To fully realize the power of byte-code engineering, and dynamic runtime classes/decisions, I believe classes need to be able to be redefined. HOWEVER, I think this would HAVE to be coordinated with the versioning system. Let me explain: When a class is defined it would automatically be given a version (whether or not you specify one) within the VM - maybe considered a "Runtime version number." When you redefine a class, you would have to specify a new version (there would be a required syntax for this that Java "forces" you to follow so we all would do it the same). CodeSources would then (in the jar?) specify whether they can use that new version, maybe like this:
As well, it would be done on a major/minor version system, so any minor versions would be assumed to be compatible with anything taking the major version of that (So if I can use 1.3, then any 1.3.1 has to be compatible with my code) Otherwise, these classes continue to use the earlier version. One thing that might also be added (not sure if nec), is some extra methods (similar to Serialization methods?) to facilitate the reloading. So if my class uses a package that can be updated, then I have the ability to implement the method public void packageReloaded(String packageName, String version)? (Not sure this would be needed) but even if I do not implement that method, the JVM could still update the class, in a default manner. This is not well thought out and would need more time, but I think this could make Java VERY powerful in terms of ability to handle dynamic systems and architectures. (What issues are raised by something like this?) As well, it would need security to be better thought out. I'm thinking that CodeSource-based permissioning is a poor concept when you're dealing with dynamically created classes that have no file (they're generated at runtime). So there would need to be an update of the security architecture for this - and a maybe way to ensure that only Sun/and/or the owner of this particular JVM installation updates the package java.* for example. [ February 18, 2003: Message edited by: Robert Paris ]
Thanks tiny ad, for helping me escape the terrible comfort of this chair.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop