My bad.  That was (dripping with) sarcasm.  

I obviously failed to make that point due to my
abysmal communication skills.  Maybe a wink
[ ;-) ] at the end would have helped get across
that I was being somewhat less than technically
helpful?

Ok.. but I will bring you back to..

'Over Optimization'.  Do you have code that supports
this claim?  Or are you simply over optimizing, trying
to solve a problem that does not exist?

How long is 'very long'?  A JTree with 40,000 nodes
would be (I guess) unmanagably large for this end-user
to usefully navigate, but I suspect the JRE could find
entries within it, relatively quickly.  That though led
me to suggest..

"It would probably be just as bad as trying to foist
such a long structure into a JTree and onto screen
in the first place.  OTOH if it is small enough for the
end user to handle and navigate, I am confident it is
small enough for the JRE to search."

So - noting that I have also failed to provide any
code to prove my point, not that I am interested
enough to write code proving anything - I feel if this
matter is of such interest to you, write some code
that supports your initial assertion that a 'very long'
(but still managable) JTree represents 'enough data
to display, but too much to search', and I might be
able to invest more thought in it.

Notes:
1) I do not know of any method that provides what
you want directly, and suspect if one exists, it would
simply be a 'convenience method' for searching
iteratively - in any case.
2) You might also store each node in a map using the
potential strings as keys, though I have not thought so
much about that yet, ..convince me it is a real problem
and I might think some more on it.