Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
I had solved this in a former homegrown solution.
The rationale for the target class was that the same "source" could be mapped twice in the DTO tree. The reason for not using an IdentityHashMap was that our underlying lib above JPA would possibly generate several instances for the same row in the database...
The cache only lived inside a top level conversion from the user... (it was cleared as soon as the conversion returned to the user). In other words, if I had a Person with an Address (both translating to PersonDto and AddressDto) the cached would last from the Person to PersonDto conversion (including the nested Address to AddressDto). However, if the user explicitly asked to translate an Address to an AddressDto (not as part of a Person), then the cache would last just there...
This allowed to convert complex structures such as graphs.
…d to resolve cyclic mapping