Pourquoi certaines méthodes de bibliothèque Java délèguent-elles à une méthode native avec une signature presque identique?

Question

Après avoir fouillé dans le code source de la bibliothèque JRE, j'ai remarqué une structure de code étrangement commune, comme celle-ci:

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

private native int foo0(double bar);
 

Quel est l'objectif de ce modèle de code et pourquoi est-il utilisé au lieu d'exposer simplement la méthode native sous-jacente en tant que méthode publique?

Answer 1

La version native est juste un détail d'implémentation.

Ce modèle sépare l'interface publique de la méthode de la mise en œuvre effective.

J'en vois au moins 5 raisons pourquoi cela est utile:

• des fins de test (vous pouvez vous moquer de la java appel de méthode)
• la variante de mise en œuvre: une version particulière de la bibliothèque java peut mettre en œuvre que la méthode en java pure forme, sans appel à l'implémentation native (commune de swing code).
• compatibilité ascendante: si, dans une nouvelle version, la méthode accepte des paramètres supplémentaires, l'original java signature de la méthode peut être conservée et le natif de mise en œuvre adaptées.
• d'entrée/sortie de validation: la plupart du temps, avant d'appeler la version native, le code java va faire quelques vérifications sur les paramètres d'entrée et de jeter l'exception en cas de besoin.
• l'isolement: le nombre de méthodes qui utilise directement le code natif est limité, permettant à plus de modifications dans le code interne de la structure.

Vous pouvez probablement trouver plus d'avantages.

Answer 2

private native int foo(double bar);

Donc, finalement, cela a pour appeler une fonction C++ pour sa mise en œuvre. En particulier, il finirez par l'appel d'une fonction avec un nom à quelque chose comme:

Java_MyClass_foo

Qu'advient-il si il y a plusieurs native foo méthodes avec des signatures différentes? Les Complications. Si vous le faites, Java ajouter des informations de type dans le nom de la méthode qu'il cherche. Mais il est tout simplement plus facile si vous vous en tenez à la non-méthodes surchargées.

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

private native int foo0(double bar);

foo0 a été donné un nom unique, il ne devrait jamais être une raison pour en ajouter un autre, foo0. Cela empêche la mise en œuvre du C++ simple, il n'a jamais à traiter avec les noms déformés. Même si foo finalement gagné une surcharge, il appellera foo1 au lieu de foo0 et le C++ JNI mise en œuvre n'aurez pas à traiter avec le supplément de complications de la surcharge.