Jakie są zalety zaciemnienia kodu wydania?

Konkretny przykład, który mam na myśli, dotyczy obecnie alfa gry Minecraft, ale myślę, że jest to ogólne pytanie, które uzasadnia rozmowę.

Minecraft jest napisany w Javie, a ślady stosu zwykle wyglądają tak (prawdziwy przykład):

java.lang.NullPointerException
    at d.a(SourceFile:247)
    at gi.b(SourceFile:92)
    at bd.a(SourceFile:33)
    at bn.a(SourceFile:69)
    at bn.e(SourceFile:115)
    at bn.d(SourceFile:103)
    at net.minecraft.client.Minecraft.i(SourceFile:1007)
    at net.minecraft.client.Minecraft.run(SourceFile:596)
    at java.lang.Thread.run(Unknown Source)

Oczywiście nie są to prawdziwe nazwy pakietów i metod, których programista używa podczas pisania. Ponieważ jest on w fazie alfa, wydaje się, że deweloper powinien mieć możliwość śledzenia śladów stosu, szczególnie jeśli ktoś jest w stanie podać jeden raport o błędzie. W tej chwili jest to w większości bez znaczenia.

Jaką korzyść można uzyskać, zaciemniając jego kod w taki sposób, że przezwycięża on wady trudniejszej identyfikacji błędów?

Również zaciemniamy nasz kod Java ....

Zaletą jest to, że trudniej jest dokonać inżynierii wstecznej (jeśli martwisz się, że ktoś ukradnie twoją bazę kodu i użyje jej jako podstawy do stworzenia podobnego konkurencyjnego produktu, na przykład itp.).

Możesz odzyskać oryginalny ślad stosu: istnieją narzędzia zaciemniania, które tworzą specjalne pliki referencyjne, których możesz użyć do uruchomienia zaciemnionego śladu stosu, i wychodzi on z oryginalnym śladem stosu źródłowego. Są one generowane przez sam proces zaciemniania, więc nie możesz odzyskać oryginalnego śladu stosu, chyba że masz w ręce plik referencyjny, którego użyłeś do zaciemnienia kodu.

To naprawdę nie ma wad. :)

• chroniąc twoją własność intelektualną

Większość zaciemniaczy optymalizuje również kod , usuwa niepotrzebne metadane lub nieużywany kod, kompresję, eliminację martwego kodu lub eliminację duplikatów.