[java] Gebruik van goto en andere lompe zaken

[RedLizard]

Hallo,

ik heb een groot java programma door een decompiler gehaald. Aangezien het programma zo groot en ingewikkeld is, spuugt mijn decompiler echter GOTOs uit waar het de nette structuren niet kan achterhalen. Ik heb [voorlopig] geen behoefte om het hele programma uiteen te rafelen, ik wil alleen wat aanpassingen maken. Het probleem is echter dat de java compiler geen GOTO's slikt.

Ik heb het programma door een hele rits decompilers heengetrokken, maar niet een kon het zonder gebruik te maken van GOTOs. Dus een andere decompiler proberen is waarschijnlijk niet de oplossing. Weet iemand manieren om GOTOs alsnog toe te staan in de java compiler?

[Voutloos]

Eerste vraag aan jou is dan of jij dan wel aanpassingen mág maken.

[whoami]

Decomplen is niet echt een legale bezigheid....

[RedLizard]

Hmm, had ik even geen rekening mee gehouden. Het lijkt erop dat de eula het er inderdaad niet echt mee eens is.

Overigens is decompilen an sich niet illegaal, maar dat is een ander verhaal.

[MisterData]

whoami schreef op maandag 07 maart 2005 @ 19:50:
Decomplen is niet echt een legale bezigheid....

Je eigen code decompilen vooralsnog niet hoor

[Brakkie]

whoami schreef op maandag 07 maart 2005 @ 19:50:
Decomplen is niet echt een legale bezigheid....

Lijkt me niet dat dat per definitie zo is, hij heeft de schijn alleen wel tegen zich

[whoami]

MisterData schreef op maandag 07 maart 2005 @ 19:54:
[...]


Je eigen code decompilen vooralsnog niet hoor

Je eigen code niet, maar dit is niet z'n eigen code.
Trouwens, waarom zou je je eigen code willen decompilen, als het goed is, heb je de source gewoon.

[RedLizard]

Je eigen code decompilen kan overigens ook zinnig zijn, namelijk als je de code om reden naar keuze verloren bent. Of voor POC-redenen.

Maar ik moet toegeven dat het niet mijn eigen code is in dit geval.

Off-topic:

hoe zit het juridisch trouwens precies? Hoever mag ik gaan? Mag ik decompilen? Disassemblen? etc

[whoami]

Palinchron schreef op maandag 07 maart 2005 @ 20:04:
Je eigen code decompilen kan overigens ook zinnig zijn, namelijk als je de code om reden naar keuze verloren bent.

Dan ben je dom bezig; als je gebruik maakt van en source-control system is de kans op verloren code toch al heel wat ingeperkt.
Trouwens, dan nog zal je afaik nooit identiek dezelfde/originele code kunnen bekomen.

[Verwijderd]

Dit maakt het verschil tussen een debug en een release build. Bij een release build wordt het programma optimaliseert en het verliest het de object-structuur die de ontwerper erin heeft gestopt. Variabelen herken je vaak ook niet terug .
Bij een debug build is het daarom handig juist niet de code te optimaliseren. Verder wordt er een mapping-file aangelegd zodat je met de broncode ernaast tracen kan. Een debug-build werkt dan ook zoals je het programma geschreven hebt.

Dit zie je bij alle compilers terug. Je wil niet weten wat C++ met je lieve class-designtje doet .

[Alarmnummer]

Verwijderd schreef op maandag 07 maart 2005 @ 20:23:
Dit maakt het verschil tussen een debug en een release build. Bij een release build wordt het programma optimaliseert en het verliest het de object-structuur die de ontwerper erin heeft gestopt. Variabelen herken je vaak ook niet terug .

Met java valt dat heel erg mee. De optimize flag heeft zelf geen werking meer voor de compiler.. de classfile is dus een bijna directe afspiegeling van de sourcecode. Je zult echt een obfuscator over de classfiles heen moeten gooien om het goed onleesbaar te maken.

[ Voor 9% gewijzigd door Alarmnummer op 07-03-2005 20:31 ]

[Nick_S]

Praat me niet van een obfuscator. Ik werk nu met een adapter generator voor Tibco. Dit is een sdk, die dus obfuscated is. Dan staat er een rits klassen, methoden en variabelen in je Eclipse autocomplete! Daar wordt je echt niet goed van en het programmeert ook niet lekker.

