Java開発者の開発環境（IDE）と言えばEclipseが定番ですが、最近はNetbeansも十分に使う価値のあります。特にSwing(GUI)の開発環境（Matisse）により、ちょっとしたアプリケーションにGUIを簡単に提供できるようになりました。また、Swing・JVMのパフォーマンス向上だけでなく、PC性能の向上の恩恵も受け、Swingは遅いというのも過去の話です。 ところが、Swingに関する情報はそのほとんどがコンポーネントに関するノウハウであり、アプリケーションを作るノウハウがほとんどありません。そこで、ここ１年くらいで蓄積してきたNetbeansでのGUIアプリの構築のノウハウを何回かに分けて書いていこうと思います。 実行環境について 結論から言えば、現時点ではSwingのアプリケーションを開発する場合、Java5をターゲットにします。 理由はMac OSを動作環境としたい
Java変態文法最速マスター - プログラマーの脳みそが面白かった && 参考になったので便乗してリスペクト。変態世間であまり見かけない(かも知れない)Javaコードを、過去のエントリからまとめてみました。 nullでなければループ 「配列がnullでなければループ」というシーンはまれにありますが、nullチェックのためにインデントが深くなるのが我慢ならん、というときにこういう記述はどうでしょう。 String[] strs = // 略 // 配列がnullでなければ各要素に対して処理を実行 if ( strs != null ) for ( String str : strs ) { // 処理 } if文の「{}」を省略してforを繋げているだけですが、インデントをさりげなく削れます。 似たような例で、「例外を無視して次へ」とかも。 // 例外が発生しても無視して次へ for ( S
Java基礎文法最速マスター - いろいろ解析日記をリスペクト。 Javaの変態文法・技法一覧です。Javaの基礎をある程度知っている人はこれを読めばJavaの変態をマスターしてJavaを書くことができるようになっています。簡易リファレンスとしても利用できると思いますので、これは足りないと思うものがあれば教えてください。 1.基礎 エンクロージング型内部classの作成 外部classのインスタンスに紐付くインスタンスを生成します。外部クラスのインスタンス - 内部クラスのインスタンス間に、クラス - インスタンスのような関係を持たせることができます。 public class Outer { public class Inner { } } というようなクラスを作った場合、 Outer o = new Outer(); Inner i = o.new Inner(); となります。new
最近、こことかこことかこことかで、Javaの検査例外に関する議論が話題になっているようだ。検査例外に関しては、自分も以前から一言言いたいと思っていたので、ちょっと書いてみることにする。とはいえ、他の人と同じ論点で書いてもつまらんので、ここではちょっと違った視点から。 まず、意識しなければいけないのは、 検査例外という概念そのものが良くない Javaの検査例外の仕様、つまり検査例外の特定の実装がマズい この二つを区別すべきだということだ。実用的に使われている言語で検査例外を実装しているのがJavaしか実質存在しないこともあって、この二つの区別が曖昧になっている場合が多いように思う*1。 このエントリでは、前者についてはとりあえず置いておいて、後者、つまり、Javaの(現在の)検査例外の仕様がイケてない点について述べたいと思う。 例外の型を透過的に扱う手段が存在しない 文だけだとわかりにくいと
HelloWorldやっても面白くねーんだよ！！ 皆さんこんにちは。 Google App Engine （GAE）でJavaがサポートされ、 PythonはスルーしたけどJavaならやりたい！でもJava未経験！ GAE/Jに手を出してみたけど、結局hello, world!のサンプルアプリを公開したまま 放置した状態になっていませんか？ 僕はそうです！ Java使えたら楽しいだろうなー Java覚えて仕事の案件こなしたいなー Java使えたらオブジェクト指向がもっとわかるだろうなー リア充へのあこがれ と、常々思っていつつも、Javaの最初の面倒臭さの前にいつもやる気喪失するんですよね。 HelloWorldひとつやるのにpublic static void main()書くなんて面倒臭すぎです コンパイルなんて面倒でやってられません eclipseの使い方憶えるのが面倒だし ecli
技術ネタじゃないところで盛り上げてしまった。技術ネタいこう、技術ネタ。 さて、JUnitを使う際、hamcrestライブラリを使って、英語として読めるようなassertionを書く、なんてのは流行ってたり流行っていなかったり？ JUnit4限定だけれど、assertionの際、assertEqualsとか色々assertionのメソッドはあるけど、全てassertThatで書くことができるはず。assertThatメソッドの第一引数にテスト対象、第二引数にhamcrestのMatcherインターフェイスの実装を与えます。なんのこっちゃですが。 Jiemamyでは、なるべくassertThat以外のassertionメソッドを使わないようにテストを書いています。（もしかしたらもう一つも残ってないかも。） まぁ、以下のように書くと、英語っぽいのが書けますよ、と。 assertThat(aaaa
プロパティファイルが肥大化してきたので、ResourceBundle 使用時のメモリ効率が気になってきた。ムズムズと。 ResourceBundle クラスで読み込んだプロパティファイルのデータは、メモリ上に保持される。そのため、一度ファイルからデータを読んでしまえば、次回からのプロパティデータへのアクセスでは、IO に関するオーバーヘッドが無くなる。素敵だ。 しかし、ここで気になるのは、もしプロパティファイルに大量のデータがあった場合、メモリが食い潰されてしまうのではないかということ。 国際化対応に使われるくらいだから、ある程度のデータ量にも十分耐えうる仕組みを採用しているだろうと予想しつつも、そこで貴重なメモリ領域が、それなりに使われているのは確か。 で、ソースを追っていったら、読み込む bundle をソフト参照(SoftReference)で保持していた。つまり、メモリのことは J
Eclipse Ganymedeでテンプレートがかなり便利になりました。 具体的には コンテキストが細かく指定できるようになった Java/JavadocだけじゃなくてJava statements, Java type membersとか 変数の属性が指定できるようになった 引数とか型とか 別のところに命令を出せるようになった インポートの追加など あたりがパワーアップしてる模様。 テンプレートは Preferences の Java > Editor > Templates で編集できます。 if (hoge == false) ... まずは簡単なのから。if (!hoge) が読みにくいので if (hoge == false) と書くスタイルにやっと慣れてきましたが、少しでもタイプ量減らしつつ頭の中を整理するためにこんなテンプレート作ってます。 if (${condition:v
バグ修正はプログラマの仕事の一つですが、このうちのかなりの時間は問題を再現することに費やされます。 症状からバグの全容が推察できる時もあるのですが、多くの場合には、手元で問題を再現し、更なるデータを集めることによって始めてバグが理解されるからです。しかし、環境に依存する問題などは再現が難しい場合もあります。どうしたらよいでしょうか。 ロギングというのがよく行われる解決・予防策ですが、「デバッガを走らせて変数xの値を教えてくれればいいのに！」と思った事があるのは私だけではないと思います。ロギングと異なり、デバッガは予めプログラムに障害発生を予期するコードを埋め込んでおく必要はありません。また、呼び出し元のローカル変数をアクセスしたり、任意の式を評価したり、あるいは変数の値を変更することもできてしまいます。当たり前ですが、障害分析ツールとしてはデバッガはずっと強力だからです。 ではなぜユーザー
EclipseでJUnit4を使ってみると、けっこう面倒だと思ってしまう。それは、Eclipseの非常に便利なimport自動編成機能（Ctrl+Shift+O）と、Java5から導入されたstatic importとの相性が悪いからだ。たとえば、JUnit4を使って、 import static org.junit.Assert.*; import static org.hamcrest.Matchers.*; ･･･中略･･･ @Test public void onePlusOneEqualsTwo() { int sum = 1 + 1; assertThat(sum, is(equalTo(2))); }というテストを書いていて、なにか別のクラスを使おうとしておもむろに「Ctrl+Shift+O」を押すと、static importの部分が以下のように展開されてしまう。 impo
Stringクラスのカノニカライゼーションがどのように実装されているか気になったので調べていたのですが、ソースをみたらString#intern()はnativeで実装されている。そういえば新人の頃に調べて同じところで行き詰った記憶があります。ソースがだめならってことでJava言語規定を読んでいたんですが、あまり細かく書いてない。 解説なぞないものかと見てみても、意外に無い。みんな気にしないところなのか？俺だけなのか？ だってさ、「new String」したら無駄にメモリが使われるところまでは納得いくけどその後その変数にsubstringとかしたらその変数って駄目なほうのMapに入るのか既存のMapに入るのかとか超きになる。ほかにもソースコードに書いた文字列ってどうやってStringクラスになるのかとか、でっかいシステムだとStringのMapって数10万のエントリを保持することになるから
そうか。やはりgenericsの機能追加は失敗だったか。 以下のサイトで言われているのでやはりと確信してしまった。 http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java 私の主張はシンプルです。Javaは極めて有効に機能していますが、それは80対20の法則にあたっているからです。私の考えでは、今までで最もわかりや すい80対20の技術の勝利一つです。次の20％を埋めようという試みは、たいてい害の無いものでした。ジェネリクスまでは。ジェネリクスは大失敗でし た。 Javaの習得や理解は難しくなりましたが、それを避けることはできないのです。 http://d.hatena.ne.jp/Kazzz/20071225/p1 ワイルドカードは、JavaのGenericsのワイルドカード(?記号)のことを指してるのだ
2000年あたり、PHP4やJSP1.0が出たころ、PHPよりもJavaがよいと言っても、「Javaは動かせる安いサーバーがない」ということで、サーバーの確保が容易なPerlやPHPが使われました。 Javaを使うには、一台まるごと借りれる割高なレンタルサーバーで、自力でTomcatなどをインストールする必要がありました。そういった状況はしばらく続き、「PHPならば安く借りれるサーバーがたくさんある」ということから、PHPがよく使われるようになりました。 PHPの普及初期では、サーバーの確保が容易なことがPHP採用の大きな理由のひとつだったと思います。 こういう状況は最近まで続いたけど、Amazon EC2のおかげで「Javaは動かせる安いサーバーがない」という問題は解決してきました。Amazon EC2を借りても自力でTomcatなどをインストールする問題がありましたが、HerokuやS
久々にJavaな話題。昨日社内で、 「Servletの中でresponse#getOutputStream()や#getWriter()したストリームは、自分でclose()する必要があるの？それともclose()せずに放置が正解なの？」 という質問を受けた。僕は「自分で獲得したリソースは自分で明示的に解放すべき」という考えが基本にあり、思い返すと、doGet()やdoPost()メソッド内でちゃんと自分でclose()するコーディングを長年に渡って行ってきた。flush()に関してもclose()したタイミングで行われるだろうし、初期のアホコンテナに対しては、ちゃんと後処理を行ってくれないんじゃないか、という不信感があったため、いつも自分でclose()を明示的に呼んでいた。 でも、昨日質問を受けて、果たしてclose()を自分でする必要があるのか？コンテナにclose()は任せる必要が
今日始めて知りました。誠に申し訳ない。 File.renameTo()は、Linux上ではrename()システムコールを使って実現されます。rename()システムコールは、ファイル実体はそのままで、ファイルのメタ情報のみを変更してrenameを実現します(故に高速)が、これができるのは同一パーティション上(同一ファイルシステム上)のみです。 ここまではまぁ、知ってみれば成る程合点が行くのですが、気に入らないのは、上記理由で失敗した時のJDKの挙動です。renameTo()の返り値はbooleanで、この場合はfalseが返るのですが、これだけではなぜ失敗したのかわかりません。ここはExceptionをスローすべきだと思うんですが。何か深い理由があるんでしょうか。 とりあえず、.NETのようにjava.io.File.moveTo()メソッドを実装してほしい。こういうところでは.NETの
Java6 の java.io.File#renameTo(File) のjavadocには以下のような記述がある。 この抽象パス名が示すファイルの名前を変更します。 このメソッドの動作の多くの部分は、本質的にプラットフォーム依存です。名前の変更操作では、ファイルをファイルシステム間で移動できないことがあります。この操作は不可分でないことがあります。また、移動先の抽象パス名を持つファイルがすでに存在する場合は、この操作が成功しない可能性があります。名前の変更操作が成功したことを確認するために、常に戻り値を調べるようにしてください。 Oracle Technology Network for Java Developers | Oracle Technology Network | Oracle まさか不可分でない可能性が…。VMの実装による違いって怖い。アプリからすると悩ましいところ。でも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
