Удалить использование определенных классов Java во время компиляции

Question

Я ищу способ удалить все виды использования определенного класса, включая сам класс, во время компиляции. В основном это форма предварительной обработки, но я бы хотел сделать это без необходимости окружать все экземпляры #ifdebug ... #endif.

Есть ли какой-нибудь инструмент на основе муравьев, который может это сделать? Если нет, может кто-нибудь указать мне правильное направление для того, как написать такой инструмент? (я знаю, что это не мелочь, но если это единственный вариант ...)

Ситуация такова, что у меня есть вспомогательный класс для отладки вызовов функций. Это создается в начале функции, а в конце вызывается. Это приложение JavaME, поэтому я нервничаю из-за накладных расходов, которые увеличивают производительность. У меня уже есть сборка выпуска и отладки, в которой есть директивы препроцессора, использующие ProGuard, поэтому я хотел бы исключить использование этого вспомогательного класса из сборки выпуска. Похоже, что это не может быть сделано с ProGuard.

Answer 1

"Это создается в начале функции, а в конце вызывается."

Если это все в вашем коде, возможно, вам нужно взглянуть на AOP.

или шаблон проектирования состояния для вспомогательного класса, в тестовом режиме он делает одно, а в prod - другое (вроде ничего)

Answer 2

Знаете ли вы, что этот код отладки замедлит работу приложения JavaME? Вы также можете попробовать создать способ условного вызова этих методов отладки.

Еще несколько идей ... Я никогда не писал приложение JavaME, но я предполагаю, что есть способ запустить / протестировать с запуском на реальном устройстве. При таком способе запуска / тестирования, возможно, вы можете использовать Eclipse / Netbeans для отладки вашего кода и использовать правильные точки останова вместо программной трассировки вызовов методов. Никакого вреда для скомпилированного кода в этом случае. Также рассмотрите возможность использования AspectJ для отслеживания вызовов методов, это можно сделать условно после компиляции кода, поскольку AspectJ напрямую изменяет байт-код (не уверен, как это работает с JavaME). Наконец, я слышал о людях, использующих стандартный препроцессор GNU C / C ++ на Java. Я понятия не имею, если это работает, Google поможет вам.

Answer 3

Можно ли создать класс один раз при запуске приложения вместо создания экземпляра для каждого метода? Ваш класс отладки может тогда выглядеть так:

public class Debug // maybe make this a *gasp* singleton?
{
    public static void start(); // called at start of method
    public static void end();   // called at end, probably should be in a finally block

    public static void setDebugMode(boolean debugOn); // turn off for production mode
}

Установите режим отладки на «true» в тестировании, но «false» в производственном процессе. Когда режим отладки выключен, ни один из методов ничего не делает (кроме проверки состояния режима отладки, конечно).

Вы не избегаете накладных расходов на вызов функции, и вам нужно проверять состояние этого логического значения, но вы действительно избегаете прыжков через обручи, пытаясь вообще избежать загрузки класса.

Это потребует дополнительной работы, если у вас также есть многопоточное приложение.

Answer 4

Не совсем то, что вы хотите, но ...
Вы можете разделить ваш код на модули (ядро и отладка, в вашем случае), а затем убедиться, что модули вызывают друг друга с помощью отражения: используйте доступный в ядре интерфейс, создайте класс-оболочку в ядре, который будет скрывать создание экземпляров объекта с помощью детализации отражения / Затем, на производстве, просто пропустите код отладки и сделайте так, чтобы обертка «ничего не делала», если инстанциация не удалась / когда вы установили определенный флаг.

Таким образом, ваши отладочные классы не попадут в рабочий процесс, и вам не придется «статически связываться» с ними, чтобы ваш основной производственный код не заботился. Конечно, это возможно только в том случае, если ваш отладочный код не имеет побочных эффектов, видимых для основного кода, но, похоже, это ваш случай (из описания вашей проблемы).