So the issue here is pretty clear i.e. in the context of Java 14+
manifested here:
the fix is pretty clear as well i.e. do the explicit import
Luckily in Groovy I can use import aliasing allowing for far more elegant solution however unless something has changed recently one can’t do so in Java.
So my question is why impose the Java developer with having to fully qualify one or the other ?
Should Daml perhaps choose a less “generic” name ?
A bit of philosophy this morning 
It’s a fair point. I think you can’t come up with something much less generic given how fundamental of a concept (it’s not that far off from a role that Object has for Java) it is but maybe at least DamlRecord is worth considering. When we created the Java bindings, Java 14 didn’t exist so it was hard to anticipate that. Changing this type of stuff is always a bit iffy since you don’t want to break old code but maybe still worth doing.
its a thought, Java 16 is coming out , already out ?
On the other hand the large majority of your intended customers I would venture will be stuck on Java 8 for a while, so that buys you some time
Groovy allows me to bypass the issue , so I’m good.
Anyhow, I submit “hadron” as a substitute
As someone who doesn’t track Java development closely, I must still say, it’s pretty bold of the Java standard library maintainers to say “surely no one is using the class name Record, let’s go ahead and put ours in the default namespace”. 
Well , it may seem bold but I’m pretty sure it seems normal to them or perhaps they are just arrogant i.e. Sun/Oracle feel that Java is the core of the ecosystem and that the package java.lang is the most appropriate for such a generic construct.
Java Records are similar to kotlin data classes, and Groovy can achieve similar with annotations.
So probably will be a decently used construct.
Personally as an API designer I rather not fight that fight.
