Jackrabbit in general is a fully JCR-1.0-compliant (JSR-170) Java content repository implementation. As the spec does not mandate every detail, Jackrabbit has to use a specific implementation in some cases and it also contains some additional features. This page shall give an overview.
Please note that this list is not complete. And the work in progress on the JCR 2.0 (JSR-283) implementation in Jackrabbit creates more of these points and two specifications to "diff" against. If you have any questions on this topic, the best place to ask are the jackrabbit mailing lists (start on the users list).
Additional Features
- XPath element() function also allows for mixin node types in the second argument (not only primary node types as mandated by the spec in section 6.6.4.13 "element() Node Test")
Implementation Choice
- Changes made by different sessions: Jackrabbit employs a copy-on-write model, ie. any non-modified item in one session will always reflect the persisted state of that item (section 7.1.3.4 "Seeing Changes Made by Other Sessions").
InvalidItemStateExceptions on concurrent modifications: complex issue, see JCR-1552 for details
UUID assignment: Jackrabbit's implementation uses UUIDs internally as well, so these are already assigned upon creating a node and will not change upon a save(). Note that Node.getUUID() will nevertheless throw an UnsupportedRepositoryOperationException if the node is not mix:referenceable (section 4.9.1.1 "When UUIDs are Assigned").