Monday, December 13, 2010

More thoughts about the abstract JVM

Having read some papers about the topic of purity and nullness checking for Java methods, it turns out that things are not that easy.
The vicious sub-typing stands in the way of sound reasoning about Java methods! Consider:

class A { 
  B b;
  T a1() { return this.b.m1(); }
  T a2() { return this.b.m2(); }
}
class B {
  T m1() { /* pure code */ }
  T m2() { return new T(...); }
}
class C extends B {
  T m1() { System.out.print("ha"); return super.m1(); }
  T m2() { if (something) return null; return super.m2(); }
}

Even if we knew that we had a value v with runtime type A, we cannot answer the questions "Is the call v.a1() free of side effects?" and "May the call v.a2() return null?"
Because at runtime, v.b could well be a C. Note that C might not even exist at the time of our check.

Except for very simple methods, this seems to mean that we cannot detect either purity, null-behaviour nor the runtime type of return values unless the involved methods or classes are declared final or static.

It will be next to impossible to provide a simple workaround for more complex existing code. Perhaps one could automatically "finalize" an existing class somehow .... lots of things to think about.

No comments:

Post a Comment

Comments will be censored by me as I see fit, most likely if they contain insults or propaganda for ideologies I do not like. Comments that are on topic will not be censored. If I leave a comment uncensored this does not imply that I agree with the opinions expressed therein.