On Mon, May 31, 2010 at 10:41, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Basically, JCR-2640 is a case of two client-facing classes A and B > both using shared internal state X. In the pre-JCR-2640 state class B > would access X through package-private methods on A, which causes a > tight coupling between A and B and forces the internals of A to be > made public if B is to be moved to another package, as suggested in > JCR-890. > > What I've proposed and now mostly implemented in JCR-2640 is to give > both A and B a direct reference to the internal state X, breaking the > implementation dependency between A and B and allowing B to be moved > around or refactored independently of A.
This sounds good to me. Since all Node/Session/Workspace/* Impl classes and their modularization are predefined by the JCR API and geared towards usability for the client, it is feasible to extract internal state into a separate shared object, as needed by the implementation. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
