Link Details

There is already an open source library with some similar features:
http://www.tek271.com/free/memoizer/tek271.memoizer.intro.html

I find it interesting that the author does not list any references to similar work done by others.

Yeah, this is really just method memoization done using interface proxies and annotations. Nothing special in that.

Probably I'm not adding any value with this comment...but I did some similar work two years ago :)

http://dev2dev.bea.com/pub/a/2006/05/declarative-caching.html

There is one important distinction: the cache is maintained relevant (fresh) in the way transparent for developers. No stale data are accessible, only fresh data can be requested from an object. To implement this, real calculation dependences are tracked; a cache element's lifetime is not taken into account at all in contrast to existing solutions, since it's not necessary for this approach. Caching is made on the level of objects, so cache elements exist as long as objects exist. Also there are some additional features not covered by the article for it not to be overloaded. You can turn to the tutorial for details: http://www.fusionsoft-online.com/refreshableobject.php

Thanks for the reference.

Honestly, it still sounds like simple method memoization done with interface proxies and some sort of a weekly referenced cache.

How could you possibly track calculation dependencies without examining the raw method byte-code? AFAIK Java doesn't provide any mechanism for doing this.

The core question to answer was when an arbitrary object property, maybe calculated from others, is changed. To track this, run-time call sequences (calculation dependencies) are analyzed. If an object property is changed, all properties calculated from it directly or indirectly, are considered to be changed too. This is done on the level of objects, not classes, so examining the raw method byte-code is not necessary for that. It means that different objects of the same class have independent calculation dependency tracking.

Memorization was the last feature added. And it is not as simple as it seems because it never gives stale data. Other approaches do give stale data from time to time or require programming to avoid this, as far as I know. In our approach, no programming is needed, stale data are never returned. It lets use the library in absolutely transparent manner: you implement getters with no optimization, doing cycles and other resource-intensive work, and then you do optimization by marking some of the getters with the annotation @Cached. And no logic is changed, no stale data should be considered. It's not true for other solutions.

I can't agree that it's just memorization. Of course, the task can be solved by hands using one of the existing memorization solutions by programming cache clearance in addition to memorization every time it is necessary. But it is not so simple if calculation dependencies are complex, form an extensive hierarchy in depth and/or breadth. This is the reason why existing approaches are applied to rare object properties if stale data are tolerated or cache clearance programming is simple enough. We talk about refreshable objects that provide property change tracking (and declarative caching when necessary) for all properties with no programming, irrespective of property calculation complexity.