+7  A: 

It depends upon your needs. I tend to think Swing components constructors taking as input non-model objects are in fact shortcuts for fast prototyping. indeed, behind the hoods, the Swing component will create a model from the input object, since it requires a model object to have all the events correctly sent.

As a consequence, here is my advice :

  • For a fast prototype, you may consider the use of these "mock-like" constructors
  • For a "real-world" application, don't even think about them, since sooner or latter will arise the need for specific event sending (to change one node rendering, making the tree grow, ...)
Riduidel
Some good advice here.
Adamski
+2  A: 

As Riduidel said, JTree always uses a TreeModel internally, so the other constructors are really just for convenience.

There's also the setModel(JTree) method, which will set (and replace) the model. In a non-trivial application you'll probably want to build the frame and it's components before filling in the data.

I don't consider any of the constructors as being non-MVC. What's more important in that regard is that you keep code responsible for the data, UI, and logic as separate and non-dependent as possible. That allows you to better unit test your code, and it helps with flexibility and re-usability.

tom
I find your approach quite interesting ...Do you often create widgets without models loaded in ? (pure curiosity question)From my point of view, I find best to create widget with its associated model (even if I eventually put data in model after having loaded and displayed the widget) instead of swapping model during component view, which *may* introduce some flckering.
Riduidel
Yes, I develop database backed apps, so waiting for the data to load takes way to long. We build the frame, then swap the model (or maybe just add items) whenever the data loads. I'm claiming it's the best solution, but it works for us.
tom
oops, I'm NOT claiming it's the best solution
tom