[Alarmnummer]

Nick_S schreef op maandag 07 maart 2005 @ 20:57:
Praat me niet van een obfuscator. Ik werk nu met een adapter generator voor Tibco. Dit is een sdk, die dus obfuscated is. Dan staat er een rits klassen, methoden en variabelen in je Eclipse autocomplete! Daar wordt je echt niet goed van en het programmeert ook niet lekker.

Dat kan ik me goed voorstellen. Ik heb er vroeger wel eens mee gespeeld. Voor de software die ik nu schrijf is het niet nodig om code te obfuscaten aangezien het mijn debugwerkzaamheden extreem veel lastiger maakt en omdat onze klanten de source toch kunnen krijgen.

[Verwijderd]

Je wilt je eigen code wel eens decompilen om te zien wat een compiler ervan gebakken heeft en of enige optimalisaties weer in te voegen zijn in de oorspronkelijke source-code. Ok, niet echt aannemelijk, maar als je dan toch wat moet verzinnen ;-)

Vreemd eigenlijk dat decompilers een goto gebruiken. Goto bestaat helemaal niet in Java (is een reserved keyword, maar is dus absoluut niet geimplementeerd door een compiler met de te verwachtte betekenis.)

Beetje offtopic, maar voor java/c/c++ etc code generators is goto niet zo ranzig. Die weet namelijk precies de context waarin het gebruik wordt, en dan kan het geen kwaad (assembly/machine code doet nix anders dat gotos gebruiken).

[klinz]

whoami schreef op maandag 07 maart 2005 @ 19:50:
Decomplen is niet echt een legale bezigheid....

Onzin.

Modbreak:

Reageer met onderbouwing of reageer gewoon niet

[ Voor 18% gewijzigd door .oisyn op 08-03-2005 23:01 ]

[Verwijderd]

Verwijderd schreef op maandag 07 maart 2005 @ 21:53:
Vreemd eigenlijk dat decompilers een goto gebruiken. Goto bestaat helemaal niet in Java (is een reserved keyword, maar is dus absoluut niet geimplementeerd door een compiler met de te verwachtte betekenis.)

code:

loopnaam:while(true){
   if(xxx){
      if(voerwatcontroleuit(){
             continue loopnaam;
       } else {
             break loopnaam;
       }
   } else {
        doeMaarIetsAnders();
   }

     nogwatMeerCode();
}

Ok, geen letterlijke goto, maareuhm, ik dacht aan zoiets toen ik dit las...bestaat in JAVA

[.oisyn]

Verwijderd schreef op maandag 07 maart 2005 @ 21:53:
Vreemd eigenlijk dat decompilers een goto gebruiken. Goto bestaat helemaal niet in Java (is een reserved keyword, maar is dus absoluut niet geimplementeerd door een compiler met de te verwachtte betekenis.)

Punt is dat het dus niet in de taal maar wel in de IL zit. Er werd waarschijnlijk geen goto gebruikt, maar door optimalisaties kan de decompiler de originele structuur (bijv. een break uit een for-loop) er niet meer bij kan halen.

[Verwijderd]

.oisyn schreef op dinsdag 08 maart 2005 @ 10:54:
[...]


Punt is dat het dus niet in de taal maar wel in de IL zit. Er werd waarschijnlijk geen goto gebruikt, maar door optimalisaties kan de decompiler de originele structuur (bijv. een break uit een for-loop) er niet meer bij kan halen.

Dat begrijp ik (natuurlijk). Wat ik bedoelde is dat het dus geen echte Java decompiler is, maar meer een tool om bytecode iets leesbaarder te maken. Een echte decompiler zou gewoon legale Java code op leveren.

[.oisyn]

Ah, op die fiets. Maar het wordt nogal lastig als je de originele structuur er niet uit kunt halen. Daarnaast lijkt het me vrij triviaal om de java compiler aan te passen zodat goto wel (weer?) werkt.

[Verwijderd]

Wat zijn trouwens de 'andere lompe zaken'?

[Alarmnummer]

Voor de mensen die eens door hun class files willen browse, zie JClasslib