United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4844847 : ByteBuffer APIs for JCA/JCE crypto

Details
Type:
Enhancement
Submit Date:
2003-04-08
Status:
Resolved
Updated Date:
2003-05-16
Project Name:
JDK
Resolved Date:
2003-05-16
Component:
security-libs
OS:
generic
Sub-Component:
java.security
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:
5.0 (tiger)

Related Reports
Relates:
Relates:

Sub Tasks

Description
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

                                    

Comments
EVALUATION

Will submit a CCC for Tiger.

###@###.### 2003-04-08
                                     
2003-04-08
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b07
tiger-b14


                                     
2004-06-14



Hardware and Software, Engineered to Work Together