I am sending patch series that adds support for subset of SVN Ra layer to the JavaHL API. Initial goal was to expose commit editor APIs necessary to commit to the remote repositories without local working copy and then seek feedback before going further.
While developing the prototype I tried to make minimal changes to the existing code, while reusing as much as possible for the new RA implementation. As a result the new code takes advantage of new additions that old code does not. Also not being an expert on Subversion API, where it conflicted with JNI code I assumed JNI code was wrong and changed it.
During the course of implementation I made couple of choices for the reasons listed below:
Hierarchical nature of editor baton's required life cycle management of the wrapper C++ and java objects for cases when a parent object is disposed before its children. I though of two possibilities:
* Maintain weak JNI references in SVNBase then a parent can zero out cppAddr for the child java objects if they are still around
* Internally release all resources maintained by the wrapper object and set a flag that object has been disposed that is checked at the beginning of each call. The wrapper object is deleted when dispose() or finalize() method is explicitly called on the java object
I chose the later because it did not require use of extra resources from the JVM, freed majority of the used memory, and only had overhead when the caller did not properly dispose of the objects.
I also ran into an issue where I was not sure of what was the proper fix. When passing "BAD" as a parameter to reparent() function, assert was encountered that killed the JVM. Would it be ok to add uri parsing check to svn_ra_reparent in ra_loader.c like the one done in svn_ra_open4?