Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ ClassRepository ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

KernelGroup working document. Edit as you see fit.

I have decided to take up the task of doing the Analyses & Design work on the ClassRepository, since no one else has. Put simply: it has to be done before JOS will exist. My beginning point will be the work that has already been done on the requirements in the mailing lists and here, instead of redoing that work as is our custom in this project. :)

I am not committing yet to the coding, but I will decide on that after these first tasks are complete. I plan to use TogetherJ, a 100% Pure Java OOAD tool. If you have further thoughts on the requirements for this piece of JOS or want to note required interactions with other parts of JOS, please note them here.

-- AveryRegier

• ClassRepository is the only home for class definitions, including the bytecode representation (if the class is not interpreted).
  • ??? - The bytecode is interpretted. Perhaps you mean the JITted code? - AveryRegier
• ClassRepository will support the JDK 1.2 Versioning specification.
• (Package,Version) combination will uniquely identify a particular version of a package. This combination will be the primary entity in the repository. Perhaps source might be a third element in this unique package identifier? Comments?
  • In the JDK 1.2 Versioning specification there are two separate versions: An API version number and an implementation version number. We need to somehow take account of this when uniquely identifying versions of a package. - AveryRegier
• The ClassRepository will be shared by every process and ClassLoader in the operating system.
  • Thus the ClassRepository is a singleton. Instead of using a Constructor, we should have a ClassRepository.getClassRepository() static method. - Avery Regier
• Since classes are not versioned or managed independently, the classes will belong to a (Package,Version) combination.
• ClassRepository will have an API that can be accessed by a CLI or GUI admin tool.
• Permissions to add/remove/update classes will be created and handled by the security manager.
• ClassLoaders will be written to use the ClassRepository API, therefore security will be handled at the ClassRepository level.
• ClassRepository might also hold any optimizations necessary for proper VM/JIT functioning.
• ClassRepository can hold bytecodes, sourcecode or both. If sourcecode is provided, then a Compiler or Interpreter object will be required. This allows scripting programs to be held by the respository as well. It also allows for other languages to be formally supported.
• When a Class is updated to a new version, a ClassMigrator class may also be installed, which will be used (when available) to automatically migrate classes from one version to another. If no ClassMigrator is available, then new class versions may only add fields (and converted objects will have these fields initilized to null). Perhaps optionally, we can make an ovverride for "dropping" fields. This is a bigger problem, called SchemaMigration that needs to be addressed, perhaps seperately.
• ClassRepository might have replication features for distributed environments to help support Zero workstation adminstration goals.
• ClassRepository can be updated dynamically by processes with the appropriate permissions. Perhaps ClassMigrations might also be done dynamically... hmmm...
• When a class is stored, additional information needed by the system will be attached. This information will be configurable through the API.
  • We can do this by serializing a subclass of java.lang.Class which contains this information. - AveryRegier
• The ClassRepository will be a persistent object.
• Every once and a while, "unreferenced" classes can be moved out of the ClassRepository based on some kind of usage / need free space / number of references based on reachability.

• The unique identifier for a class in the repository is (Package, Class,Version). I'm not sure this will work. Nothing guarantees Package and Class are unique and I'm not sure how we'd know what version something is. We may need UUIDs here, after all.
• When a class is stored, additional information needed by the system will be attached. This information will be configurable through the API. ClassRepository treats each class as a MetaObject. This could be done by defining a MetaObjectable interface that wrappers serializable for each Class. We'd need to provide one for Object if we want to save non-jos classes.
• The ClassRepository will be a persistent object. * The ClassRepository's API should be the same API as the rest of the OOFS. Either the MetaObjectable interface or the OOFS API would be the place to define the distributed replication API.
• Every once and a while, "unreferenced" classes can be moved out of the ClassRepository based on some kind of usage / need free space / number of references based on reachability. This seems like a bad idea to me. If we bothered to load them, why would we unload them? Who would determine which classes to remove? -- BillRehm
• When loading packages, ClassRepository should be able to strip static main() code iff it is allowed by package information, e.g. "Strip-Main-At-Installation: yes", or beans in general. This came up on the apps mailing list. -- RalfStephan

• There should be a simple API for automagically creating .jar files from classes in the repository. This would include meta-information about the classes be automatically included in the Manifest file. For instance, if a Class is registered as a bean in the repository, then an entry in the Manifest is created Java-Bean: true for that particular class. This needs to be the same for Package information and versioning information.

Content of these pages are owned and copyrighted by the poster.
Hosted by: