[news.eclipse.tools] editor extensions registration options?

[gjohnsto@xxxxxxxxxx (Gary Johnston)]

We are building a graphical editor for a certain kind of "goober" (and
let's just leave it at that so that I don't have to spend space describing
what a "goober" is, which isn't really relevant).  A goober is actually
saved as a Java source file (i.e., a .java file and corresponding compiled
class file), one goober class definition per .java/.class file in our
case.  So, every goober shows up in the Navigator as a .java file, but not
all .java files are goobers, of course.  We'd like to register our goobers
(with the editor extension point) such that 1) goobers have a distinct
icon in the navigator (so user's can tell which .java files are goobers
and which aren't), 2) double-clicking on a goober source file opens our
goober editor (rather than the Java source editor), and 3) the file is
otherwise treated as a normal .java file (e.g., the Java source editor
could be opened on it via "Open with" from the context menu).

The approach we're considering is to register (in our plugin.xml) the
extension "goober.java", specifying our own goober icon and our goober
editor.  I have a few questions about this approach:

1) Would this basically work the way we want it to?  Would our icon be
used by the Navigator for .goober.java files, or would it just be ignored
(i.e., .java file icon would override it)?  Would our editor be invoked if
one double-clicked on a .goober.java file, or would the Java source editor
still be invoked?  Would the Java source editor still be available via
"Open with" from the context menu?  More generally, does an "foo.bar"
editor extension registration override a "bar" extension registration
while still leaving "bar" registered tools available via the context menu,
etc.?

2) Are we making any trouble for ourselves WRT the Eclipse Java tools due
to the fact that our goober .java and .class files won't follow the common
convention that, for example, MyClass.java contains the definition for a
single class, MyClass, and compiles to MyClass.class?  Our approach
violates this convention because the class defined in, say,
MyGoober.goober.java would be MyGoober and would, of course, compile to
MyGoober .class.  This is perfectly valid Java, of course, and so
shouldn't be any problem for the Eclipse Java tools unless they assume the
convention is being followed.

3) Is there some other (better) approach we should take?

Thanks for any help or advice.