It certainly isn't secure enough for a situation where guessing values can reveal information.
At least some of the overrides aren't even secure enough to use as a hash-code in the face of arbitrary user-selected input (it's really easy to do a hash-DoS attack against anything using Java's
In cases where you want an identifier, I recommend taking a simple identifier (e.g. a numeric key in a database, an atomically incremented integer which is a key into a hash table, etc), and then appending a cryptographic hash of that and a salt.
That is, your publicly-exposed ID would be of the form (in language agnostic form):
Concatenate(PrivateID, HexString(SHA256(UTF8Bytes(Concatenate(Salt, PrivateID)))))
(You could remove part of the hash for a smaller ID at the cost of reduced time to brute-force).
Then the private ID can be obtained as a substring, and the full id can be verified again. The general procedure is also easily ported between languages.
The handful of CPU cycles this will cost isn't going to be a big impact relative to the rest of the system, unless your system is so trivial that you won't be using much CPU anyway, so unless you're running this on something really low-powered (as in, far less powerful than a cheap phone) it won't be a concern.
In cases where you actually want to use a hash-code as a hash-code and have to deal with user-selected input, then use a seedable hash algorithm (e.g. SpookyHash) and base your seed on start-up time (or better still, a mix of start-up time and the time you create the hash container). (Nothing to do with cryptographic hashes, so they can be much faster; the only security risk this avoids is hash-DoSing).