En réponse à Frederic Mantegazza <mantegazza@???>:
> On Tuesday 08 April 2003 16:28, Adrien Revol wrote:
>
> > Pour voir le code source d'une classe, par contre, il te faut un
> > logiciel qui transforme le bytecode de type ".class" en fichier
> source
> > de type ".java". Cherche "java decompiler" dans google, tu devrais
> > trouver ton bonheur je pense
Il existe aussi JODE entièrement en Java
http://jode.sourceforge.net/
un autre en Perl, et aussi
'jad' qui est natif mais plus difficile à obtenir maintenant.
Mais attention, les décompileurs ne sont pas forcément parfaits. Il reste
encore des lacunes et on obtient des différences avec des expressions
comme MyClass.class.getClassLoader()
ou encore des différences avec les initializer statiques.
Je confirme qu'un jar est un fichier zip. Simplement un jar se distingue
par la présence et le contenu de META-INF/MANIFEST.MF. Voir les
spécifications du jar sur le site de Sun
---------------------------------------
Package java.util.jar Description
Provides classes for reading and writing the JAR (Java ARchive) file format,
which is based on the standard ZIP file format with an optional manifest file.
The manifest stores meta-information about the JAR file contents and is also
used for signing JAR files.
----------------------------------------
Et
http://java.sun.com/j2se/1.4.1/docs/guide/jar/jar.html
Décompiler les classes est très pratique pour déboguer un code non-GPL
fournit par une société mais c'est déjà difficile en soit car on ne
dispose que des noms des classes et éventuellement d'un StackTrace pour
comprendre et localiser un problème.
Je ne parlerai pas des sociétés qui décide d'obfusquer leur jar (renommage
complet des classes et des methodes internes - les interfaces externes
étant préservés)
avec les inconvénients suivants pour le développeur:
- stack trace incompréhensible donc dépendance force vis-à-vis du
support du fournisseur [ bref, il a intérêt à être efficace mais c'est
souvent payant... ]
- conflit entre deux produits obfusqués par le même programme d'obfuscation
car en général il y a une classe de bootstrap au nom fixe...
Pour ne siter qu'un exemple:
- l'ORB RMI/IIOP du jdk 1.3.1 d'IBM livré avec WebSphere 5.0 est obfusqué
- le runtime Java du produit EntireX de SoftwareAG est obfusqué avec
le même prog que l'ORB d'IBM
Comment voulez-vous que cela fonctionne ! Bref, à vouloir protéger son
code, on arrive à la situation stupide de ne pouvoir faire fonctionner deux
bibliothèques dans la même JVM.
IBM supporte Linux. Bien. Cela fait que WebSphere 5.0 fonctionne sous
Linux et que l'on voit de la pub Linux partout. Par contre, faire du Java
avec IBM (avec Linux ou autre) nécessite une bonne dose de patience et
éventuellement un contrat de support.
Voilà pour mon expérience des jar, .class, décompilateur et obfuscateur.
Désolé pour la longueur.
--
Yves Martin
