I would be surprised if you find a "clean" one (of course depending on
your criteria for "clean"), for a couple of reasons (in no particular
order, this is an endless subject):

- Swing's own architecture isn't modeled as "pure" MVC or MVP, but a
variant. Applications following the Swing architecture are unlikely to
be "clean".

- Everyone interprets MVC or MVP slightly different. Even if we leave
MVC aside (the Smalltalk people claim they know and have the only pure,
original and real MVC), MVP is also a problem. E.g. some people simply
say the Presenter in MVP is the typical main loop which can be found in
many GUI toolkits, others disagree and point to some separate event and
interaction "managing" component.

- The above comes into play also, because MVC and MVP are idealized
patterns. And just like when you build something real from an idealized
blueprint (e.g. an engine from the model of an engine), you soon figure
out that there are issues not covered by the model, and that you need to
do more. And there your cleanness goes out of the window.

- The Model-View separation doesn't scale too well for real world
applications. E.g. there once was a C++ GUI toolkit (recently
resurrected) called Fresco, where each and every, really each and every
small and large GUI component was modeled that way. Even a single color
component of a color was a separate object. When you programmed with
that toolkit you got mad about the amount of objects which you need to
wire together to get things set up. Many people have learned a lot from
Fresco and its predecessor InterViews, and you can still do, but it
drove me mad.

- Scaling/scope, more particular, matching the real world to the pattern
is also an issue with Swing (or applications based on similar toolkits).
E.g. take a simple form-type entry dialog with a couple of text fields
for data entry. How should the Model(s) look like? What are they? Where
are they? Each text field has an own Model, or should the sum of the
text entries (some kind of data set) be the Model? But what if that set
of data from that particular dialog window is just an excerpt from some
larger data set? Wouldn't it be good to treat that large data set as the
Model? But if you do that, what do you provide as input/output to the
dialog? All this is solvable and is solved in practice, but it dilutes a
"clean" application of MVC.

- Expanding further on the above dialog example, when you implement
something like this, you will soon figure out that you need some kind of
transactions. Not something which is defined in MVC or MVP. E.g. you
don't want that each single keystroke changing data in a text field is
immediately applied to the Model. You want that all changes at once (and
typically either all changes or non, probably with a chance to undo
them, too) are applied to the Model. So where do you hold the
intermediate changes? From the GUI widget's point of view, there should
be some Model holding this data, but that Model is not the "real" Model
which is finally changed from an application's point of view. Again, all
this can and is solved in practice, but you won't find anything of this
in "clean" MVC or MVP.

/Thomas

At least a good starting point are the examples
provided by Martin Fowler in his free draft for
"Further Patterns of Enterprise Application Architecture".

Martin motivates several desktop patterns and
data binding strategies in a longer text. Just google
"Organizing presentation logic". I suggest to start
with that, then look into the individual patterns
that come with source code examples.

Martin explains differences between "Presentation Model"
and MVP and describes why he focuses on MVP, not MVC.
He provides guidelines when to split up an Autonomous
View into a presentation and a presentation logic role.
That's what MVP and "Presentation Model" both offer
(and there are other ways to achieve it).

There's one point where I slightly disagree with Fowler.
It's not just a matter of taste whether you choose
MVP or Presentation Model. It may also depend on where
you come from, how much a refactoring costs, how well
one or the other pattern fits into your GUI toolkit,
and how easy you can support GUI requirements.

I provide a free data binding library that includes
source code tutorial examples for a "Presentation Model"
implementation in Swing. I've found that the PM pattern
is useful for almost every team. In contrast automatic
data binding is a wild and powerful horse that sometimes
helps, and in other contexts stiffles your productivity.
Anyway, here's the library: http://binding.dev.java.net/

Hope this helps.
-Karsten