jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jr3] Security through obscurity
Date Mon, 31 May 2010 08:41:20 GMT
Hi,

On Mon, May 31, 2010 at 10:19 AM, Felix Meschberger <fmeschbe@gmail.com> wrote:
> On 31.05.2010 09:41, Jukka Zitting wrote:
>> On Mon, May 31, 2010 at 9:39 AM, Felix Meschberger <fmeschbe@gmail.com> wrote:
>>> Let me add another word here: We must not drive the architecture of
>>> anything by the desire to avoid public method in internal classes.
>>
>> Did anyone suggest that? Seems to me like this whole thread is a big
>> misunderstanding.
>
> Maybe this has not been proposed explicitly, but the proposals of
> JCR-2640 and JCR-890 implicitly state this ;-)

That's certainly not my intention and I'm sorry if I haven't been
clearer about this.

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.

At no point was this about preventing "public methods in internal
classes" like X.

BR,

Jukka Zitting

Mime
View raw message