It looks like some VM bug where the inheritance of classes brakes.
I have 3 classes
class a { public void method1(){}}
class b extends a {public void method1{}}
class c extends b {public void method1{}}
As you can see each class overrides the implementation of method1.
During runtime it happens sometime that the object is instanceof c, though when method1 is invoked, vm uses class a implementation from the top class in the inheritance tree.
I wonder if Sprint did any over the air buggy firmware update in the last month, as I’m absolutely sure that it this worked fine on A900 month ago, and it does work on all the other devices (as it’s supposed to).
3 Comments
The issue seems to be with a class structure fork.
I believe that the the VM gets confused with a class tree as follows when methods are being called in rapid succession (e.g. when quick opcodes or a JIT might be used)
Class tree:
1. EF extends DF extends C extends B -extends A
2. E extends D extends C extends B extends A
Where the base class is A and all of these classes implement the method: “method1()”. Class C has a method “testMethod” that calls “method1″.
If we have an array of elements EF and E and we rapidly iterate through it calling “testMethod”. Normal operation will invoke method1 in either EF or E depending on the instance. However, I believe in the A900, the just-in-time compiler gets confused and incorrectly calls the “method1″ method in “C” when there is more than one override path.
I encountered this problem and it seems to have gone away by me declaring all the involved classes as “abstract”. I don’t know how often that’ll work, but it worked for me.
I believe the way Vincent fixed it, was to move all the methods into the base abstract class, “testMethod” in this case.
Post a Comment