Harmony
  1. Harmony
  2. HARMONY-6245

NoSuchMethod error with three-level hierarchy

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 5.0M10
    • Fix Version/s: 5.0M11
    • Component/s: VM
    • Labels:
      None
    • Environment:

      Description

      Running the attached class produces:
      java.lang.NoSuchMethodError: com/sap/sql/sqlparser/SQLParser.resetTokenBuffer()V while resolving constant pool entry at index 9 in class Test
      at Test.main(Test.java:13)

      The hierarchy used is:
      public class SQLParser extends LLkParser
      public class LLkParser extends Parser

      The method resetTokenBuffer() however can be found in antlr.Parser

      Running the same with SunVM produces no such Error

      1. NoSuchMethod.zip
        824 kB
        Hristo Spaschev Iliev

        Activity

        Hide
        Hristo Spaschev Iliev added a comment -

        Test class with 2 JAR files containing the hirarchy producing NoSuchMethod

        Show
        Hristo Spaschev Iliev added a comment - Test class with 2 JAR files containing the hirarchy producing NoSuchMethod
        Hide
        Pavel Pervov added a comment -

        Without looking at the code I may suggest that the problem is in the fact that DRLVM contains antlr and uses it for internal purposes and that antlr can have older version, which does not contain resetTokenBuffer()V with this exact signature or does not contain it at all.

        Try using -Xbootclasspath/p:<path to your antlr>. If this fixes the issue, we can look at updating antlr version used in DRLVM to the latest version.

        Otherwise, it is necessary to debug the whole thingy (is it SAP over Harmony?).

        Show
        Pavel Pervov added a comment - Without looking at the code I may suggest that the problem is in the fact that DRLVM contains antlr and uses it for internal purposes and that antlr can have older version, which does not contain resetTokenBuffer()V with this exact signature or does not contain it at all. Try using -Xbootclasspath/p:<path to your antlr>. If this fixes the issue, we can look at updating antlr version used in DRLVM to the latest version. Otherwise, it is necessary to debug the whole thingy (is it SAP over Harmony?).
        Hide
        Pavel Pervov added a comment -

        Well, looking at the archive, I should say that updating antlr in DRLVM won't help.

        Show
        Pavel Pervov added a comment - Well, looking at the archive, I should say that updating antlr in DRLVM won't help.
        Hide
        Hristo Spaschev Iliev added a comment -

        Prepending antlr to the classpath really fixes the issue.

        The update of antlr in DRLVM may fix our case but will this be OK for applications that want to use older (or newer) versions of antlr?

        Show
        Hristo Spaschev Iliev added a comment - Prepending antlr to the classpath really fixes the issue. The update of antlr in DRLVM may fix our case but will this be OK for applications that want to use older (or newer) versions of antlr?
        Hide
        Tim Ellison added a comment -

        I agree with Pavel here.

        If you run
        java.exe -Xbootclasspath/p:sap.com~tc~antlr~runtime.jar -cp .;sap.com~tc~bl~opensql~implStandalone.jar Test

        then it runs to completion without error.

        Also when I ran the Test class using the original launch line and the IBM VME it ran to completion without error (the IBM VME doesn't use antlr).

        Show
        Tim Ellison added a comment - I agree with Pavel here. If you run java.exe -Xbootclasspath/p:sap.com~tc~antlr~runtime.jar -cp .;sap.com~tc~bl~opensql~implStandalone.jar Test then it runs to completion without error. Also when I ran the Test class using the original launch line and the IBM VME it ran to completion without error (the IBM VME doesn't use antlr).
        Hide
        Tim Ellison added a comment -

        Welcome to Java ;-/

        Seriously though, it is the same problem if you want to use a different version of the XML libraries, JMX, or ICU (modulo the standards override mechanism).

        Until we get a runtime modularity story for Java the 'classpath hell' means that whoever gets to put their version first on the path wins.

        Show
        Tim Ellison added a comment - Welcome to Java ;-/ Seriously though, it is the same problem if you want to use a different version of the XML libraries, JMX, or ICU (modulo the standards override mechanism). Until we get a runtime modularity story for Java the 'classpath hell' means that whoever gets to put their version first on the path wins.
        Hide
        Tim Ellison added a comment -

        I'm closing this as a non-bug. It's a limitation of Java which we could work around as Pavel states on the mailing list.

        Show
        Tim Ellison added a comment - I'm closing this as a non-bug. It's a limitation of Java which we could work around as Pavel states on the mailing list.

          People

          • Assignee:
            Tim Ellison
            Reporter:
            Hristo Spaschev Iliev
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development