[java] opruimen ongebruikte methodes/objecten

[Alarmnummer]

Is er ook een tool of een manier waarmee je erachter kan komen of je ongebruikte methodes of objecten hebt? Ik geloof dat IntelliJ zoiets kan en obfuscators ook. Maar hier moet je over het algemeen wel dik voor betalen.

[mbravenboer]

Hum ja, die zijn er wel, maar ik weet geen naam/link .... Misschien eens zoeken op dead-code elimination/removal en Java?

Wel uitkijken als je ook reflectie gebruikt .

[Alarmnummer]

De meeste zijn op bytecode maar ik zoek er een op source code nivo. En hij moet ook zeker niet gaan hakken in de code, maar alleen alle methodes/objecten displayen die niet aangeroepen worden.

[mbravenboer]

Alarmnummer: De meeste zijn op bytecode maar ik zoek er een op source code nivo.

Compileren en daarna decompileren

[Verwijderd]

Zijn die decompilers niet de shit voor je code dan? Ik heb ooit gedecompiled met jad, maar daar werd ik toch niet echt blij van...

[mbravenboer]

minne: Zijn die decompilers niet de shit voor je code dan?

Merk de en de op .

[Verwijderd]

Ik dacht ook al: ben ik nou gek geworden?

[CyeZ]

Kun je in je programma niet aan de Garbage Collector opvragen hoeveel 'garbage' er nog is?
Als ik JBuilder gebruik is er in ieder geval een Runtime.gc class ergens te vinden. Ik weet alleen zo niet of dit een standaard routine is die altijd te gebruiken is (ik vermoed eigenlijk van niet, en dat het zo'n JBuilder-only class is).

[mbravenboer]

CyeZ: Kun je in je programma niet aan de Garbage Collector opvragen hoeveel 'garbage' er nog is?

Het gaat hier niet om runtime garbage, maar om garbage van de programmeur .

Ongebruikte methodes en klassen zorgen voor een grotere applicatie en nemen dus alleen maar ruimte en tijd in beslag. Als je deze even snel en automatisch kunt laten verwijderen voordat je een applicatie distribueert, is dat best handig .

[Alarmnummer]

Op zondag 03 februari 2002 12:40 schreef mbravenboer het volgende:

[..]

Het gaat hier niet om runtime garbage, maar om garbage van de programmeur .

Ongebruikte methodes en klassen zorgen voor een grotere applicatie en nemen dus alleen maar ruimte en tijd in beslag. Als je deze even snel en automatisch kunt laten verwijderen voordat je een applicatie distribueert, is dat best handig .

En ze maken code lastiger te onderhouden omdat er dus methodes inzitten die je wel aan het 'upgraden' bent terwijl het niet meer hoeft. En doordat je extra methodes hebt wordt het ook lastiger om je code te doorzien.

[tomato]

Een tooltje om ongebruikte classes te vinden is natuurlijk zo gemaakt. Ongebruikte methods vinden ligt nog iets ingewikkelder (ik ken er trouwens geen bestaande tooltjes voor).

[mbravenboer]

tomato: Een tooltje om ongebruikte classes te vinden is natuurlijk zo gemaakt.

Dat gaat nog niet meevallen denk ik .

Allereerst kunnen er dubbele klassenamen voorkomen.... Dus je kunt niet simpelweg wat met reguliere expressies gaan doen. Je moet de imports van een klasse ook meenemen.

Daarnaast ga je nog gruwelijk de mist in als je dynamisch klassen instantieert voor bijvoorbeeld een soort plugin architectuur.

Als je methoden wilt gaan doen stuit je nog op veel meer moeilijkheden: je moet dan in feite een volledige type-checker hebben en je moet rekening houden met overloading, noodzakelijke methoden ivm met interfaces, invocatie via interfaces, invocaties vanuit gecompileerde code (library bijv) (die je in feite niet kan nagaan) en last but not least: invocatie via reflectie.

Dat laatste wil je dus in ieder geval niet doen .

Als je zoiets wilt gaan schrijven moet je het in ieder geval doen op basis van bestaanden componenten (parsers, type-checkers, pretty-printers, toevoegingen van semantische informatie), anders ben je voorlopig nog niet klaar .