JavaDoc ConventionBundle

In v1.0.0, the class javadoc on ConventionBundleImpl looks a little stale, similarly for DefaultConventionBundleSource, looks like the classes were called ReferenceRate and ReferenceRateSource in the past.

I found ConventionBundle a little puzzling, it seems like it has grown to become a union of many separate types of convention bundles. The constructors of ConventionBundleImpl almost suggest the separate types.

Gary

/**

  • An implementation of ReferenceRate for use by the InMemoryReferenceRateRepository. Note it is NOT immutable, because the repository needs to be able to assign
  • unique ids to it retrospectively, and to be able to update the bundle.
    */
    public class ConventionBundleImpl implements ConventionBundle {

/**

  • Default implementation of ReferenceRateSource that uses an underlying ReferenceRateMaster as a data source.
    */
    public class DefaultConventionBundleSource implements ConventionBundleSource {

Hi Gary,

You’re correct, it is basically a union of all the different conventions at the moment. This structure is the result of organic growth in our requirements over the last couple of years. We’ve been meaning to refactor this for quite a while and had a couple of goes at it, but there’s always been changes in the meantime that have meant we’ve backed off.

You can expect that this will change in the future - the current intention is to merge it into a remodelled security master as a set of ‘templates’ for OTCs and rates. In this scenario each convention set would be properly typed rather than the current model.

In the meantime I’ll get someone to take a look at the JavaDocs and see about making them clearer.

Jim
P.S. Great to meet you the other day, do keep the comments coming!

Just as a follow-up, I’ve now checked in some JavaDocs for the constructors and also cleaned up some of the interfaces a bit. This is on the ‘develop’ branch and the JavaDocs will be available from the next release, although in the meantime you can build them yourself pretty easily.

As I said before, we are still planning to do a larger reworking of these data structures in the next few months.

Jim