Product classes marked as final


#1

I created a BermudanSwaption product class and ideally I would have wanted to derive it from Swaption but it is marked as final so I can’t. Also I will need to create a swap with embedded optionality and will need to create stand-alone CancellableSwap, CallableSwap etc since Swap is also marked final. This results in a lot of boilerplate coding. Is there a reason for making products final?

With regard to a Cancellable swap I could structure it with a swap and european swaption in the same trade. However it seems only 1 product per trade is supported?


#2

Our data model is intended to be fully immutable, of which declaring the final is good practice. It also prepares the code for a possible future as value types. When we designed Strata, the trade off was accepted that there would be more duplication of code than is typically seen as a result of our choices.

There is a case to consider if Swaption should have pluggable optionality, as that is how FpML represents it IIRC. That might solve the bermudan problem, although ultimately it depends on how common the two are, especially in market data and pricing (in general, each product Java class corresponds to an approach to pricing).

As you say, only one product is allowed per trade. When resolved you could create the two products you want, but you’d still need to have a wrapper around them that delegates to the two underlying pricers. Part of the advantage of this is that it allows the configuration necessary at the strata-calc level to be different for each type.

Hope that helps


#3

Totally makes sense. Thanks. I’ve recently started working in Kotlin where classes by default are final (or “not open” in Kotlin speak). I’m starting to appreciate the rationale behind making everything immutable except Java makes this more difficult than need be.

Are there plans to support more “exotic” IR types in Strata? At the moment, until I have time to implement the models, I’ve used SWIG to build a Java wrapper on top of Quantlib and I’m calling down into it.


#4

OpenGamma has a focus on margined derivatives, so those are the ones that tend to be in Strata. As such, there are no current plans to add more exotic IR types, although non-deliverable swaps may be added to support common Brazil conventions.