What clear case did was correct for C/C++ and possibly Pascal and Ada and run by makefiles. Clearcase would spot which header files were used in your code and only recompiled if you changed those headers and if someone else used the same code and headers clear case would give them the .o file it had compiled for you. (no having to generate .dep files).
As local machines got faster this became less of a speedup.
In the latter all dependency tracking was not part of the language so it could be left to clear case.
Java does its own dependency tracking and so did cleanse on the server so you get the mess. Clearcase is not necessarily at fault here it just was not designed for Java.
No the error is the users/management Clearcase and Java just don't work together using winking etc. So the users should use something else.
Clearcase assumptions still worked for C/C++.
Clearcase could also act in the way svn, PVCS and CVS did with a checkout to a local disk and that way there would not have been the issues the OP talks about. (We did that for some projects not because of Java but because we were on Windows). Clearcase was still useful as it had good merging and easy branching 10 years before git.
After git and mercurial came out then yes Clearcase was not worth the money and collapsed.
What clear case did was correct for C/C++ and possibly Pascal and Ada and run by makefiles. Clearcase would spot which header files were used in your code and only recompiled if you changed those headers and if someone else used the same code and headers clear case would give them the .o file it had compiled for you. (no having to generate .dep files). As local machines got faster this became less of a speedup.
In the latter all dependency tracking was not part of the language so it could be left to clear case.
Java does its own dependency tracking and so did cleanse on the server so you get the mess. Clearcase is not necessarily at fault here it just was not designed for Java.