Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of tmueller@day.com designates
 207.126.148.87 as permitted sender)
MIME-Version: 1.0
Date: Wed, 26 May 2010 13:28:12 +0200
Message-ID: <AANLkTikdTtijzT25d97i79chHBDu6362jR-yNbjzUfih@mail.gmail.com>
Subject: [jr3] Security through obscurity
From: =?ISO-8859-1?Q?Thomas_M=FCller?= <thomas.mueller@day.com>
To: dev <dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Do we want have public methods in the Jackrabbit 3 implementation that
can possibly be misused (if somebody casts to an implementation
class)? See the discussion at
https://issues.apache.org/jira/browse/JCR-2640

The advantage of not having public classes: people can't cast
implementation classes and call such methods. Is this really a
problem? People should use the JCR API - they are not supposed to cast
to implementation classes.

The disadvantages are: it massively complicates developing Jackrabbit
3. It complicates understanding the source code. It potentially slows
down performance. It needs more memory (potentially a lot, for example
for cached objects such a NodeImpl). It's probably not always possible
to follow this rule. It doesn't solve the problem (people can still
modify the source code of Jackrabbit, or they can call
setAccessible(true)). Wikipedia currently defines "security through
obscurity" as follows: "a principle in security engineering, which
attempts to use secrecy  (of design, implementation, etc.) to provide
security." In my view this is such a case.

Examples of embedded repositories or databases

a) that need more than one package and use this "no public methods" approach:

- I don't know any. Are there any such projects?

b) that do have public methods:

- All open source Java databases I know (Apache Derby, HSQLDB, H2)
- Hibernate (well probably most projects)
- I'm sure there are many cases in Sun JDK and JRE, for example xml
packages, javac, javadoc, almost everywhere where interfaces and
implementation are distinct and multiple packages are used.