Your ideas are not enough to slide the toolbar down. And please forget
about setLocation(). I haven't thought this through in all details, and
I have no intention to do so, but here is how I would approach the problem:

Don't do it :-)))

If this is not an option, I would start with defining some principle
behavior. E.g. what do you want?

a) Maybe you want that the contents of the rest of the window (below the
toolbar) is moving smoothly, too. This is maybe the most difficult case,
since the involved layout manager(s) would have to re-layout all that
stuff repeatedly and smoothly, while you gradually enhance the size of
the sliding toolbar. A lot of calculation and repainting might be going
on, and the result might be all but smooth. Gradually resizing the
toolbar component shouldn't be a big problem, but what these resizing
does to the other components might be. Try if the resizing works
smoothly, before you spend time on the gradual painting of the component.

b) Adding the toolbar immediately reserves the space for the complete
toolbar, and then gradually paints/slides the toolbar into that space.
The rest of the window would only have to be re-layouted once. The
disadvantages would be, that the rest of the window would "jump" once,
and you would have some void on top, which then starts to fill. I am not
sure if this would look ok.

c) The sliding toolbar overlaps with the window contents. In this case,
I would give Popup and PopupFactory a very good look, including the
source code of the classes in order to figure out if they can be
convinced to be resized gradually.

When you have settled on a behavior, you have to solve the next problem.
Gradually drawing the toolbar. Regarding the gradual painting in case a)
and b) I would probably consider messing with the paintComponent(), or
in this case even paint() method of the toolbar. A timer should trigger
repaints, which in turn should result in calls to paint(). I would try
to override paint in such a way that paint first manipulates the
Graphics contents by moving the origin and clipping region, before
calling the original method(). The more often paint() is called, the
smaller this manipulation should be, until you reach the final point. In
case this results in to much CPU time, I would think of letting the
first paint() go to some Image, and the following paints then gradually
draw parts from the image - until the image is painted completely. From
that point on I would direct the painting to the original method.

I have no idea if such a painting is also possible with c).

For extra points you might want to mess with the origins of events to
ensure the toolbar already works while you slide it down.

Oh, have you considered, that such a sliding might go on your user's
nerves? I for example hate many of that "eye candy" which delays things.
E.g. I don't like windows or menus which open or close with some animation.

The more I think about it, the more I like my original suggestion :-)

/Thomas