EclipseのコンパイラとSunのjavacは本当に違います

1568 ワード

前に書いたjdkは確かに正確ではありません.正確な言い方はコンパイラのはずです.jdkの概念が大きすぎます.この投稿は主にコンパイラの違いだけを言いたいので、変えました.
------------------------以下は原文の内容ですが、エラー文字は修正されています------------------------
よく知られているように、Eclipseは自分のコンパイラを持っていて、私たちは一般的にこのデフォルトのコンパイラを使って自分のプロジェクトをコンパイルしています.しかし、このコンパイラはSunのjavacと一致していますか?言わないで、本当にそんな違いがあります.
これは普通のannotationです.


@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Anno {
		
	public String itemName();
	
}

次は普通のクラスで、このannotationを使用しています.


public class UseAnno
{
	@Anno(itemName="test")
	public void testMethod() {
		//
	}

}

この2つのファイルはeclipseでもSunのjavacでコンパイルしてもエラーは発生しません.次にannotationを修正します.


@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Anno {
		
	public String itemName();
	public Integer b = new Integer(2);
}

そしてeclipseでコンパイルし、正常に通過します.実行時にもエラーは発生しませんし、実行時にもannotationで定義された変数を反射的に正確に得ることができます.
しかしjavacでコンパイルすると?エラーが発生し、コンパイルできません.ヒント:
注記Annoがありません.
clinitについては、googleで資料を調べることができます.私が調べた資料はjavacがclinitを処理するときにいくつかのバグがあります.このような状況がこのバグの表現症状の一つかもしれません.
(コンパイラのバグと考えられるのは、eclipseコンパイル後java環境で正しく動作するためです.)
したがって、
1、できれば、eclipseが持っているコンパイラはなるべく使わないようにしましょう.
2、できればNetbeansを使うのが正しいはずですが、結局はSunの手から出たものです.
3、継続的な統合の習慣を身につける.そうでなければ後期になって、javacのコンパイルでいくつかの特性が異なることに気づき、損失が大きくなります.

2.Goパフォーマンスの最適化——コンパイル最適化

条項6:コンパイラによって生成されたデフォルト関数を明示的に拒否