[OpenAFS-devel] Q's Java API (JAFS) in the 1.4.x build branch

[Jim Doyle]

I recently discovered that libjafs.so builds out with the default build 
from the head of the 1.4.x branch. It appears if you got JAVA_HOME in your env path, that configure chases after it and adds it as a build target.

I was PLEASANTLY suprised to see that not only does it build, but it 
works (!) with just a few minor bug fixes nonetheless. I was able to 
traverse my cell and have it dump all the servers, partitions and volume
information.

Who is using JAFS?   Who is relying on it?   Who, if anyone, has put time
into it to maintain it?

There are a number of design and architectural issues with JAFS that I see
immediately that I could fix ; provided it isnt being already done by others:

1.  hashCode()/equals() is improperly implemented in the current codebase.
In particular, the signature equals(Object o) must be implemented properly
and further, hashCode() must ALSO be overriden at the same time to reflect  the object identity rule, as opposed to the default reference identity behavior.  I've already fixed this, I'd just need cvs commit privs.

2.  The architecture is not suitable for most Java environments because
attribute values have been too closed coupled to the behavior specific to native methods.  Architecturally, the entity classes (Cell, Volume, etc), need to be Serializable POJOs with no behavioural methods - they are just value objects. The "behavioral" methods should be moved to pure Interfaces (i.e. releaseVolume(...), createVolume(...)).  A number of concrete classes can then realize these interfaces ; NAMELY:  Proxies for remoting access
to JAFS via RMI-IIOP, RMI-JRMP, even web methods.   Adapters that implement but hide the specifics of the Java Native Methods glue.   Interceptors that can shim ontop the service interfaces to implement auditing, access control etc. This is classis SOA (service oriented architecture) stuff...

3.  If these minor but significant architectural enhancements can be pulled off (at the cost of breaking the "current" JAFS API signatures!), JAFS
should not only be alot easier to maintain, BUT, should be eminently usable
by both JFC/Swing UI developers, web developers as well as work with the frameworks (EJB3, Spring).  Further, using the classic SOA architecture
I proposed, it'd not be hard to wrap the JAFS API with a Webservice to
permit other language bindings (Perl, Ruby, etc).

4.  Dump the checked exceptions and use runtime exceptions.

5.  Because we dont know how multiple Java threads hitting multiple methods
on the same _impl object and spawning multiple Pthreads for RX is going
to behave, it also makes sense to change the JNI methods to use a master
lock to avoid psychotic thread-mapping/thread safety issues. The master lock approach is a hack, but its correct at the expense of performance. 

That said, I'd like to know who out there is already on JAFS and also
who is depending on the current API for production work.... The proposed
refactoring will substantially alter the API. 

-- Jim