son - librerias de java netbeans

¿Por qué algunos métodos de biblioteca Java delegan a un método nativo con una firma casi idéntica?

Question

Después de profundizar en el código fuente de la biblioteca JRE, noté una estructura de código extrañamente común, como esta:

public int foo(double bar) {
return foo0(bar);
}
private native int foo0(double bar);

¿Cuál es el propósito de este patrón de código y por qué se usa en lugar de simplemente exponer el método nativo subyacente como público?

Answer 1

La versión nativa es solo un detalle de implementación.

Este patrón separa la interfaz pública del método de la implementación real.

Veo al menos 5 razones por las cuales esto es útil:

• propósito de la prueba (puede burlarse de la llamada al método java)
• implementación alternativa: una versión particular de la biblioteca java puede implementar ese método en forma pura de java sin necesidad de llamar a la implementación nativa (común en el código swing).
• compatibilidad con versiones anteriores: si en una nueva versión, el método acepta algunos parámetros adicionales, la firma original del método java puede conservarse y la implementación nativa puede adaptarse.
• validación de entrada / salida: la mayoría de las veces, antes de llamar a la versión nativa, el código de Java hará algunas verificaciones en los parámetros de entrada y lanzará una excepción si es necesario.
• aislamiento: la cantidad de métodos que utilizan directamente el código nativo es limitada, lo que permite más cambios en la estructura interna del código.

Probablemente puedas encontrar más ventajas.

Answer 2

private native int foo(double bar);

Entonces, eventualmente esto tiene que llamar a una función C ++ para su implementación. En particular, terminará llamando a una función con un nombre similar a:

Java_MyClass_foo

¿Qué sucede si hay varios métodos foo nativos con diferentes firmas? Complicaciones Si lo hace, Java agregará información de tipo al nombre del método que busca. Pero es simplemente más fácil si se apega a métodos no sobrecargados.

public int foo(double bar) {
return foo0(bar);
}
private native int foo0(double bar);

foo0 se le ha dado un nombre único, nunca debería haber una razón para agregar otro foo0 . Esto mantiene la implementación de C ++ simple, nunca tiene que lidiar con nombres destrozados. Incluso si eventualmente foo gana una sobrecarga, llamará a foo1 lugar de foo0 y la implementación de C ++ JNI no tendrá que lidiar con las complicaciones adicionales de la sobrecarga.