decompilet class fil

Jeg glemte lige at sige at det var en class fil jeg havde hentet ud af en en jar fil til en j2me applikation.
QD::

al højniveao kode er propfuld af 'goto' sætninger.
men det er strukturere goto sætninger genereret af compileren.

Jeg vil tippe ovenstående kommer fra en helt normal java struktur som fx en try-catch sætning eller noget i den retning.

Hvad siger du ?? al højniveau sprog fuld af goto ?? Du mener vel lavniveau?? Decompileren burde vel have generet en try and catch af sig selv? Det burde den vel let kunne forstå!
QD::

if ( ( noget && nogetandet) || nogettredie ) {
    sætning 1;
    sætning 2;
} else {
    sætning 3;
    sætning 4;
}
// koden efter if sætningen


vil i en highlevel kompiler blive til noget i retning af:


// if ( ( noget && nogetandet) || nogettredie ) {
        if ( ! noget ) goto L10;
          // shortcut evaluering af betingelse unædvendita t teste 'nogetandet'

        if ( nogetandet ) goto L11;  //betingelsen er sand. udfør THEN blokken
L10:                          // test led efter  ||
        if ( ! nogettredie goto L12;
L11:                          // 'then' blok
//    sætning 1;
        udfør sætning 1;
//    sætning 2;
        udfør sætning 2;
        goto L13;
L12:                          // 'else' blok
//    sætning 3;
        udfør sætning 3;
//    sætning 4;
        udfør sætning 4;
L13:                          // fortsæt her når if-sætning er udført

men da alle de goto er placeret sytematisk så den implementere en kendt og fornuftig kontrolstruktur er de IKKE dårlig kode. koden er bare meget mere uoverskuelig på dette detail-niveao.

mvh JakobA

Jeg vil nødig være den der skal dekompilere helt tilbage til "hvad programmøren skrev".
Java compileren optimerer.

ovenfor har jeg fx optimeret sekvensen imellem L10 og L11. egentlig burde der stå:

L10:
      if ( nogettredie ) goto L11; // gør then
      goto L12;                    // gør else
L11:

men de fleste compilere er smarte nok til at se de kan spare en linie der ved at vende betingelsen.

quaid:

Det ser ud som om JAD ikke kunne finde ud af at dekompile koden.

Lugter af obfuscation af koden, ved hjælp af at men bruger JVM instruktioner i en rækkefølge dekompileren ikke kan genkende.

Jeg er ikke den store J2ME ekspert, men kunne man forestille sig at dekompileren ikke har haft de nødvendige libraries til rådighed? Eller at der er lavet nogle ting i j2me som JAD ikke kender (burde der ikke være, men jeg har som sagt ikke sat mig ind i j2me).
Obfuscation i den form jeg kender det, burde ikke kunne genere dekopileren på denne måde, da det primært går ud på at rename variable og metodenavne og evt. inline kodestumper.

En anden mulig forklaring er at den oprindelige kode har været kompileret med en kompiler der ikke er helt strict og derved har accepteret nogle ode-strukturer der ikke er heeelt fine i kanten, og som JAD derfor ikke forstår (eller forventer).
Prøv evt. med en anden dekompiler, eller prøv at kompilere den dekompilerede kode og se om det går. Så kan du evt. dekompilere din version bagefter. Det er usandsynligt at det går, men ikke helt umuligt.
Håber du kan bruge det til noget.
P.S. Hvad er det egentlig du prøver at dekompilere? Det er vel forhåbentligt noget open source eller noget du selv har skrevet ;-)

Jeg syntes at i alle har bidraget konstruktivt til debatten. Det vigtigste var at jeg kunne se og tyde den del af kode jeg var interesseret i.
Jkrag: Vedr. dit PS ?????!!!!!
QD::

jkrag:
Jeg har selv dekompilet J2ME midlets uden problemmer, JAD æder dem råt.