How about a compromise: create *two classes *for the two versions, both implementing the same interface. Instantiate the class for the correct version either from (1) static configuration file or (2) runtime "hack" lookup to the version on the Monitor.
(1) gives safety at the expense of the user having to specify another parameter. (2) looks like it will work at least in the near future going to 1.7, as well as for past versions. Thanks for the suggestions! I like the two classes approach better both as a developer and as a user; no need to juggle JARs. ~Dylan On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey <[email protected]> wrote: > > On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison <[email protected]> > wrote: > >> >>> I'm working on a clean way to handle getting Accumulo monitor info for >> different versions of Accumulo, since I used methods to extract that >> information from Accumulo's internals which are version-dependent. As Sean >> wrote, these are not things one should do, but if it's a choice between >> getting the info or not... >> We're thinking of building separate JARs for each 1.x version. >> >> > Why not just take the version of Accumulo you're going to talk to as > configuration information that's given to you as a part of deploying your > software? > > It'll make your life much simpler in the long run. > > > -- > Sean > -- www.cs.stevens.edu/~dhutchis
