Création Jar particulière

Version imprimable

28/03/2007, 09h52
schneidb

Création Jar particulière

Bonjour,

Alors voilà quand je veux faire un jar pour l'utilisateur, j'aimerais que ma ligne dans mon main:

Code:

Thread.setDefaultUncaughtExceptionHandler(new ErrorHandler());

se dé-commente.

Elle permet de récupérer toutes les exceptions non attrapée "correctement" pour qu'elles soient mis dans un fichier de log.

Seulement bien sur j'aimerais ne pas le faire à la maison a chaque fois.
Peut être existe-t-il un outil qui permettrait de le faire via Ant ?

Ps: J'utilise Eclipse :)
28/03/2007, 12h00
maxf1

Tu voudrais que lors de la creation du jar ca te decommente la ligne, fasse ton jar puis ensuite recommenter ton code??

Sinon tu peux p'etre le faire avec un programme ou tu lui precises les fichiers ou sont presente les lignes commentés et qu'il faut qu'il les decommente. Et que seuleument ensuite il compiles tes class et construise ton jar et bien sur que ton prog fasse machine inverse une fois ton jar fini.

Perso je ne connais pas d'outil permettant de faire cela....
28/03/2007, 12h35
adiGuba
Salut,

Pourquoi ne pas utiliser les propriétés Java ?
Code:

1 2 3 if (Boolean.getBoolean("DEBUG")) { Thread.setDefaultUncaughtExceptionHandler(new ErrorHandler()); }
Ainsi, pour "activer" le log il faut utiliser l'option -D de la JVM :

Code:

java -DDEBUG=true -jar tonfichier.jar

Note : sous eclipse, ce paramètre peut être ajouté dans l'onglets Arguments/VM arguments de la boite de dialogue "Run..."

a++
28/03/2007, 13h46
Clorish

Citation:

Pourquoi ne pas utiliser les propriétés Java ?

A la lecture de ce thread j'avais pense a proposer un truc du genre.
Sous delphi, on a des directives de compilation pour ce genre de choses, mais j'ai pas trouve d'equivament dans les recherches sous Java.

C'est donc ca qui remplace les directives de compilation des langages Delphi, C++ , etc ... ?

Citation:

Envoyé par Clorish

C'est donc ca qui remplace les directives de compilation des langages Delphi, C++ , etc ... ?

Java ne possède pas de directives de compilation, mais il est possible d'utiliser les spécificités du compilateur pour aboutir à un résultat similaire.

En effet, lors de la compilation, le compilateur supprimera toutes les bloc de code qui ne seront jamais accessible, par exemple lorsqu'on est sûr qu'on ne rentrera jamais dans un if :
Code:

