Unlike every other event, if a component has no mouse [motion] listener
then mouse events are bubbled up to the parent container. This means you
can get away with listening to a parent component, and still receive
events for all of its children.

However, events are supposed to be multicast and listeners should not
interfere with one another. If some other code, quite reasonably, adds a
mouse [motion] listener to a child component, then the events wont get
bubbled up.

This is spectacularly bad design.

So, prefer the higher level event types. Mouse [motion] listeners are
fine if and only if you are defining your own subclass of JComponent or
implementing a PL&F.

Otherwise there are hacks to get the low-level events. The best is to
push a java.awt.EventQueue that intercepts events as they are
dispatched. This works with standard applet/web start permissions (from
1.2.2, IIRC). However, you do lose system copy & paste support and
potentially other features of trusted libraries.

Another approach is to use Toolkit.addAWTEventListener. This does not
work at all for untrusted code, so avoid if you can. This technique is
used by the Basic PL&F to implement pop ups on components from 1.5, and
activating internal frames from 1.6.

The most popular approach is 'glass panes', which are really broken.
Avoid at all costs.