In this particular case it probably wouldn't make any difference as String is immutable.
If a member isn't and doesn't implement Cloneable you'll have to explicitly make a deep copy yourself.
There might be more to it, I've not used Cloneable extensively myself, but that's how I understand it to work.
jwenting
duckman
8,392 posts since Nov 2004
Reputation Points: 1,662
Solved Threads: 337
Thread safety isn't something of a single method, it's something for the entire class.
Without knowing the code for the rest of the class, it's impossible to tell whether this one is threadsafe or not.
It might be, but most likely it isn't. Just putting a "synchronized" keyword here and there isn't going to change that however, you'll need to make sure no update to one data member can happen while you're working on another one.
For example you have to ensure that noone changes that String while you're cloning the HashListNode (which also has to have thread safety in mind).
jwenting
duckman
8,392 posts since Nov 2004
Reputation Points: 1,662
Solved Threads: 337
Not even halfway there.
Different threads can still access data members at the same time, even if they can't change them at the same time.
One thread can call setData while another calls getData for example, potentially getting corrupted results.
jwenting
duckman
8,392 posts since Nov 2004
Reputation Points: 1,662
Solved Threads: 337