update 071006 「パッケージディレクトリ内でのプログラムの起動」を追加 パッケージに属するクラスとクラスパス パッケージに属さない、というかpackage宣言のないクラスのクラスパスは、そのクラス(クラスファイル)があるディレクトリです。しかし、パッケージに属するクラスのクラスパスは、そのクラスのクラスファイルがあるディレクトリの「ルートディレクトリ」です。このことは、Javaの基本ドキュメントの随所にちゃんと書かれているのですが、私のような鈍い人間は、実際に痛い思いをしないと身にしみません。 以下に、その痛い思いの経緯を、簡略化した例で説明してみましょう。 【前提】私同様、多くのかたのCLASSPATHには、カレントディレクトリがドット'.'で指定されていると思います。その前提で話を進めます。 その指定のないかたは、javacやjavaを動かす無オプションのコマンド
最近知ったこと。 いや、『Java魂』(O'REILLY)を読んだから知ってるはずだけど忘れていた事実。 public static final String HOGE = "hoge";のような定数への参照は、コンパイル時にバイナリファイルにインライン展開される。 (HOGE を参照している箇所は、"hoge" という値が直接バイナリファイルの該当箇所に書き込まれる。) この仕様は、バイナリ互換性を保つための要件として Java の言語仕様で記述されている。 『The Java Language Specification, Third Edition』 http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html 「13.1 The Form of a Binary」 より References to fields t
Javaの定数がインライン化される理由は、実行時に switch 文のラベルの定数値に重複がないことをコンパイル時に保証することにある。 次のリンク先には Javaの定数がインライン化される理由について書かれている。 トップ 同じことが書籍『Java言語仕様 第3版』にも次のように記されている。 (定数のインライン化が必要な理由の1つとして,switch 文ではそれぞれの case が定数を要求し,こういった定数値には重複が許されていないからである。コンパイラはコンパイル時に switch 文中の重複した定数値の有無をチェックする。 class ファイル形式は case の値に対してシンボル・リンクを行わない。)Java言語仕様 第3版 — P.309 13.4.9 final フィールドと定数 よって、次の3つのファイルがあったとき、 Main.java はコンパイルエラーとなる。 //
FindBugs とは、プログラム中に存在するバグを検出するツールです。 プログラミングで問題となり得るバグパターンを検知し、ユーザにそれを知らせます。 以下、FindBugs が定義するバグパターンの一覧と簡単なサンプルコードを示します。 対象バージョンは 1.2.1 です。 Limy Eclipse Plugin を使えば、Findbugsによるコードチェックを簡単に行えます! Bad practice このカテゴリのバグパターンは、「バッド・プラクティス」。 良くないコード記述法を指します。 AM: Creates an empty jar file entry 空のjarファイルを作成しています。 putNextEntry() メソッド呼出の後、すぐに closeEntry() を呼び出しています。 jar圧縮するコンテンツは putNextEntry() メソッドを呼び出した後で
http://www.eclemma.org/jacoco/ EclEmmaで使っているカバレッジ測定用ライブラリ(というかエンジン?)。EclEmmaはEclipseプラグインだけど、JaCoCoはライブラリなのでAntやMavenからも利用できる。 カバレッジ測定といえばCoberturaが有名どころなんで「何も今さら」な気もするけど、JaCoCoはon the flyでカバレッジの測定ができるのがうれしい(instrumentメンドイんだもの)。on the flyと言えばEMMAでもできるのだけど、用意してあるantのタスクはJaCoCoのほうが使いやすかった。 詳しくは公式ドキュメントを参照するか、githubにサンプルプロジェクト作ったので、そっちを見て欲しい。 → GitHub - masanobuimai/ant-sample-project at 2f1300b1134f
Findbugsはみなさんご存知の通り、クラスやJARファイルを解析して潜在的な問題を探し出してくれる静的解析ツールです。 今のプロジェクトではこのFindbugsを2つのタイミングで実施しています。 EclipseにFindbugs Pluginをインストールし、ビルドと同時にFindbugsを実行 CIのタイミングでMavenでFindbugsを実行 基本的には開発者は前者だけを意識して、後者は開発リーダなんかがプロジェクトの全体状況を把握しているのに使用しています。 ここでEclipseとMaven2の2箇所でFindbugsを実行しているわけですが、この2箇所で同様の設定(同じFindbugsのルールセット)で実行されるようにしておく必要あります。この設定の方法が色々めんどくさい。というかEclipseのFindbugsがあまりいけていない。 Maven2とEclipseのFind
BC: Equals method should not assume anything about the type of its argument (BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS) The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this. BIT: Check for sign of bitwise operation (BIT_SIGNED_CHECK) This method compares an expression such as ((event.detail & SWT.SELECTED
Checkstyle 日本語訳 バージョン 4.1 この日本語訳は Oliver Burn 氏が作成した Checkstyle のドキュメントを同氏の了解のもと、一ユーザが個人的に作成した非公式訳です。 最新版の正式なドキュメントは Checkstyle Home Page (http://checkstyle.sourceforge.net) にあります このドキュメントや Checkstyle が出力する日本語メッセージについてお気付きの点がありましたら翻訳者までお知らせください。 概要 Checkstyle は、プログラマがコーディング標準に従った Java コードを 書くようにするのを支援する開発ツールです。Java コードをチェックする プロセスを自動化し、人間がこの退屈な(しかし重要な)仕事をする手間を 省いてくれます。このため Checkstyle はコーディング標準を強
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く