At the code level a reference to another class or instance usually is at least an association.
The only way I can imagine a dependency in Java code that isn't an association is an unused object member or an unused method parameter. Once you start using methods on the object you are defining the semantics of the relationship at which point the relationship is at least an association.
Your example has a dependency (which isn't an association) because you are not using bar inside of Foo.do. The moment you call a method on bar inside of do() you are defining the semantics of the relationship between Foo and Bar - now there is an association between Foo and Bar.
Dependency is also used more as an 'aspect' rather than a full-blown concept. There are many types of dependencies that can adorn an inter-classifier relationship: access, binding, call, creation, derivation, instantiation, permission, realization, refinement, send, substitution, trace dependency, usage.
In UML a dependency means that a change in the definition of one of the dependent objects may result in a change to the other.
An association allows one object instance to allow another to act on its behalf (by sending a message from one to the other).
Dependencies can exist between other elements than classes. (Requirements, use cases, packages, etc.)
The word dependency is overloaded a little bit in current use in such idioms as "dependency injection" and "dependent objects". In a UML context I believe these are associations. (Not to suggest that we should start saying "association injection".)