River
  1. River
  2. RIVER-82

ClassDep generates duplicate output lines

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: jtsk_2.1
    • Fix Version/s: River_2.1.2
    • Component/s: com_sun_jini_tool
    • Labels:
      None
    • Bugtraq ID:
      6392596

      Description

      Bugtraq ID 6392596

      The classdep utility generates duplicate output lines when
      run under Java5. In particular, this is seen for enum classes
      and for inner classes named on the command line.

      Consider a java source file (in src/foo/Bar.java):

      package foo;
      public class Bar {
      private static enum Contents

      { RECORDS, TASKS }

      public class Inner { }
      }

      Run:

      rm -rf classes
      mkdir classes
      javac -d classes src/foo/Bar.java
      java -cp /vob/jive/lib/tools.jar:$JAVA_HOME/lib/tools.jar \
      com.sun.jini.tool.ClassDep \
      -cp classes -files -in foo foo.Bar foo.Bar\$Inner

      Result:

      foo/Bar.class
      foo/Bar$Contents.class
      foo/Bar$Contents.class
      foo/Bar$Inner.class
      foo/Bar$Inner.class

      Note the two duplicate lines.

      Using jdk1.5.0_06.

        Issue Links

          Activity

          Hide
          Fred Oliver added a comment -

          For reasons not yet clear to me, sometimes BinaryConstantPool.getDependencies returns ClassDeclarations with a name that is an Identifier for an array type ([LFoo$Bar and so the class name embedded in it is a binary (mangled) name, and ClassDep.process does Identifier.lookup on that mangled name, which doesn't transform back to the expected canonical "Foo. Bar" syntax, so the "seen" table ends up with not-equal Identifiers for both "Foo$Bar" and "Foo. Bar", when there should just be "Foo. Bar".

          Show
          Fred Oliver added a comment - For reasons not yet clear to me, sometimes BinaryConstantPool.getDependencies returns ClassDeclarations with a name that is an Identifier for an array type ([LFoo$Bar and so the class name embedded in it is a binary (mangled) name, and ClassDep.process does Identifier.lookup on that mangled name, which doesn't transform back to the expected canonical "Foo. Bar" syntax, so the "seen" table ends up with not-equal Identifiers for both "Foo$Bar" and "Foo. Bar", when there should just be "Foo. Bar".

            People

            • Assignee:
              Mark Brouwer
              Reporter:
              Fred Oliver
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development