OK, here's the rub: there will be document objects, various kinds, with
the potential for more kinds to be introduced in the future by other
coders. (So, there should be an interface or abstract base class.)

These will need gui editability and viewability.

It will be desirable for old gui code to support new document classes.

How to achieve this?

I can see several options, all of which seem to have drawbacks as well
as advantages:

* MVC model, or similar. Each document class has a parallel ui class,
and maybe helper
 classes. A UI instance and a document instance are created, and
associated.
 Upside: Multiple UI implementations for one document type can be
written and chosen
 among.
 Downside: Have to create a document object, a compatible UI object,
associate them, and
 experience ClassCastExceptions if an incompatible pair arise somehow.
Generally messy
 and ugly and type-unsafe.
* Similar, but UI classes "own" document classes -- the UI class acts
as a factory for
 document objects (can load, create, etc. them).
 Upside: Can again have alternative UI implementations per document
type, and no type
 safety issues or ugliness.
 Downside: UI implementations must reimplement document factory
methods; or else call
 document constructors that receive UI instances as arguments, which
of course may be
 called with wrong-type arguments. Also, attaching more than one UI
view to a single
 underlying document becomes problematic.
* Document instances provide methods to produce UI instances bound to
the document
 instance. Document classes rule, and provide their own viewer/editor
UI.
 Upside: Type-safe and can attach more than one UI object to a single
document object.
 Downside: Document class author provides "official" UI
implementations, and third party
 UI implementations for the same class will be ugly and rickety at
best, and may be
 unsafe/nonworking/not possible.

Any experienced application developers know which way to go in this
sort of situation?
Another way of showing it is to show the type hierarchy:
                     DocInterface --> Doctype1 --> SpecializedDoctype1
JComponent --> DocViewer --> Doctype1Viewer --> SpecializedViewer
JComponent --> DocEditor --> Doctype1Editor --> SpecializedEditor

Problem being you read, say, an ObjectInputStream and cast to a
DocInterface. Then you
want to generate a suitable UI instance. Option 3 above makes it easy,
call a getViewer or
getEditor method specified by the interface, but at the cost of
extensibility (even if you can
make custom viewers that work, you will get the standard one from
getViewer or getEditor).
Options 1 and 2 mean you need to somehow determine if you have a
compatible UI class
at all, and if so what class, and then instantiate it ... ugly as hell
and probably fairly bug-prone.

On the other hand, one could provide DocInterface with a method to
return a Class object
representing an interface all compatible UI implementations would
implement -- Doctype1 say specifies Doctype1EditorInterface. (A given
implementation need not actually provide more than viewing facilities.)
Or better yet, an abstract JComponent subclass implementations should
subclass. This can have a static factory method to provide instances of
Doctype1-author-contrived UI implementations, getEditorInstance and
getViewerInstance. Users could browse a filtered list of alternative
implementations (filtered to show only extenders of the abstract class,
or implementors of the interface) from a list of all the UI classes,
populated via static initializers or something. (The abstract class may
have private static HashSet<Class> foo = null, and the static
initializers have if (foo == null) foo = new HashSet<Class>();
foo.add(class); note latter statement not part of if.)

So far I'm leaning toward option 3, just having the document objects
themselves able to produce instances of appropriate UI objects you can
then stuff into a JPanel. One thing about that that really bugs me
though is that it makes anything that depends on a document class
automatically have associated editor classes as dependencies, even if
it's a batch-mode job meant to do some sort of automated grinding on
document objects rather than an interactive application. And that, of
course, means that said batch job will haul in all of Swing, the AWT,
and God only knows what else (and may fail on headless machines,
machines that don't have a GUI, etc...) Is there a way to avoid a
dependency nightmare without running, instead, into a type-safety
nightmare?

--
I am the terror that flaps in the net!
I am the circular dependencies that confound and confuse!
I am TWISTED!