java.nio.file API with JDK 1.6 and older

[Semen Vadishev]

Hello there,

Our team develops Java libraries to work with Subversion and Mercurial 
version control systems. These libraries heavily depend on file system 
access. Currently we have to execute external programs or use JNI/JNA 
bindings to call necessary functions, since corresponding functionality 
is not present in JDK 1.6 and older:

- No symlink processing;
- No support for some file attributes;
- Poor ACL support;
- No bulk fetch of attributes.

As supposed, java.nio.file API solves these problems. Eventually we will 
rewrite certain pieces of code to use this API. On the other hand our 
libraries have to work with older versions of JDK. So, the goal is to 
support two implementations of file system access — older one 
(java.io.File with exec calls or JNI/JNA bindings) and newer one 
(java.nio.file interface).

Here are two ways how we can achieve that:

I. Use wrapper interface.

We build a wrapper interface which delegates its functionality to 
java.nio.file API, if corresponding classes are available at runtime, 
otherwise it delegates calls to existing code which works fine under JDK 
1.6 and older.

II. Make java.nio.file API work with older JDKs.

Currently we're investigating an opportunity to write a standalone 
library which has java.nio.file API and at the same time it could be run 
under JRE 1.6, 1.5 or even 1.4. Basically, this library should include 
all the classes from java.nio.file package and a 1.5/1.6-compatible 
implementation(s) of file store, file system provider, etc. Introduced 
SPI helps a lot here.

The trick is obvious — one writes code using java.nio.file no matter for 
which version of JDK, then one puts the described library along with 
created code. At runtime class loader decides which classes to load and 
use — under JRE 1.7 default implementation is available so JVM uses it, 
under older JREs classes from the library are loaded.

Generally we prefer the second approach though it certainly needs much 
more effort. We also believe that a lot of Java developers will benefit 
from such a library. Hopefully, this community will help us to 
understand if we're on right track.

Currently we have the following ideas and questions:

1. Implementation issues.

I can suggest the following approaches to implement the library:

a) Reuse JDK 1.7 code as much as possible. That means that standalone 
library is just extracted code from JDK 1.7 with certain modifications 
which make it compatible with older JDKs. This code includes 
java.nio.file package and sun.nio.fs sources available in JDK 
repository, plus all the JNI bindings.

I'm no expert, so this suggestion may seem insane for someone. Here are 
some thoughts on that:

+ Reuse of well-tested and established code base.
+ Minimal effort to support such library for third-party company.
+ If I understand things correctly, such code extraction is in course of 
global JDK modularization scheduled for 1.8 release.
- Library has to include the compiled code for a number of supported 
platforms.
? Is that technically possible?

b) Implement from scratch all the native stuff using JNI/JNA to access 
necessary libraries at runtime. That means that library includes 
java.nio.file API which is backed by java.io.File methods and some 
native functions called via JNI/JNA.

+ In case of JNA library will need just a tiny JNI wrapper, so there 
won't be a lot of native code in distribution.
- Much more effort in developing and supporting this code for 
third-party company.

c) Execute necessary programs for functionality missing in JDK 1.6 and 
older.

+ Some developers avoid to call native functions which can crash the 
whole JVM, instead they prefer executing separate processes.
- Performance penalty for executing a bunch of processes.

2. Test coverage.

No matter what implementation we will choose, reuse of existing tests is 
always an advantage. Especially when we're talking about different 
implementations of the same interface.

Another question: may we reuse java.nio.file QA infrastructure to test 
the library on all supported platforms?

3. License issues.

Licensing could be another great problem for us. Generally it would be 
nice to have Apache-like license for the library, but it seems 
impossible (I'm no expert in this area though). A lot depends on what 
implementation will we choose after all.


Thanks a lot in advance.

-- 
Semen Vadishev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!