The value of this toString function is questionable. Make sure the information returned in this function is necessary. For instance, the portal may use this string directly. In that case, consider using a different function name.
toString is also used by IDEs when debugging. There is not enough null checking in this code at the moment. In particular, healthStatus is often null and will cause the object to look broken during debugging because toString makes a null reference.
The change to use the spring @repository annotation obscures how spring retrieves information from the database. And a null pointer exception in this toString method can make debugging very difficult. DeviceRepository's findDeviceByName function does retrieve the correct object. The IDE will show that null pointer exception unless you look closely at the object.
I don't think it hinders validation. It's not an urgent problem yet.
iadgovuser26
commented
2 months ago
https://github.com/nsacyber/HIRS/blob/4b72d9aee39c6072a807080bfe6251560933d71e/HIRS_AttestationCA/src/main/java/hirs/attestationca/persist/entity/userdefined/Device.java#L115-L118
The value of this toString function is questionable. Make sure the information returned in this function is necessary. For instance, the portal may use this string directly. In that case, consider using a different function name.
toString is also used by IDEs when debugging. There is not enough null checking in this code at the moment. In particular, healthStatus is often null and will cause the object to look broken during debugging because toString makes a null reference.
The change to use the spring @repository annotation obscures how spring retrieves information from the database. And a null pointer exception in this toString method can make debugging very difficult. DeviceRepository's findDeviceByName function does retrieve the correct object. The IDE will show that null pointer exception unless you look closely at the object.
I don't think it hinders validation. It's not an urgent problem yet.