tauZaman DESIGN DECISIONS (Calendar)
Calendar related components in the system consist of two main sources;
1. Calendar Specification file (in XML), which reveals Calendar's Granularity and Additional Field Names
information. This file, in a sense, is the only point to get any information that eventually builds a Calendar.
If we explain it further, Calendar Specification file contains every information about a specific Calendar,
either hard coded or with a link. For example; It does not include information about how really
Irregular Mappings' are implemented, on the other hand, it gives a java class link that is supposed to
contain the implementation.
2. Java Class files that include implementation of methods a Calendar uses. Since these files are distributed,
and since an XML file can not contain code ready to run, with the help of links in specification file, needed
classes will be loaded dynamically and provide service.
First source, specification file, will be parsed and utilized by using XML Parsers. And for the second, links will be
fetched from the specification file and classes that they point will be loaded by Class Loaders.
XML Parsing seem to be not problematic with appropriate Parsers and Calendar methods. However, dynamic
loading needs a little working. There are two problems here; first which loading principle to follow, and second
how to handle data resolving issues between loaded class and our system.
2 Problems in Loading
1. Java Dynamic Loading, in its very meaning, gives opportunity to a lazy approach to load. However,
in our context, this may change. When we form a Calendar given a Calendar Specification file, we
can immediately load all the classes that we need, that is to say, pointed by specification file. This is
eager way. Alternatively, we can just keep the links in a Calendar, and load and keep the classes to a
Calendric System when they are needed. This is lazy way. Note that Calendric System also may have
to load a class (it may contain an inter Irregular Mapping) without depending whether we implement
a lazy approach or eager.
These two options also contain another problem, which is, how should we organize the Class Loaders.
If we choose lazy eager approach, we have to have a Class Loader instance in Calendars, whereas, in
the other we don't have to, only Calendric System will have such loader. In my understanding both
approaches have duplicate class problem, but I believe eager approach (every Calendar keeps its
loaded classes) will be easier to handle.
So, assuming that we choose eager approach, 3 components will make use of a Class Loader;
a. Calendar
c. FVManager (still working of its details, name can change)
We may have a base ClassLoader and MethodCaller class, which all of them will make use of.
(I am still working on this, whether their use will be that general or not. It seems that option will
be enough. One problem is how to adjust packaging then, a loader package?.)
2. Methods in those dynamically loaded classes will eventually use parameters and return data types
which should be conformant to our system. For example, a method of a dynamically loaded class
may take Fields as a parameter and return an object, which contains formed Granule and its Granularity.
So, a "Calendar Method Class" (a class, which contains specific methods of a Calendar) implementer
should reach some of the components, which are most likely; Field, Fields, Granule, Granularity and
probably a merger class which merges Granule and Granularity for return types. (or maybe this can
be done by a Vector).
One of handling this is to form a .jar file, which only includes these needed classes to write a "Calendar
Method Class". And this .jar file might be distributed publicly.
Note: URLClassLoader (Java Sun JDK) will be used to implement these loaders rather than ClassLoader, since it also
implements SecureClassLoader. In fact, lots of what is explained in this page were also implemented experimentally and
successfully. (see another decision alternative on Dynamic Class Loading.)