Должны ли программы Java, скомпилированные с отладочной информацией, не использоваться в производственной системе? - PullRequest
11 голосов
/ 13 ноября 2009

Есть ли причина, по которой мне следует избегать компиляции при отладке информации с Javac в моих классах Java для использования на рабочем сервере? Есть ли какие-либо проблемы со скоростью или безопасностью, о которых мне следует знать?

Обратите внимание, что я имею в виду отладочную информацию, такую ​​как номера строк в трассировке стека, а не уровень отладки регистраторов.


Похожие вопросы:

Ответы [ 5 ]

8 голосов
/ 13 ноября 2009
5 голосов
/ 13 ноября 2009

Говоря как разработчик, я бы порекомендовал оставить столько, сколько вы можете сойти с рук. Рассуждение?

Однажды вы столкнетесь с ошибкой в ​​вашей программе, когда имеющаяся у вас информация ONLY является трассировкой стека, и ошибка не может быть воспроизведена по команде, она была совершенно непредвиденной исходными программистами И это ваша работа, чтобы исправить это. Чем больше информации будет доступно в этом стеке, тем лучше! Оставьте всю отладочную информацию в!

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

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

Производительность Я считаю, что с HotSpot это не имело значения.

3 голосов
/ 13 ноября 2009

Если вы имеете в виду информацию о номере строки, для печати следов стека, то, как правило, это хорошая идея. Клиент может вставить трассировку стека в отчет об ошибке, чтобы вы могли с ним работать.

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

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

0 голосов
/ 13 ноября 2009

Я согласен с BalusC в том, что уровни производства в производстве обычно могут быть установлены выше (меньше производительность), чем в тесте. Я думаю, что полное удаление регистрации было бы контрпродуктивным. Даже в рабочем коде возникают ошибки, и вам нужна информация для регистрации, чтобы узнать, что произошло.

Утверждения Assert также не являются большой проблемой, если, конечно, они не являются частью кода, чувствительного к производительности. Вы должны быть в состоянии полностью их исключить, поскольку операторы assert обычно предназначены для проверки того, что не может произойти (если используется правильно). Но переживать неприятности, пусть даже и малые, на самом деле их не нужно.

Я лично считаю, что программное обеспечение, установленное на производстве, должно быть как можно ближе к программному обеспечению для разработки, как это было проверено чаще всего.

0 голосов
/ 13 ноября 2009

Зависит от чрезмерной отладки и чувствительности вашей программы. 90% мира с умеренной отладкой не должны беспокоиться.

Вы также всегда можете использовать препроцессор для удаления кода.

...