2010-05-08 3 views
1

J'essaye de créer l'exécutable sous la plate-forme de fenêtres pour le programme de Java en utilisant JNI, C/C++ et invocation API, j'ai déjà créé le dossier de jar pour mon programme qui inclut toutes les dépendances. Je veux l'intégrer dans le fichier exe, j'ai réussi à exécuter la classe principale simple (présent dans le système de fichiers) en utilisant l'API d'invocation JNI, je prévois d'ajouter le fichier jar comme ressource dans le programme C/C++. Mais je ne sais pas comment exécuter ce fichier jar, une option est de créer un fichier jar temporaire sur le système de fichiers et l'exécuter en Java, mais je ne veux pas exposer mon fichier jar à tout le monde pour des raisons de sécurité, fichier jar à la volée en utilisant JNI?Création de Java exécutable en utilisant JNI?

+1

« Je ne veux pas exposer mon fichier jar à tout le monde pour des raisons de sécurité » en le mettant dans l'exe et l'envoi de l'exe à quelqu'un, vous _are_ exposer. –

+0

Oui mais exe ne peut pas être décompilé aussi facilement que bytecode – Xinus

+2

Mais si vous êtes juste emballer le fichier JAR dans le .exe il n'y a pas de « décompilation » nécessaire pour le sortir. – Nate

Répondre

2

La compilation de Java vers un exécutable avec GCJ ne fonctionne pas tout le temps, il existe des limitations en ce qui concerne l'utilisation de la réflexion et d'autres éléments tels que les classes d'interface utilisateur, Look at this page.

Si vous convertissez votre code Java en une bibliothèque ou simplement en un autre module, vous pouvez créer un lien vers celui-ci et simplement l'exécuter sans nécessiter de JVM.

+0

La réflexion devrait fonctionner correctement avec la stratégie que l'OP poursuit. –

+0

@Kevin Day - Je suppose que tu m'as dingué d'avoir mis le reflet là-dedans. Vous n'avez pas suivi mon lien pour pointer vers GCJ. J'ai édité mon post depuis pour le rendre plus explicite :( –

+0

Foire « nough considèrent le ding inversé ;-) –

1

Ma réaction initiale était que je serais choqué si vous pouviez obtenir ce travail et qu'il soit performant. Mais alors j'ai commencé à y penser, et peut-être que vous pourriez le retirer en utilisant un chargeur de classe personnalisée. Si vous incorporez le jar dans l'exe comme une ressource, ce serait exactement la même chose que d'avoir les octets jar présents à un décalage particulier dans n'importe quel fichier (exe ou non).

Alors, voici une stratégie potentielle: mettre en œuvre un chargeur de classe personnalisée qui accepte le chemin exe et décalage de la ressource jar dans ce fichier. Cela utilise une version personnalisée de ZipFile qui utilise un indice décalage fixe pour son lit (malheureusement, il ne va pas être possible d'utiliser ZipFile lui-même - mais si vous prenez la source de ZipFile il devrait être assez évident où vous besoin d'ajouter le décalage).

Il y a un problème de bootstrapping ici (comment voulez-vous charger le chargeur de classe personnalisée?) - mais je pense qu'il pourrait être possible de le faire à partir du côté JNI. Fondamentalement, vous stockez le fichier .class pour le chargeur en tant que ressource distincte dans l'exe, chargez-le entièrement en mémoire puis construisez-le en utilisant les appels JNI. Ce sera un problème, mais c'est juste pour une classe, et ensuite vous pouvez laisser le runtime Java prendre le relais. Cela ressemble à un projet intéressant (bien que, comme d'autres le soulignent, il n'y a pas beaucoup de sécurité dans ce que vous faites ... Je suppose que vous pouvez crypter le pot incorporé et ajouter du code de déchiffrement au classloader, mais vous avez un peu de décider à quelle distance vous voulez prendre cette chose).

Questions connexes