)]}'
{
  "log": [
    {
      "commit": "b1f9c79c550e4d9d77d85ab723b642cd0eb7afad",
      "tree": "99e6c330f7b9c9c4e7c659788e4920ebdd96555a",
      "parents": [
        "b27d874ebc0c067d96994a6ebe3c10eaeb2e4a75"
      ],
      "author": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Fri Aug 03 11:10:49 2018 +0100"
      },
      "committer": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Fri Aug 03 11:11:52 2018 +0100"
      },
      "message": "Remove all multidex.jpp files.\n\nThese are unused since jack was removed from the tree.\n\nTest: Rely on TreeHugger\nChange-Id: Iaf16bc70ed943d46cd56a3140deb7508c8bf985f\n"
    },
    {
      "commit": "afb664701734c6edbea07431382ee33f1677d42b",
      "tree": "bd67954a08efb59e7bee75dfe46d1230abe4443b",
      "parents": [
        "7f14c2ec37c70010d99cab6806d85018df56c555"
      ],
      "author": {
        "name": "Alex Light",
        "email": "allight@google.com",
        "time": "Tue Aug 01 09:54:49 2017 -0700"
      },
      "committer": {
        "name": "Alex Light",
        "email": "allight@google.com",
        "time": "Wed Aug 02 14:58:10 2017 -0700"
      },
      "message": "Fix verifier checks on interface methods.\n\nWe were disallowing interfaces in the IsInheritedMethod even though\nthe function can be called with them. This could cause some failing\nDCHECKS if the verifier cannot find methods in some situations.\n\nWe also fixed a small issue in the verifier where we allowed\nnon-public java.lang.Object methods to be considered valid for\ninterface dispatch.\n\nTest: ./test.py --host -j50\nTest: Compile an app with bad bytecodes (See bug)\nBug: 64158483\nBug: 64274113\nChange-Id: Ia79f25be0001efc4069a411a0b34476bd0871803\n"
    },
    {
      "commit": "ba118827465d12177f3996e50133960087b1c916",
      "tree": "f39728cdafc7810004d51c0bef2728b98993daa9",
      "parents": [
        "64a102dde8c5daad83b991710decb418ce43aac5"
      ],
      "author": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Mon Jun 12 15:41:56 2017 +0100"
      },
      "committer": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Thu Jul 20 13:35:06 2017 +0100"
      },
      "message": "ART: Change method lookup to be more consistent to JLS and the RI.\n\nThe method lookup for different invoke types was previously\nwidely different and didn\u0027t work well with the dex cache\nmethod array where we have only a single slot for each\nMethodId. The new behavior is to perform the same lookup for\nall cases, distinguishing only between interface and\nnon-interface referencing class, and to further align the\nbehavior with the JLS and the RI. Where the JLS conflicts\nwith the RI, we follow the JLS semantics.\n\nThe new lookup for class methods first searches the methods\ndeclared in the superclass chain (ignoring \"copied\" methods)\nand only then looks in the \"copied\" methods. If the search\nin the superclass chain finds a method that has not been\ninherited (i.e. either a private method or a package-access\nmethod where one of the classes in the chain does not belong\nto the same package, see JLS 8.4.8), we still search the\n\"copied\" methods as there may actually be a method inherited\nfrom an interface. This follows the JLS semantics where\ninherited methods are included in the search (JLS 15.12.2.1)\nbut conflicts with the RI where the private or\npackage-access method takes precedence over methods\ninherited from interfaces.\n\nNote that this search can find an accessible method that is\nnot inherited by the qualifying type, either for a package\naccess method when the referrer is in the same package but\nthe qualifying type is in another package, or for a private\nmethod where the referrer is in the same class but the\nqualifying type is actually a subclass. For the moment we\nallow such calls and we shall consider whether to throw\nan IncompatibleClassChangeError in this situation in future\nto comply with JLS 15.12.4.3.\n\nThe new lookup for interface methods searches the interface\nclass, then all the superinterfaces and then the\njava.lang.Object class, see implicitly declared methods in\ninterfaces, JLS 9.2. The search for the maximally-specific\nnon-abstract superinterface method is not yet implemented,\nbut the difference should be difficult to observe as the\nusual subsequent call to FindVirtualMethodForInterface()\nshould yield the same result for any matching method.\n\nThe new test 162-method-idx-clash exposes several cases\nwhere we previously completely messed up due to the effects\nof the DexCache, or where we were out of line with the RI.\nIt also tests a case where the JLS and the RI disagree and\nwe follow the JLS.\n\nTest: art/test/run-test --host --jvm 162-method-resolution\nTest: m test-art-host-gtest\nTest: testrunner.py --host\nTest: testrunner.py --host --interp-ac\nTest: Nexus 6P boots.\nTest: testrunner.py --target\nBug: 62855082\nBug: 30627598\nChange-Id: If450c8cff2751369011d649c25d28a482a2c61a3\n"
    }
  ]
}