salut , je viens de tester la fonction du jbuilder 7 qui fait des exécutables natifs pour chaque os , et en fait quelle ne fut pas ma surprise de voir que ce ne sont que des .jar renommés en .exe ...
 
y a d'autre solution pour faire de vrai exe ?

     
 
jbuilder powa sa race  

 
utiliser un vrai langage natif ... VB.Net ?      

DarkLord a écrit a écrit :           jbuilder powa sa race

 
grrrrrrrrrrr

drakkeng a écrit a écrit :     grrrrrrrrrrr

 
c'est encore une idée à la con de vouloir faire des exécutables natifs de toutes façons
y a qu'un utilisateur de JBuilder pour avoir des idées pareilles

DarkLord a écrit a écrit :     c'est encore une idée à la con de vouloir faire des exécutables natifs de toutes façons y a qu'un utilisateur de JBuilder pour avoir des idées pareilles

 
j'utilise tout moi meme IntelliJ idea , je voulais proteger mes class de la decompilation ,et accessoirement accélérer l'exécution.

http://www.excelsior-usa.com/jet.html
 
mais cela utilise toujours la JVM

 
oui je suis en train de l'installer ça fait 3 heures qu'il compile je sais pas quoi

comme pourrait dire darklord : "il optimise ton code pas bo fait par jbuilder"  
 
 

Taureau a écrit a écrit : comme pourrait dire darklord : "il optimise ton code pas bo fait par jbuilder"

 
il est bo mon code car je fais des projets vide avec le jbuilder j'utilise pas ses fonctions de génération de code , je me sert juste de l'edieur .

Pour empêcher la décompilation, il y a le bytecode obfuscator, et pour accélérer l'exécution du bytecode, il y a des JVM plus efficaces, et un bon profileur (OptimizeIt est assez bien fichu, par exemple).

 
C quoi un profileur ?
Quand on obfuscate le byte code par contre, quand une exception se produit, j'imagine que c plus dur de la localiser (la n° de ligne, et les classes/méthodes de la pile sont inninterprétable. Non ?
Pourquoi certaines JVM son plus rapides que celles du JRE, la plus distribuée ? pourquoi plusieurs machines virtuelles ?

 
 
http://proguard.sourceforge.net/
 
 
 
 

 
Au bureau, on me fait coder. je fait du code completement imbitable, on m'appelle l'obfuscateur.

 
ok merci je vais voir , ça .

 
 
.Jar renommé en .exe ???? t sur la ?... paske ca me parait pas executable du tout, vu que .jar=.zip renommé....
 
 

 
chez nous c'est le chef de projet qui remplit cette fonction, on code puis il passe derrière pour obfuscater notre code

 
ben oui car j'arrive a l'ouvrir avec winrar , et je vois mes class dedans.

DarkLord a écrit a écrit :

 
va manger des frites toi

drakkeng a écrit a écrit :     va manger des frites toi

 
t'as compris pq je me marres au moins ?

+1

DarkLord a écrit a écrit :     t'as compris pq je me marres au moins ?

benou i ?

DarkLord a écrit a écrit :     t'as compris pq je me marres au moins ?

 
non , peut etre parce que tu trouves l'expression "ben oui" ridicule car ça fait nordiste ?

ben non, c'est pas nordiste, ca, on l'utilise partout...

 
ça tombe bien car j'habite dans le sud
je voulais brouiller les pistes.

 
a ok c'est ridicule car c 'est normal d'ouvrir un zip en winrar

Non, le bytecode obfuscator se contente de renommer tous les symboles (hormis les noms des classes publiques et leurs méthodes publiques ou protégées) en utilisant un générateur de noms de symboles aléatoires. Les classes "obfusquées" restent décompilables, mais le résultat de la décompilation est très difficile à comprendre pour un humain (ça reste cependant du code Java parfaitement recompilable).
Ceci dit, les piles d'exceptions restent parfaitement valides, et si tu disposes du code source non "obfusqué", tu pourras t'y retrouver.
 
Maintenant, au sujet des JVM : il en existe plusieurs, y compris au sein du J2SDK de Sun : historiquement, il y avait le simple interpréteur de bytecode, puis est apparu le compilateur Just-in-Time Symantec, distribué avec le JDK1.1. Sun a ensuite développé la machine virtuelle HotSpot, fournie avec le JRE depuis la version 1.2, et aujourd'hui diffusée sous le nom de "HotSpot Client" ; elle est déjà nettement plus rapide que le JIT Symantec. Plus récemment est apparue la JVM HotSpot Server,  qui est encore beaucoup plus rapide qu'HotSpot Client. Mais elle n'est distribuée avec aucun JRE (téléchargement séparé), et elle n'est distribuée avec le JDK que depuis la version 1.4.
Point de vue rapidité d'exécution, HotSpot Server donne des résultats vraiment étonnants, et on arrive à obtenir des programmes Java à peine plus lents que les programmes C++ équivalents (1 à 3-4 fois), au lieu de programmes 50 fois plus lents avec l'interpréteur de bytecode historique.
 
Maintenant, d'autres sociétés ou organismes ont préféré développer leur propre JVM plutôt que d'utiliser celle fournie par Sun, typiquement IBM, qui fournit sa propre JVM avec WebSphere, par exemple.

 
Ms avec un code obfuscaté, dans la stack d'une exception, les nom de méthodes et de classes seront pas les originaux !
Et un profiler c quoi alors ?

c'est un truc qui te permet de reperer ou ton programme perd son temps, histoire de savoir ou optimiser.

Si les méthodes sont publiques ou protégées et qu'elles appartienent à une classe publique, si. Sinon, effectivement, elles seront obfusquées. Mais rien ne t'empêche de laisser les numéros de lignes comme seules informations de débogage. Ce qui fait que si tu reçois une pile de la part d'un utilisateur et que tu disposes du source non obfusqué, tu pourras parfaitement interpréter la pile et retrouver chacun des appels dans ton source.
 
Un profileur, c'est un outil qui va mesurer avec précision le temps passé dans chaque ligne de ton source, et le nombre de fois que chacune des lignes de ton source est exécuté.
Cela permet de savoir très précisément quels sont les bouts de ton code qui sont les plus coûteux et/ou les plus souvent sollicités.
C'est donc ces bouts de code-là qu'il faut optimiser en priorité pour accélérer la vitesse globale du programme (ne jamais oublier de vérifier au profileur que l'optimisation effectuée est vraiment efficace...).
Et si une fonction est trop difficile à optimiser (par exemple, parce qu'elle est très courte), mais qu'elle est appelée un très grand nombre de fois, il faut alors essayer de diminuer le nombre d'appels à cette fonction, par exemple en utilisant un cache.
 
Enfin, en fonction du langage, il y a un certain nombre de trucs pour améliorer localement l'efficacité du code. Par exemple, en Java, utiliser java.util.StringBuffer au lieu de java.util.String pour la construction des chaines de caractères, essayer de réutiliser des objets déjà alloués plutôt que faire des "new", etc (ces 2 exemples typiques permettent en outre une consommation mémoire moins gourmande, donc une moindre sollicitation du ramasse-miettes).

Ce topic débile a fini par devenir tres instructif