Repository navigation
Conversation
Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
| .setAnnotationType(AnnotationType.OTHER) | ||
| .setComment("Annotation 2") | ||
| .build(); | ||
| assertNotSame(ann1, ann2); |
There was a problem hiding this comment.
Hi, @goneall. I came across this issue while working with SPDX SBOMs for RPMs. I wanted to write an SPDX ID like "SPDXRef-{arch}-{name}".
RPMs with the names "Foo" and "foo" are distinct everywhere (RPMs, PURLs of type rpm, and SPDX IDs in the spec) except in java-spdx-library's InMemSpdxStore.
This test case can't catch the bug because it checks object instances (which are always different). Replacing this line with assertFalse("ann2 overwrote ann1 in the SPDX store", ann1.equivalent(ann2)) surfaces the bug.
I believe, just like in https://github.com/spdx/spdx-java-rdf-store, we should store things under the exact URI and then lowercase only for getCaseSensitiveId() as you noted in spdx/tools-java#283 (comment).
Thanks!
There was a problem hiding this comment.
The equals for the abstract parent of all SPDX objects is overridden - so this should fail as is - reference https://github.com/spdx/spdx-java-core/blob/0f87d39db9fc5807a0b891caca15a28ae4d9c18f/src/main/java/org/spdx/core/CoreModelObject.java#L832
That being said, it would be a good idea to add your recommended check in addition to the current check. I'll update the PR.
There was a problem hiding this comment.
To clarify, same uses == not equals(), but I don't think equals() can fail here either (it's always false) and it's comparing the Java objects themselves whereas equivalent() is actually looking in the store, right?
There was a problem hiding this comment.
You are correct in the equivalent() looks at all of the properties in the store. This was done so 2 Java instances with the same URI will show as being equal - the URI is a key used to access all the properties, so we know if the URIs are the same, the objects will be the same even if they are in different instances.
The equals override returns true of the 2 object URIs are the same for Element types - I believe the == will call the equals() and get overridden.
I thought when I originally created the unit test it failed, but it's been a while - so I may be wrong.
In any case, it doesn't hurt to have both tests.
Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
This branch has not been deployed
3 participants
No description provided.