Discussion :

[ToTo13]

Bonjour,

j'utilise depuis peu JNI afin d'accélérer certains traitements.
TOUT ce qui je fais avec JNI, je peux aussi le faire avec Java car j'ai le code en double.
Ce qui je souhaiterai, c'est pouvoir au lancement de mon appli
- scanner toutes les classes de ma librairie
- détecter les méthodes natives
- si la librairie native existe et que la méthode existe dans la librairie native
-----> Pointer sur la méthode native
-----> Pointer sur la méthode java

Quelque chose du genre :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
public static void mamethode()
{
// Appeler la méthode native si elle a été détectée au lancement du programme, sinon la méthode java.
}
 
private static void mamethodenative() ;
 
private static void mamethodejava()
{
// mon code java
}

J'aimerai éviter de faire un test à chaque appel de la méthode.

Est ce que quelqu'un aurait une idée ?
Merci par avance.

[joel.drigo]

Salut,

Premièrement, tu peux déterminer si une méthode existe dans une classe et si elle est native, par réflexion :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public boolean isNativeMethodExists(Class<?> klass, String methodName, Class<?>...parameterTypes) {
   try {
      final Method method = klass.getMethod(methodName, parameterTypes);
      return Modifier.isNative(method.getModifiers());
   } catch (NoSuchMethodException | SecurityException e) {
      return false;
   }
}
 
public boolean isNotNativeMethodExists(Class<?> klass, String methodName, Class<?>...parameterTypes) {
   try {
      Method method = klass.getMethod(methodName, parameterTypes);
      return !Modifier.isNative(method.getModifiers());
   } catch (NoSuchMethodException | SecurityException e) {
      return false;
   }
}

Reste à "scanner" les classes. Ceci normalement n'est pas possible en Java. 2 solutions :

• Utiliser une variable (liste, tableau) pour stocker toutes les classes à analyser (donc qu'il faut initialiser à la main)
• scanner les fichiers .class dans les dossiers du classpath, ou scanner les entrées des jar s'y trouvant
  Ce que tu peux faire avec ces méthode :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  public static List<Class<?>> getClassesFromPackage(String packageName) throws IOException, URISyntaxException{
     return getClassNamesFromPackage(packageName).stream()
                                                 .map(className-> toClass(className))
                                                 .filter(c->c.isPresent())
                                                 .map(c->c.get())
                                                 .collect(Collectors.toList());
  }
   
  private static Optional<Class<?>> toClass(String className) {
     try {
        return Optional.of(Class.forName(className));
     } catch (ClassNotFoundException e) {
        e.printStackTrace();
        return Optional.empty();
     }
  }
   
  public static List<String> getClassNamesFromPackage(String packageName) throws IOException, URISyntaxException{
     final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
     final List<String> names = new ArrayList<String>();;
   
     final String jarPackageName = packageName.replace(".", "/");
     final URL packageURL = classLoader.getResource(jarPackageName);
   
     if (packageURL==null) {
        throw new IllegalStateException("Not found: "+packageName);
     }
     if("jar".equals(packageURL.getProtocol())){
   
        final int start = packageName.length()>0?packageName.length()+1:0;
   
        // build jar file name, then loop through zipped entries
        String jarFileName = URLDecoder.decode(packageURL.getFile(), "UTF-8");
        jarFileName = jarFileName.substring("file:/".length(),jarFileName.indexOf("!"));
        try( JarFile jf = new JarFile(jarFileName) ) {
           for(Enumeration<JarEntry> jarEntries = jf.entries();jarEntries.hasMoreElements(); ){
  	     String entryName = jarEntries.nextElement().getName();
  	     if ( entryName.startsWith(jarPackageName) && entryName.endsWith(".class")){
                  entryName = entryName.substring(start,entryName.lastIndexOf('.'));
  		if ( !entryName.contains("/") ) {
  		    names.add(packageName+"."+entryName);
  		}
  	     }
           }
       }
     } else if ( "file".equals(packageURL.getProtocol()) ){
        final File folder = new File(packageURL.toURI().getPath());
        final File[] content = folder.listFiles();
        if ( content!=null ) {
           for (File actual : content) {
  	    String entryName = actual.getName();
              entryName = entryName.substring(0, entryName.lastIndexOf('.'));
              names.add(packageName+"."+entryName);
           }
       }
     }
     else {
        throw new IllegalStateException("Cannot extract class from " + packageURL);
     }
     return names;
  }

[ToTo13]

Merci beaucoup pour ces informations.

Je suppose que pour tester si une méthode java déclarée "native", pointe bien sur vers une méthode native, il faut tenter de l'appeler. Correct ?

Une idée comment pointer efficacement sur l'une ou l'autre des méthodes ?
Pointer sur une classe ou une autre est facile avec des interfaces, mais des méthodes... pas d'idée :-(

[joel.drigo]

En gros, tu voudrais savoir si l'appel d'une méthode native va soulever une UnsatisfiedLinkError ?

Je pense qu'on devrait le faire en amont, au moment du chargement de bibliothèque native (System.loadLibrary()), en chargeant le bon jar (voir URLClassLoader) en fonction de l'echec ou non du chargement de bibliothèque native (en faisant 2 jar identiques, l'un avec les classes avec les méthode natives. l'autre avec les classes avec les méthodes non natives, mêmes noms, mêmes packages, mêmes méthodes, même signatures, etc.). Plus besoin de scan ou de test : il te suffit de programmer avec l'un des deux jars (de préférence le non natif pour faire les tests dans l'IDE) dans le classpath, mais de ne pas l'exporter dans le classpath, mais en intégrant les 2 fichiers jar dans le jar de l'application.

