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.
