There is one possibly common use case with Object Ids: one where no generation is needed, but source ids are String ids with arbitrary structure (or, possibly, none) and where the only important thing from Jackson perspective is that they are unique ids.
In addition to allow use of "opaque" Object Ids, generation side could either:
Throw an exception if attempted, to only for deserialization, OR
Use Random UUID generation, similar to UUIDGenerator
For now I think (2) makes more sense, as it actually will work just fine. If anyone wants to disallow this, or change it, they may then simply override implementation method(s).
(note: based on idea from https://github.com/FasterXML/jackson-dataformat-yaml/issues/45)
There is one possibly common use case with Object Ids: one where no generation is needed, but source ids are String ids with arbitrary structure (or, possibly, none) and where the only important thing from Jackson perspective is that they are unique ids.
In addition to allow use of "opaque" Object Ids, generation side could either:
UUIDgeneration, similar toUUIDGeneratorFor now I think (2) makes more sense, as it actually will work just fine. If anyone wants to disallow this, or change it, they may then simply override implementation method(s).