Discussion :

[Mobius]

Je cherche le moyen de compiler des fichiers .class (contenant du byte code java).
Le code ainsi obtenu doit encore pouvoir être chargé par la JVM.

J'ai donc pensé a compilé mes classes en utilisant GCJ qui peut générer une librairie partagé (un fichier .so).

Pour utilisé cette librairie, j'ai pensé charger cette librairie avec la méthode "System.loadLibrary" et pouvoir réécrire une implémentation de la classe en déclarant toutes les méthodes "native".

Voici mon code:

Code :

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

1
2
3
4
5
6
7
8
public class Main {
	static {
		System.loadLibrary("helloworld");
	}
	public static void main(String[] args) throws Exception {
		HelloWorld.sayHello();
	}
}

La méthode HelloWorld.sayHello étant bien déclaré native.

Le problème c'est que j'ai une erreur lors de l'execution

[java] Exception in thread "main" java.lang.UnsatisfiedLinkError: sayHello
[java] at HelloWorld.sayHello(Native Method)
[java] at Main.main(Unknown Source)
[java] Java Result: 1

Si je comprend bien l'erreur, la JVM ne trouve pas la méthode native correspondante.

Pour construire ma librairie partagé, j'ai créé une implémentation (non native) de la classe HelloWorld que j'ai ensuite compilé avec GCJ.
Je suppose que la compilation GCJ n'est pas tout a fait correcte et que le résultat ne respecte pas les convention JNI.

Première question : Est ce faisable ?
Deuxième : Comment ? (je suppose qu'il manque quelque chose lors de la compimation avec GCJ mais je ne sais pas quoi).


PS: Je suis prêt à compiler mon code avec autre chose que GCJ si besoin.

[tchize_]

les classes compilées avec gcj s'utilisent comme toutes les autres classes. En fait, qu'elles soient compilées avec GCJ ou avec javac, elles devraient avoir le meme comportement. System.loadLibrary, c'est pour charger des librairies natives (genre du code C par exemple), pas pour charger des classes java compilées avec gcj. Pour les classes java, ca reste le principe du classpath et des import qui est à utiliser.

[Mobius]

Sauf que par défaut si on utilise GCJ pour générer des fichier .class (option -C), cela compile les classe sous forme de bytecode. J'aimerai pouvoir générer ces classes sous forme de code natif.
Pour le reste je suis d'accord (sauf que du coup ca correspond pas a mon besoin)

[thelvin]

Mais... Du code natif ne peut être lié à du bytecode que par l'utilisation de JNI.

Et Java, ironiquement, est totalement incapable de décrire des fonctions répondant aux conventions de liaison de JNI.

[adiGuba]

Salut,

J'aimerai pouvoir générer ces classes sous forme de code natif.

Ce n'est pas possible ! Un fichier *.class ne peut pas être un fichier natif.

Si tu produit du code natif avec GCJ, il faudra générer un exécutable natif pour pouvoir l'exécuter

a++

[Mobius]

Ce n'est pas possible ! Un fichier *.class ne peut pas être un fichier natif.

D'ou l'idée de compilé mes classes en code natif dans une librairie externe et de faire le lien avec JNI.
Mais cela semble difficilement faisable.
La réponse de thelvin semble confirmer ma crainte.

[adiGuba]

Pourquoi une telle obsession pour générer du code natif ???

a++

[Invité]

Par code natif, tu entends code machine ?
Si oui, à mon avis, il n'y a pas d'autre moyen que de partir du code source d'une JVM opensource car c'est là que se situe le code natif de tout ce qui est lié au systèmes.