Re: Substitute Name Handling

Martin Matula <[email protected]> Thu, 03 Oct 2002 12:58:07 +0200
Newsgroups gmane.comp.java.netbeans.modules.mdr.devel
Message-ID <[email protected]>
Hi Brian,

Brian Smith wrote:
  > (1) In the default JMIMappers' mapping of package names (package names
  > should be all lowercase, but they are not always generated as all
  > lowercase). For example, if the packagePrefix is removed from the
  > "PrimitiveTypes" package, the resulting Java package name is
  > "primitiveTypes" when it should be "primitivetypes".

This is obviously a bug. I found out that the MDR does not even pass the
TCK currently because of this bug. I think I have brought it in with my
last changes to JMIMapper and TagProvider where I was replacing use of
Strings by StringBuffers on some places. I have already fixed this bug 
to be able to run TCK on the MDR to check for other bugs that I might 
have introduced.

  > (2) I would like TagProvider.getSubstName(), .getTypeFullName(), etc. to
  > handle the special case for Exceptions (if an exception's name ends in
  > "Exception" then it is left unchanged, otherwise "Exception" is appended
  > to it). Currently, the caller of TagProvider.getSubstName() needs to do
  > handle this special case. This is easy to forget to do (I didn't even
  > know about the special case until I started working on improving
  > JavaMapper).

I agree. I am sure that there are other "ugly" thinkgs in
JMIMapper/TagProvider as they were written rather quickly than cleanly
:) So if you see that other architectural improvements/cleaning can be
done, feel free to do it.

  > (3) I noticed that Section 4.6.2 of JMI 1.0 seems to say that even if
  > the javax.jmi.substituteName tag is found, that the "formatting and name
  > mangling" still apply to the substitute name. Currently, MDR only does
  > the formatting only if a substitute name was not found.

You are right. We did this for performance reasons assuming that one
would not provide an invalid substitute name. But your example shows
that this is not the case. You are right that to conform to the spec it
should be fixed.

Could you please fix also TagSupport while making these changes so that
it is consistent with TagProvider? (TagSupport is used for generating
implementations of JMI interfaces)
Thanks,
Martin

  > Example:
  >
  > package DOM {
  >      class DOMImplementation
  >
  >      tag DOMImplementationCapitalization:
  >          javax.jmi.substituteName='DOMImplementation'
  >          on DOMImplementation
  > }
  >
  > MDR will generate this interface (among others):
  >
  > package dom;
  >
  > public interface DOMImplementation extends javax.jmi.reflect.RefObject {
  > }
  >
  > However, it appears from the specification that it should generate:
  >
  > package dom;
  >
  > public interface Domimplementation extends javax.jmi.reflect.RefObject {
  > }
  >
  > since the name substitution "occurs before applying any name mangling
  > rules."
  >
  > The JMI Spec says:
  >
  > 4.6.2 Tag for Providing Substitute Identifiers
  > ....
  > Wherever the Java mapping makes use of a model element’s name, the
  > substitute name should be used in its place. This substitution occurs
  > before applying any name mangling rules.
  >
  > restrictions: The preconditions defined in “Preconditions for Java
  > Interface Generation†on page 49 apply to the substitute name; i.e.
  > [1] it must be a syntactically valid Java identifier, and
  > [2] all identifiers produced from it must be unique in their respective
  > scopes after formatting and name mangling, as per the Java mapping
  > specification. In addition, [3] there should be at most one substitute
  > name tag per ModelElement.
  >
  > And later:
  >
  > 4.7.1: Rules for Splitting MOF Model.ModelElement Names into Words
  > ....
  > In order to generate a complete JMI API, all ModelElement names (or the
  > javax.jmi.substituteName if one is provided) must conform to the [rules
  > for splitting MOF Model.ModelElement mames into words].
  >
  >