1 2 3 if (false) { // ceci ne s'exécutera JAMAIS }
Ainsi, dans ce cas le compilateur ne génèrera pas le bytecode associé à ce code.

En l'utilisant conjointement avec des constantes (String ou type primitif en static final) on peut simuler une compilation conditionnelle.

Par exemple on peut utiliser une classe définissant les constantes :
Code:

1 2 3 4 5 public class Directive { public static final boolean DEBUG = false; }
Il suffit de l'utiliser dans un simple if pour que le code soit généré selon la valeur de la constante à la compilation :
Code:

1 2 3 if (Directive.DEBUG) { // Ce code sera compilé ou non selon la valeur de la constante Directive.DEBUG }
Attention, car lors d'une modification de la constante, il faudra recompiler tout le code et non pas seulement la classe dans laquelle elle est défini...

Petit exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 public class Main { public static void main(String[] args) { if (Directive.DEBUG) { System.out.println("DEBUG"); } System.out.println("FIN"); } }
Si on compile avec DEBUG=false, on s'aperçoit très bien que le code du bloc if à disparu lorsqu'on décompile la classe (javap -c Main) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 javap -c Main Compiled from "Main.java" public class Main extends java.lang.Object{ public Main(); Code: 0: aload_0 1: invokespecial #1; //Method java/lang/Object."<init>":()V 4: return public static void main(java.lang.String[]); Code: 0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3; //String FIN 5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V 8: return }
:arrow: La méthode main ne comporte que le code correspondant à :

Code:

System.out.println("FIN");

A l'inverse, lorsqu'on utilise DEBUG=true on retrouve les deux affichages :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 javap -c Main Compiled from "Main.java" public class Main extends java.lang.Object{ public Main(); Code: 0: aload_0 1: invokespecial #1; //Method java/lang/Object."<init>":()V 4: return public static void main(java.lang.String[]); Code: 0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3; //String DEBUG 5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V 8: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream; 11: ldc #5; //String FIN 13: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V 16: return }
A noter que si le corps du if est bien présent, l'instruction conditionnelle elle même n'est pas présent...

a++

28/03/2007, 14h19
Clorish
Citation:
Envoyé par adiGuba

Java ne possède pas de directives de compilation, mais il est possible d'utiliser les spécificités du compilateur pour aboutir à un résultat similaire.

En effet, lors de la compilation, le compilateur supprimera toutes les bloc de code qui ne seront jamais accessible, par exemple lorsqu'on est sûr qu'on ne rentrera jamais dans un if :

Code:

1 2 3 if (false) { // ceci ne s'exécutera JAMAIS }
Oui j'ai rencontre ce phenomene dans Delphi, sous le therme de "compilation optimisée" mais j'ai jamais fait le rapprochement .... Faut dire que si on a des directives ca sert a rien ;)

Citation:

Envoyé par adiGuba

Attention, car lors d'une modification de la constante, il faudra recompiler tout le code et non pas seulement la classe dans laquelle elle est défini...

Bien sur ... D'ailleur pour eviter tout problemes je supprime par batch tous les CLASS avant une compilation. J'ai trop souvent eu des heures de prise de tete sous Delphi a ne pas comprendre pourquoi un code modifié ne marchais pas avant de comprendre qu'il se basait sur une ancienne version pre-compilé.

Citation:

Envoyé par adiGuba

Si on compile avec DEBUG=false, on s'aperçoit très bien que le code du bloc if à disparu lorsqu'on décompile la classe (javap -c Main)

A ce sujet petite question bete : On peux proteger son code ? avec un mdp dans un jar ou autre, car, on peux decompresser un jar et decompiler un CLASS .... c'est genant non ?

Citation:

Envoyé par adiGuba

A l'inverse, lorsqu'on utilise DEBUG=true on retrouve les deux affichages [...]
A noter que si le corps du if est bien présent, l'instruction conditionnelle elle même n'est pas présent...

Normal .... optimisation de code ;)

Voici le code de mon main:

Code:

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
	MainFrame mf = getInstance();
		mf.setVisible(true);		
 
		boolean debug = false;
 
		if (args.length > 0)
		{
			String allValue = args[0];
 
			String[] vals = allValue.split("=");
			if (vals.length > 0)
			{
				//System.out.print(vals[1]);
				debug = Boolean.parseBoolean(vals[1]);
			}
		}
 
		if (debug)
		{
			System.out.println("debug mode OK");
			//	JOptionPane.showMessageDialog(mf, "debug mode actived");
		}
		else
		{
			Thread.setDefaultUncaughtExceptionHandler(new ErrorHandler());
		}

Et celà fonctionne merci beaucoup :)

28/03/2007, 16h06
adiGuba

Citation:

Envoyé par Clorish

On peux proteger son code ? avec un mdp dans un jar ou autre, car, on peux decompresser un jar et decompiler un CLASS .... c'est genant non ?

On peut utiliser un obfuscator pour gêner un peu plus la décompilation, mais même sans cela on est loin d'obtenir le code d'origine...

Sinon il faut passer par un mécanisme d'encryption plus élaboré mais surement plus complexe...

a++
28/03/2007, 16h13
Clorish

donc je me pose 2 question par rapport a un programme binaire :
1- Peut on recompiler directement le code decompilé et en y rajoutant ou supprimant quelques instructions.
2- le code decompilé est il aussi peu clair d'un exe deassemblé ?

Le tout est de pôuvoir creer des programmes commerciaux dont la decompilation ne permettrais pas de trop facilement reperer les instructions de tests des licences pour les deactiver et recompiler le programme :(

bref java est il un langage dedié aux logiciels opensources ;)
29/03/2007, 10h18
schneidb

Citation:

Envoyé par Clorish

bref java est il un langage dedié aux logiciels opensources ;)

Pour moi non, preuve en est si on essaye de décompiler une API (déjà faut arriver à récupérer le jar...), si un obfuscator modifie bien les classes je peux te garantir que ca devient l'usine a gaz.

Exemple rien que pour une vérification de clé.
Si on a deux classes nommées "A" l'autre "B" extends "A", que les noms des méthodes ne sont pas parlantes... Sa en découragera déjà beaucoup :)

Ensuite reste toujours l'option de validation d'une clé via un serveur externe.
Reste le problème de disponibilité réseau Internet.
29/03/2007, 10h29
Clorish

ok :)
je regarderais ca de plus pres le temps voulu ;)
Par contre quand tu parle d'arriver a recuperer un jar tu entends quoi par la ?
C'est une archive compresse tout a fait exploitable via winrar et je me demande meme si ya pas une option dans jar.exe, java.ex ou javac.exe pour extraire les fichiers d'un jar ...
29/03/2007, 15h07
schneidb

Parfois il n'est pas simple de récuperer le fichier Jar, je dit bien *parfois* : on ne trouve qu'un fichier exe magouillé.
Mais je crois alors que celà forme un tout qui comporte:
- le jdk
- le jar
- et tout ce qu'il faut.
29/03/2007, 15h20
Clorish

ok ... mais alors la ca sous entends que l'on a passe motre soft a la moulinette d'un autre soft ....

Parce que sinon un jar classique genere par la commande "jar.exe" ... c'est plutot simple a extraire ;)
29/03/2007, 15h25
adiGuba

Citation:

Envoyé par Clorish

Parce que sinon un jar classique genere par la commande "jar.exe" ... c'est plutot simple a extraire ;)

A extraire oui...

Mais la décompilation ne donne pas forcément un code compilable ni forcément très lisible... et si tu as utiliser un obfuscateur c'est encore moins lisible !!!!

a++
29/03/2007, 15h28
Clorish

ok merci :)
29/03/2007, 15h40
schneidb

Ce que je veux dire c'est:
Que tu as alors uniquement une executable et pas de fichier jar. L'exe contenant tout ou partie de ce qu'il lui faut pour faire tourner l'application (Jar seul ou contenant le jdk). Pas d'execution par java.exe -jar Monaplli.jar alors.
Voilà j'espère c'est plus clair.

Par contre je me souviens plus du nom du soft qui faisait celà.
EDIT: http://www.download.com/3001-2417_4-10561332.html c'était peut être celui ci
29/03/2007, 16h01
Clorish

ok :) merci ;)

Je verrais ca plus tard quand j'en aurais besoin :p
En attendant je note ca dans un coin :D