Sinon, je ne sais pas si on peut tester si l'appel d'une méthode native va soulever une UnsatisfiedLinkError. La méthode bourrine serait d'appeler la méthode et en cas d'exception rediriger vers la méthode non native.

On pourrait faire ça par réflexion, mais on perdrait l'avantage de pouvoir tester les types des paramètres à la compilation (sans parler de la completion), donc il faudrait faire attention aux paramètres qu'on passe (et on ne sait qu'on s'est planté qu'à l'exécution), ou alors il faudrait faire un handler pour chaque couple de méthodes, avec les bons paramètres (du coup, plus vraiment d'intérêt de scanner). On pourrait aussi générer ces classes en avance, ou éventuellement dynamiquement au lancement de l'application.

Ou alors faire un handler avec des lambdas, mais on est obligé systématiquement de duppliquer l'appel, et puis ça peut devenir lourd d'écrire tous les appels comme ça, sans parler des enchainements d'appels...

Genre quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class CallHandler<T> {
 
	private boolean callNative=true;
 
	public T call(Supplier<T> nativeCall, Supplier<T> nonNativeCall) {
 
		if( callNative ) {
			try {
				return nativeCall.get();
			}
			catch( UnsatisfiedLinkError e ) {
				callNative=false;
				return nonNativeCall.get();
			}
		}
		else {
			return nonNativeCall.get();
		}
 
	}
 
	public static class Test {
		public native int nativeTestMethod(int param);
		public int testMethode(int param) {
			return param;
		}
	}
 
	public static void main(String[] args) {
 
		Test test=new Test();
 
		System.out.println(new CallHandler<Integer>().call(()->test.nativeTestMethod(100), ()->test.testMethode(100)));
 
	}
 
}

[ToTo13]

Oui, j'ai l'impression qu'il n'y a pas de solution facile :-(
Dans mon cas je n'ai que peu de méthodes natives et elles sont toutes dans la même librairie.
Je pense à une solution du type
- une interface qui désigne les classes ayant des méthodes natives
- scan de toutes les classes
- les classes qui implémentent l'interface ont une méthode static qui teste chaque méthode native et fait le lien qu'il faut. Dans ce cas le lien serait un simple test sur un booléen.

C'est moche, c'est long, mais simple.

En tout cas merci pour tes réponses.

[joel.drigo]

- une interface qui désigne les classes ayant des méthodes natives

A la place, tu peux parcourir simplement toutes les méthodes de classes pour tester si l'une est native.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public static boolean hasNativeMethod(Class<?> klass) {
   for(Method method : klass.getMethods()) {
      if ( Modifier.isNative(method.getModifiers()) ) {
	  return true;
      }
   }
   return false;
}

- les classes qui implémentent l'interface ont une méthode static qui teste chaque méthode native et fait le lien qu'il faut. Dans ce cas le lien serait un simple test sur un booléen.

Pourquoi mettre une méthode statique dans chaque classe : une seule suffit pour l'ensemble des classes. Ou alors tu as besoin de traiter des informations spécifiques pour chaque classe et chaque méthode native. Peut-être qu'un fichier descripteur à part pourrait faire l'affaire. Ou alors une annotation (mais je ne sais pas si on peut faire une annotation sur une méthode native). Peut-être un aspect serait la solution (pour rediriger l'appel vers la méthode non native si c'est ce que tu cherches à faire).
Par contre, je ne comprends pas ce que tu veux dire par "le lien serait un simple test sur un booléen".