Hi Roger,
Thanks for looking into it and for your reply.I don't see a compulsory
reason to change the code.
In context of JDK-8217375 I happened to touch the issue and I agree to
Max to solve it differently in that particular case now by creating a
real deep copy based on reading the manifest bytes
Hi Phillip,
Did you discover need for a deeper copy? If so, can you elaborate?
It may be that adding a new constructor would be cleaner.
I'd suggest clarifying the documentation of existing methods as opposed
to changing the spec and implementation and the possible risks
to clients.
Thanks, Ro
Hi Philipp,
This is going to take some further discussion/input as this has been documented
for sometime as a shallow copy.
If there is a consensus to move this forward, it will also require a CSR. I
can help with that and sponsoring the updates, if the decision is to go ahead
with the pro
Hi again,
Just after having sent the previous mail I found Manifest::clone
explicitly says it creates a shallow copy which is true only to a
certain extent. It deeply copies main attributes as well as individual
sections map already now and only shallowly copies individual sections
attributes maps.
Hi,
Creating a new manifest as a copy from an existing one using the copy
constructor assigns the new manifest individual sections entries map
the same values which are references to attributes as the original
rather than copying them as well deeply resulting in two manifests
pointing to the same
