Blair Zajac wrote:
> Working on a new Java Subversion project, I have a number of
> repositories that by design will have revisions that do not have
> monotonically increasing dates. So I'll be doing my own date to
> revision search through a log history.
>
> So I need two things, one is microseconds time since 1970 as stored in
> apr_time_t and I want to do the sorting fast. Currently, the
> java.util.Date's contain microsecond time since 1970, so the sorting
> algorithm may not be accurate if I truncate the times. Also, if I use
> new log message callback in trunk's SVNClient.logMessages(), then I can
> get the timestamp and with the attached patch, not have to construct
> java.util.Date's and only use the timestamp.
>
> The current LogMessage class grows an additional field, but besides
> calling the new constructor from the C++ code, will there be any
> ramifications of doing this?
>
> Is this a safe change to make? Will it break anything for older clients?
>
> I know in C land, adding a field to a class or structure can be
> problematic, but in Java, will their be an issue?
I've also been thinking about this same issue in the context of a
different object. The only scenario that I came up is if LogMessage is
somehow serialized, either through a subclass, or by being a member of
another class, with the old version and then unserialized with the new
version. It seems like that might be a problem, but somebody with more
Java knowledge than myself could comment definitively.
If it is an issue, and we do need to keep object data membership limited
as we extend the interface, I whole-heartedly recommend extending
successor objects from previous versions. (See Info and Info2 as an
example of how *not* to do this.)
-Hyrum
Received on Wed Apr 18 02:11:50 2007