Currently, the JCA/JCE APIs utilize byte arrays to pass data between applications and the provider implementation. Providers implemented in native code need to access the contents of the byte array via JNI. These JNI functions return a copy of the data in many JVM implementations because of memory management issues (GetPrimitiveArrayCritical, which would usually avoid the redundant copy, typically cannot be used). Experiments have determined that the copy operation may limit performance, in particular when using crypto accelerators.

This could be avoided by using (direct) ByteBuffers as introduced with the NIO APIs in J2SE 1.4. Methods that take ByteBuffer arguments should be added to the JCA/JCE classes that process bulk data:

    messageDigest.update(ByteBuffer input);
    signature.update(ByteBuffer input);
    cipher.update(ByteBuffer input, ByteBuffer output);
    cipher.doFinal(ByteBuffer input, ByteBuffer output);
    mac.update(ByteBuffer input);

The new methods accept both direct and non-direct byte buffers. Provider implementations are required to deal with all cases, including for example a direct buffer as input and a non-direct buffer as output. This also makes it unnecessary to define methods that mix ByteBuffer with byte[] types. Applications should use code like cipher.update(inputBuffer, ByteBuffer.wrap(outputArray)) to achieve that effect if required.

Concrete default implementations of the engine versions of those methods would also be added to the corresponding Spi classes. This ensures compatibility with existing providers that do not implement these methods (and providers who decide not to override them).

This RFE is part of 4635083 (Enhanced security token integration).

###@###.### 2003-04-08