Bad practice to have two classes of the same name in different packages?

Question

We have split our application so that package A handles data from one external source and package B from another. In both cases we need to create a domain object and have a

Answer 1

I wouldn't go as far as saying that it's always a bad practice, but it's somewhat of a code smell.

If both classes do different things, then why don't they have different names?

if both classes do the same thing, then why are there two classes?

From a practical standpoint it can become very annoying if those two classes ever need to be referenced in the same class: you'll have to use the FQN for one of those (it would probably be best to use it for both in this case, for clarity). If those two classes are in sufficiently distinct parts of the code that they won't be referenced from the same code, then the practical problem is not so bad.