I know how to do this in a cumbersome way, interested if any of you has a better way to share.
It would be easier to do this in other languages which have an import aliasing mechanism (like Daml and others), but as far as I know, Java doesn’t have it.
In the generated Java code, the package id is part of the TEMPLATE_ID static attribute, so it’s hard-coded in the generated template classes.
I can apply a prefix to the generated package names, so e.g. two Product contract classes, generated from two different DARs, can be referenced like this:
But in the absence of an aliasing mechanism, I cannot import both versions into a file under different aliases.
What I can do is not to import them, but wrap up every piece of code which uses this class into a switch/case construct, and reference the class qualified, depending on some input flag specifying the DAR version.
That’s the cumbersome way, requiring a lot of boilerplate code. Can any of you think of a better way to do this?
Consider how much of your code you can lift one level of abstraction. The Java codegen has in more recent releases been acquiring features on the COMPANION static field, which is a bigger object that reflects more about the template than just the ID. For example, it has a TEMPLATE_IDinstance field, so if you write a generic method that takes companions, it can access and operate on that field.
You could usefully copy all these companions to a utility class and deal with them in a purely different-names-have-different-types way.
It is at least worth considering whether you can use a JVM alternative language that properly supports qualified imports and renaming, even if just to enumerate the reasons for rejecting this option.
I’m a bit confused by that. You can use the fully-qualified name instead of an alias, which I agree is longer, but how does that require more boilerplate than having aliases? You’d still need to have all the code that decides which to use when, as far as I can tell.
Yes, that’s true, aliasing in itself makes only a little difference. The real difference is that in the event of a partial change in the Daml model, only part of the client code must be changed, probably a big chunk of it will be repeated in the switch/case branches.