Discussion :

[Bowser]

Bonjour,

J'ai un programme réalisé avec Java SE 6, sous Windows. Je dispose initialement du jar, mais j'ai pu le dé-compiler pour obtenir la source.
J'aimerai exécuter ce même programme sur une plateforme Unix qui dispose d'un JRE 1.5.

Lors de ma tentative d'exécution directe sous Unix, j'ai eu une erreur m'indiquant des problèmes de versions majeur et mineur.

Je cherche une solution pour rendre portable ce programme et l'exécuter sur le JRE 1.5.
Impossible d'installer le JRE 1.6, la machine Unix est soumis a des protocoles stricts et le Java 6 ne fait pas encore partie des programme autorisés.

Y-a-t-il une possibilité de re-compiler le programme avec un mode de compatibilité Java 1.5?
Avez vous des idées?

Merci pour votre aide.
Cordialement

[tchize_]

tout premier quesiton: avez vous les droit légaux de décompiler cette application? Il est possible si l'application n'utilise pas de fonctionnalités java 6, de compiler en mode compatibilité,

Code :

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

javac -source 5 -target 5 fichier.java

Si je suis bien la logique d'entreprise: java 6 n'est pas autorisé, mais une application java décompilée et bidouillée serait autorisée. Faudra les informer que l'application java aussi devrait alors subit le protocole d'autorisation sinon ca n'a pas de sens (java n'est jamais qu'un lanceur)

[adiGuba]

Salut,

tout premier quesiton: avez vous les droit légaux de décompiler cette application? Il est possible si l'application n'utilise pas de fonctionnalités java 6, de compiler en mode compatibilité,

Code :

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

javac -source 5 -target 5 fichier.java

Attention ! Avec cela on se contente ici de vérifier deux choses :

• Le -source 5 interprétera le langage du code source comme du Java 5. Les "nouveautés" du langage de Java 6 ne seront pas prise en compte (mais ce ne sera pas bien méchant puisque cela se limite à quelques détails).
• Le -target 5 génèrera un bytecode "Java 5", afin qu'il puisse être exécuté par une JVM 5.

Par contre toutes les vérifications des liens se fera par rapport à l'API de la version du compilateur que tu utilises. Donc le bytecode généré risque de provoquer des erreurs sur une vrai JVM 5...

Il faut toujours compiler avec un JDK correspondant à la version minimum que l'on souhaite utiliser.


a++

[Bowser]

Bonjour,

Merci pour vos réponses, ça m'a permit d'approfondir le sujet.

En ce qui concerne les droits de décompilation, le programme a été réalisé en interne (certainement un prestataire), mais mauvaise organisation faisant, nous n'avons plus les sources.
Pour les histoires de bidouilles en accord avec les protocoles, je vais voir ça.

J'ai lu un peu la doc de javac ; tchize_, je pense que tu veux parler des options -bootclasspath et -extdirs qui vont permettre justement de spécifier les bibliothèques externe qui seront nécessaires à l'exécution.

Malheureusement je n'ai pas de javac d'installé sur ma machine, je dispose seulement du JRE 1.6, JRE 1.4 et d'un Eclipse. Le Java 1.5 n'est pas disponible pour les postes de travail... ceci reflète un problème de cohérence dans les protocoles puisque c'est le 1.5 qui est installer sur les productions...

Ma méthode envisagée pour gérer la cross-compilation avec Eclipse : démarrer un nouveau projet Eclipse en indiquant un autre JRE que le 6 (en l’occurrence, le 1.4) ; importer la bibliothèque JRE 6 dans le projet.
Avec mon Eclipse, j'arrive à exécuter le jar initial avec les bons paramètres.
Par contre, lorsque j'introduis le .java dé-compilé, impossible de le re-compiler, il y a des erreurs de syntaxe notamment sur l'utilisation de goto :

Code :

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

if(pAr.length() <= 4) goto _L2; else goto _L1

En effet je vois des marqueurs de _Lx à plusieurs endroits :

Code :

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

1
2
3
4
_L1:
        if(trouve)
            break MISSING_BLOCK_LABEL_243;
        if(true) goto _L3; else goto _L2;

Ceci m'étonne beaucoup, je soupçonne un programme très bidouillé.

Donc :
1) Pouvez vous m'éclairer sur l'utilisation des goto? j'ai cru comprendre que Java n'en utilisait pas. Existe-t-il une manière pour moi de faire reconnaitre par Java ces goto? où serait-ce des maladresses de dé-compilation?

2 ) Est-il envisageable d'exécuter un programme Java 1.4 sur une Java VM 1.6?

Merci pour votre aide.
Cordialement.

[tchize_]

J'ai lu un peu la doc de javac ; tchize_, je pense que tu veux parler des options -bootclasspath et -extdirs qui vont permettre justement de spécifier les bibliothèques externe qui seront nécessaires à l'exécution.

Non j'ai parlé de source et target qui définissent respectivement la version de la grammaire à utiliser en entrée et la version du format .class à utiliser en sortie

Malheureusement je n'ai pas de javac d'installé sur ma machine,

Ben installe / fait le installer. Eclipse sans un jdk ça ne te servira a rien

Ma méthode envisagée pour gérer la cross-compilation avec Eclipse : démarrer un nouveau projet Eclipse en indiquant un autre JRE que le 6 (en l’occurrence, le 1.4) ;

