I'm a tad disappointed no one's asking why I'm not using Uuid for object
identity?
Firstly, I'd like to.
Let me explain:
The purpose of versioning is to keep important long lived Objects alive
while code evolves. One of the projects I had recently was related to
charge out rates & contracts for several different employment agreements...
Currently, you have to shut down your djinn if you wish to upgrade your
code and codebases can move etc, need to use something like hibernate or
JDBC to persist your objects and tackle the whole object relational
mapping impedance problem, ie, splitting an object into a number of
tables & reconstituting . This isn't suitable if we're ever going to
expand River out into the web.
Not all object's need to persist over upgrades.
Back to the question, the problem, Uuid is a class who's objects may be
required to live for long periods of time, it is precisely the type of
object that should be preserved. Why haven't I chosen to use it yet? I
get the feeling I need to. Currently I have been thinking of River as a
library, such that if it received an upgrade, the new version would be
loaded into another ClassLoader to avoid conflicts. That's the problem,
Uuid now has two Types, and it's equals method returns false for the
same Uuid object if using separate Type's.
For this to work there needs to be a small core or base that doesn't
change, the other packages or jar files can change or be used as
libraries, however any River classes that produce long lived objects,
either need to support versioning or not change or be installed locally
and backward compatible, just like the JRE API itself.
It is very important to keep the version API simple and mostly
restricted to interfaces or classes that don't change, hence the need to
have you all review and comment. I'm not the most experienced but I'm
having a go. I'm hoping that those among you who have considered this
problem before can look at the code and make suggestions.
Best Regards,
Peter.
