Przeprowadzanie manipulacji kodami bajtowymi za pomocą interfejsów API takich jak javaassist modyfikuje pliki klas po kompilacji. Ale jeśli kod Java jest zoptymalizowany, czy modyfikacje nie mogą być wykonane w niewłaściwym miejscu? Czy istnieją sposoby na uniknięcie tego problemu? Czy historia różni się między zwykłą Javą a Androidem?Szyfrowanie kodu bajtowego jest bezpieczne
Typowy program Java jest kompilowany wiele razy. W pierwszym kroku kod źródłowy Java jest tłumaczony na kod Java o kodzie. W drugim kroku kod bajtowy Java jest tłumaczony na kod maszynowy o kodzie.
Szczegóły tego procesu zależą oczywiście od maszyny wirtualnej, która uruchamia kod. Wcześniejsze wersje Javy nie zawierały na przykład tak zwanego kompilatora just-in-time. W tym przypadku kod bajtowy został zinterpretowany jako instrukcja, gdzie manipulacje kodami bajtowymi mogą oczywiście mieć wpływ na wydajność. Ale to nie jest prawda. Zarówno maszyna wirtualna OpenJDK HotSpot, jak i środowisko wykonawcze z Androidem ART i DEX dokonują optymalizacji kodu bajtowego.
Kompilator javac, który tłumaczy kod źródłowy na kod bajtowy, wykonuje bardzo niewiele optymalizacji. Normalnie nie powinieneś martwić się o wpływ translacji na kod bajtowy. Jednak w niektórych przypadkach kod bajtowy wygenerowany przez generowanie kodu runtime może mieć wpływ na wydajność. Dzieje się tak, gdy kompilator just-in-time obserwuje kod bajtowy, który jest trudny do zoptymalizowania. Zazwyczaj jest to spowodowane niepotrzebnymi alokacjami obiektów, które trudno jest zoptymalizować.
Jeśli chcesz wyglądać w szczegółach tej sprawy, dałem tę prezentację gdzie mogę porozmawiać trochę o tym problemie: https://www.youtube.com/watch?v=XMY6HA7_h5Y
chodzi o bezpieczeństwo: Dopóki manipulacji kodu bajtowego nie uszkodzić bajtowy kod, nie ma problemu. Jeśli zepsuje kod bajtowy, wirtualna maszyna języka Java odmówi załadowania klasy z uszkodzonym kodem. Dotyczy to zarówno HotSpot, jak i Androida, które sprawdzają kod bajtowy poprzedzający załadowanie klasy.
Kod bajtowy nigdy nie jest zoptymalizowany, przynajmniej nie na ważne sposoby. –
Nie śledzę twojego dokładnego znaczenia. Masz na myśli, że konwersja z .java do .class przez javac nie wymaga dużej optymalizacji? –
Tak, prawie żadna optymalizacja nie jest wykonywana w tym kroku. Jest to w większości proste tłumaczenie. W rzeczywistości próba optymalizacji kodu bajtowego może zepsuć optymalizacje kompilatora JIT i spowolnić działanie kodu. –