Une application prévue pour java 6 a une marge de chances de fonctionner sous java 5, mais il n'y a presque aucune chance d'arriver à la compiler pour java 1.4. De toutes façons, java 1.4 n'est plus supporté depuis belle lurette.

importer la bibliothèque JRE 6 dans le projet.

Marchera pas, java 4 sera incapable de lire ses fichier puisqu'elle est prévue pour java 6 :/

Avec mon Eclipse, j'arrive à exécuter le jar initial avec les bons paramètres.
Par contre, lorsque j'introduis le .java dé-compilé, impossible de le re-compiler

La décompilation retourne du "pseudo java", il faut encore repasser à la main sur pas mal de code pour avoir un truc ompilable, bonne chance. Mettre java 6 sur le serveur reste quand meme la solution "travail minimum". Au pire tu embarque la jar avec la jvm, une jvm n'ayant pas besoin d'installation. Et tu dis rien à personne au déploiement

1) Pouvez vous m'éclairer sur l'utilisation des goto? j'ai cru comprendre que Java n'en utilisait pas. Existe-t-il une manière pour moi de faire reconnaitre par Java ces goto? où serait-ce des maladresses de dé-compilation?

existent dans la jvm (code binaire) mais pas dans la grammaire. Question con: êtes vous sur qu'a la base c'était du java, et non pas du scala ou du groovy (le deux compilent à destination de la JVM mais ont un language différent).

2 ) Est-il envisageable d'exécuter un programme Java 1.4 sur une Java VM 1.6?

Oui, il y a compatibiltié dans ce sens.

[adiGuba]

@tchize_ : eclipse intègre son propre compilateur et n'a besoin que d'un JRE... même si un JDK reste plus agréable (intégration des sources dans eclipse, etc.)

ceci reflète un problème de cohérence dans les protocoles puisque c'est le 1.5 qui est installer sur les productions...

Tout à fait ! C'est vraiment ahurissant de ne pas avoir la même version en développement et en production !!!!

importer la bibliothèque JRE 6 dans le projet.

Hum... NON ! Tu dois utiliser la bibliothèque de Java 5 au maximum.
Donc si tu ne peux vraiment pas l'installer sur ton poste de dev, tu devras te contenter de l'API de Java 1.4...

Sinon tu risques d'utiliser malencontreusement des méthodes de l'API 1.6

Tu ne dois pas l'utiliser si tu veux éviter les mauvaises surprises...

1) Pouvez vous m'éclairer sur l'utilisation des goto? j'ai cru comprendre que Java n'en utilisait pas. Existe-t-il une manière pour moi de faire reconnaitre par Java ces goto? où serait-ce des maladresses de dé-compilation?

Goto n'est pas supporté par le langage (même si c'est un mot clef).
Par contre il l'est au niveau du bytecode.

Les goto que tu obtiens correspondent sûrement à une structure de contrôle (if, while, for) qui a été décomposé à la compilation.

La décompilation est loin de te rendre le code tel qu'il était, et rien ne garantie non plus qu'il soit compilable (le langage Java est plus stricte que le bytecode)

2 ) Est-il envisageable d'exécuter un programme Java 1.4 sur une Java VM 1.6?

Oui


a++

[tchize_]

@tchize_ : eclipse intègre son propre compilateur et n'a besoin que d'un JRE... même si un JDK reste plus agréable (intégration des sources dans eclipse, etc.)

A force d'utiliser des plugins comme maven qui marchent pas sans un jdk, j'ai tendance à l'oublier

[Bowser]

Merci à vous deux pour vos réponses complètes, ça m'aide beaucoup et c'est intéressant.

Ma première décompilation était effectuée avec JAD. Après plus de recherche je me suis aperçus que c'était très bien pour du Java 1.4 mais pas plus, ce qui doit expliquer mes problèmes.
Je viens d'utiliser JD, et le rendu est bien mieux. Je n'ai plus les goto et le code est bien plus lisible.
Je pensais initialement que le processus de décompilation était "parfaite".

Sous vos conseils, j'ai enlevé la bibliothèques JRE 1.6 de mon projet. Eclipse ne me sort pas d'erreur sur des objets inconnu, seulement quelques petits problèmes que je devrais pouvoir régler à la main.

Question con: êtes vous sur qu'a la base c'était du java, et non pas du scala ou du groovy (le deux compilent à destination de la JVM mais ont un language différent).

-> Est-ce que ces langages produisent des .jar et des .class? de toute façon, avec le résultat que j'ai maintenant en décompilation, je pense que c'est bien du Java. Mais bon à savoir.

Mettre java 6 sur le serveur reste quand meme la solution "travail minimum".

->Tout à fait d'accord, mais je fais face à des lourdeurs et lenteurs administratives... je fais avec les moyens du bord.

Au pire tu embarque la jar avec la jvm, une jvm n'ayant pas besoin d'installation. Et tu dis rien à personne au déploiement

->Je garde ça en tête, mais comment tu "embarques" la JVM avec la jar?

Non j'ai parlé de source et target qui définissent respectivement la version de la grammaire à utiliser en entrée et la version du format .class à utiliser en sortie

->Désolé, ma remarque sur les options de javac était adressée à adiGuba en fait.

Je tente maintenant une correction du code, une compilation en 1.4 et une exécution Windows. Souhaitez moi bonne chance...

Cordialement,