C#では、プロジェクトをビルドする2つのモードがあります:Debug
とRelease
、Javaは同じものを持っていますか?IntelliJを使用していますIDEA as Java IDEそして、これまでのところ、VS IDEのようにビルドモードを構成するための場所を見たことがありません。
javac
-g Generate all debugging info
-g:none Generate no debugging info
-g:{lines,vars,source} Generate only some debugging info
コンパイルされたクラスにデバッグシンボルを含めるか(これがデフォルトです)、または含めないかを選択できます。それを行わないことには多くの利点はありません。 jarファイルは 少し小さい になりますが、パフォーマンスのメリットは最小限に抑えられます(ある場合)。これらのシンボルがないと、スタックトレースで行番号を取得できなくなります。 ローカル変数名を含む追加のシンボル を含めるオプションもあります(デフォルトでは、ソースファイル名と行番号のみです)。
Java
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
実行時にアサーションを有効にすることもできます(デフォルトはオフ)。これは、開発およびテスト中に役立つ場合があります。これはパフォーマンスに影響を及ぼします(問題のコードが実際にアサーションを使用した場合、私は ncommon だと思います)。
これらの設定に関係なく、JVMでは常にデバッガをアタッチできます。
Javaにないものは、条件付きコンパイルであり、完全に異なるコードがいくつかの外部設定に基づいてコンパイルされます。取得できる最も近いのは、コードのどこかにpublic static final boolean DEBUG_BUILD = true;
のようなものであり、それを使用しますこれにより、実際にはコンパイラが到達不能になるコードを除外しますが、この定数をソースコードで設定する必要があります。
Javaでのすべてのリリースはデバッグ可能な方法です。難読化が必要な一部のプロジェクトでは、リリースビルドが存在する可能性がありますが、12年間の開発ではこれを見たことがありません。 Java。
アサーションやデバッグメッセージなどは通常、本番環境インスタンスの実行時にオフになりますが、必要に応じていつでも(動的にでも)オンにすることができます。
私見では、同じソースだけでなく同じJARでも、すべての環境で同じビルドを使用することをお勧めします。これにより、テストで機能する場合は本番環境で機能し、本番環境で問題が発生した場合はテストで再作成できる可能性が最も高くなります。
Javaコードはこのように記述されているため、JITは呼び出されないデッドコードの最適化に非常に優れています。IMHOがマイクロ "ベンチマーク"のほとんどの場合Java outはC++を実行します。これは、ベンチマークが何もせず、JITがこれを検出するのに優れている場合です。IMHO、C++は、開発者が何もしないコードを記述しないように十分に賢いと想定しています。
あなたは私が推測するさまざまなものでコンパイルするためにさまざまな種類のビルドを求めています。たとえば、Debug.WriteLineとConsole.WriteLineがあります。
「いいえ、Javaはその機能と完全に一致していません。アスペクトを使用するか、IOCコンテナを使用して異なる実装クラスを挿入することができます。 "これを次の質問から盗みました: 条件付きJavaコンパイル
(そこにあなたのための他の素敵な答えがあります)