Y a-t-il une raison pour éviter de compiler des informations de débogage avec Javac dans mes classes Java pour une utilisation dans un serveur de production? Y a-t-il des problèmes de vitesse ou de sécurité que je devrais être au courant?
Veuillez noter que je parle de déboguer des informations telles que des numéros de ligne dans les traces de pile, pas le niveau de débogage des enregistreurs.
5 Réponses :
dépend de la précision du débogage et de la sensibilité de la performance de votre programme. 90% du monde avec un débogage modéré ne devraient pas avoir à s'inquiéter.
Vous pouvez toujours utiliser un préprocesseur pour éliminer le code aussi.
Voulez-vous compiler avec l'option de débogage? Existe une différence de performance entre Javac Débug sur et off?
Ah, je savais que cette question allait probablement être une dupe, mais je n'ai rien trouvé dans mes recherches.
Si vous voulez dire l'info de numéro de ligne, pour imprimer des traces de pile, il est généralement une bonne idée de garder cela autour. Un client peut coller dans la trace de la pile dans un rapport de bogue pour que vous puissiez travailler avec.
Si vous êtes vraiment inquiet pour les noms de vos méthodes visibles, vous pouvez utiliser Proguard ou certains autre obfousciateur. PROGUARD a la belle propriété que cela peut déconcerter des traces de pile, afin que les clients puissent toujours les envoyer à vous.
Obfuscation n'est pas parfait, donc si vous ne voulez pas passer les efforts, il n'y a rien de mal à ne pas le faire.
Je suis d'accord avec Balusc que les connexions à la production peuvent généralement être définies plus élevées (moins de rendement) dans la production que lors du test. Je pense que cela éliminerait entièrement la journalisation serait contre-productif. Même dans les erreurs de code de production se produisent et que vous besoin les informations de journalisation pour découvrir ce qui s'est passé.
Les déclarations ASSERT ne sont pas non plus énormément de problème, sauf si bien sûr dans un code de code sensible très performant. Vous devriez être capable de les laisser complètement car les déclarations d'assertion sont généralement pour vérifier les choses qui ne peuvent pas se produire (si elles sont utilisées correctement). Mais en traversant le problème, peu tel qu'il est, pour les sortir n'est pas vraiment nécessaire.
Je pense personnellement que le logiciel, tel que installé dans la production, devrait être aussi proche que possible du logiciel de développement, comme cela a été testé le plus souvent.
La question ne concerne pas la journalisation, la question concerne l'option -g de javac .
Cela souligne que vous devez être critique lorsque vous vous enregistrez pour produire des données utiles.
Parler en tant que développeur, je vous recommanderais de partir autant que vous pouvez vous échapper. Le raisonnement?
Un jour, vous rencontrerez un bogue dans votre programme où la pièce seul l'information que vous avez est une trace de pile et le bogue ne peut pas être reproduit sur commande, il a été complètement imprévu par l'original. Les programmeurs, et c'est votre travail de le réparer. Plus les informations sont disponibles pour vous dans cette pile trace le mieux! Laissez toutes les informations de débogage dans!
Si vous le pouvez, utilisez un cadre de journalisation (pour obtenir les traces de pile à un fichier) qui peuvent fournir des informations sur le fichier jar dans lequel chaque classe a été trouvée. La connexion peut faire cela et je crois que log4j peut aussi.
Vous ne pouvez pas être autorisé d'inclure toutes ces informations, mais je pense que vous devriez d'abord crier et crier et dire qu'il devrait être laissé pour des raisons d'urgence.
Performance dans le cas où je crois que depuis hotspot, cela n'a pas eu l'impression.