On 19.2.13 15:51, Jukka Zitting wrote:
So, to simplify things I propose that we refactor the above code to
something like this:
public Something getSomething() {
enter("doSomething");
return ...;
}
The problem is that SessionDelegate.needsRefresh() requires clean up
after the "real" method returns. Using a closure like approach frees the
caller from this responsibility. In your approach you would probably end
up forcing each client method having to call a leave() method after the
"real" work is done. Forgetting to do so would break the refresh
invariants.
I agree that there is to much boilerplate though. Some of it stems from
the Java encoding of closures and some of it stems from the various
precondition checks. The former is pretty well hidden by modern IDEs and
will go away soon anyway (when Java 42 is out ;-) ). The latter is IMO
better tackled by enriching SessionOperation with preconditions to be
checked before the core of the call is actually executed. This will at
the same time address the issue I brought up at our last meeting that
implementing JCR method in terms of each others will result in the
preconditions being checked multiple times instead of just once.
Regarding the cost of the extra object allocation, I think the JVM is
pretty efficient with handling these and we shouldn't jump to conclusion
until we have figures on the performance drain caused by this. If this
turns out to be a problem we still can get rid of the per call
allocations by using pre allocated instances and by passing in a more or
less generic environment.
Michael
