十年一昔といいますが、文字通り一昔前の書籍ではJ2EEのEJBコンポーネントはプロセスが分散化されたリモート呼び出しにより処理を行う分散コンポーネントとして説明されています。そして、残念ながら現状Java EE関連の日本語の書籍はこうした古い時代に書かれたものがほとんどとなっています。それゆえ、 開発効率がきわめて悪い 実行性能が悪い*1 仕様がきわめて複雑で理解が大変 といった悪いイメージが定着してしまっているのではないかと思います。しかしながら、最新バージョンのJava EE6では、Spring、Guice、SeamなどのOSSの軽量コンテナのアイデアを取り込むことにより、以前とは比較にならないくらい開発効率が改善されているという事実があります。 ここでは、Hello WorldのEJBの書き方を以前の古いバージョンから順次振り返りながら比較してみることで、EJBのプログラミングモデル

DDDで設計を始めると不変条件を維持するために、エンティティなどの可変オブジェクトの複製を行うことがよくあります。 Javaの場合は、Cloneableインターフェイスを実装して、実装型に応じた複製インスタンスを返すcloneメソッドを作る。以下のような感じ。 public class Employee implements Cloneable { private String name; // setter, getter 省略 @Override public Employee clone() { try{ return (Employee)super.clone(); } catch (CloneNotSupportedException e){ throw new Error(e); } } } このcloneメソッドは便利なので普通に使っていたのですが、最近、簡単に使ってよいのだ

長い文章になってしまったので、概要だけ先に書きます。 以下のJavaプログラムは、常に上から下に順番に命令が実行されると思いますか？つまり、aに1が格納された後に、bに2が格納されると思いますか？ 実は場合によってはこの実行順序が入れ替わる場合があります。これはJavaの言語仕様として定義されていることです。これを考慮しないと信頼性のある並行処理は実装できません。 気になる人は以下を読んでみてください。 a = 1; b = 2; すでにインターネットは社会インフラ化しています。ソーシャルネットワークで多くの人とコミュケーションやコラボレーションできる時代で、個人が情報を作り消費することは当たり前になってきています。そして、インターネット上のコンテンツは増加の一途を辿っています。「情報爆発」なんて言葉も耳慣れた言葉になりましたが、その問題解決のためにMapReduceなどの分散処理技術に注

もっとJavaEE6っぽくやってみよう 昨日のエントリでは、AsyncContextの使いかたを試すため、サーブレットだけを使って実装してみました。 でも、すこし泥臭いコードも多くなっていたし、このまま実用的なコードにしていくときにゴテゴテとコードを継ぎ足していくというのもイヤな感じです。 そこで、もっとJavaEE6っぽいコードに書き換えてみましょう。 少し準備 今回は、JAX-RSでのRESTful Webサービスと、CDIでのインジェクションを使ってみます。 JAX-RSの準備 まずは、JAX-RSを使うための設定クラスを作成します。 package chat2; @javax.ws.rs.ApplicationPath("rs") public class ApplicationConfig extends javax.ws.rs.core.Application { } こういう

Cometとは？ ブラウザベースのチャットをつくろうとする場合、以前は定期的にクライアントからリクエストを送信して更新を確認するという手法がとられました。そうすると、平均して更新間隔の1/2の遅延が発生し、更新がないときの問い合わせが無駄になるなど、ユーザーにもサーバーにもうれしい手法ではありませんでした。 そこで使われるようになったのがCometです。 Cometは、HTTPでクライアントからの接続への返答を保留して、サーバーからデータを送信する必要がでたときに返答を返すことで、サーバーからのリアルタイムデータ送信を行う手法の総称です。 Servlet3.0でのComet対応 Cometでは、クライアントからの接続を保持しつづけるので、これまでのServletの仕組みをつかって実現しようとすると、各接続にスレッドを割り当てることになり、スレッド数が多くなりすぎるため、多くのユーザーには対

はじめに 今やWebのフレームワークと言えば、そのほとんどが「RoRタイプ」です。RoR（Ruby on Rails）がWebの開発に与えた影響は非常に大きく、その後生まれたフレームワークの多くがその影響を受けています。 しかし、Javaの世界に関しては、RoRはなぜか素通りしてしまいました。既にStrutsというデファクトスタンダードがあったために新しいMVCフレームワークが割り込む余地があまりなかったのか、あるいはLL（ライトウェイト）言語でないとRoRなスタイルは作りにくかったのか。ともあれ、その後、長い間、Javaでは「いわゆるRoRタイプ」と言えるフレームワークは登場しませんでした。 その流れを変えたのは、Groovyです。Groovyの登場により、JavaでもLL言語のような小回りの聞くコーディングが可能となりました。そのおかげで、ようやくJavaの世界にも遅まきながら新しい世

モックライブラリ使ってますか? 僕はJavaの人なので、主にJUnitを使ってテストコードを書いています。テストコードを書いている最中、「もしこのオブジェクトから例外が帰ってきたら、ちゃんと例外のハンドリングができてんの？」等々、既存のオブジェクトの振る舞いを差し替えたくなることってありませんか？そういうときにモックライブラリを使うと、既存のオブジェクト処理を差し替える事ができます。 実は最初はモックライブラリって意味あるの?と懐疑的だったんです。どういうところに懐疑的だったかというと、 テストコード中に出てくるモックライブラリのセットアップがめんどい。 テストコードがプロダクトコードの実装に依存しちゃうんじゃないの？プロダクトコードをちょっと変えただけでテストが落ちるようになるんじゃないの？ みたいなところです。でもMockitoというモックライブラリを使ってテストコードを書き初めてから

前回、前々回と割とヘビーな仕様の話だったので、今回は若干実用的なネタとして、シングルトンパターンの遅延初期化をメモリモデルの視点から、どのようにすればスレッドセーフになるか考えてみたいと思います。 そのシングルトンの遅延初期化はスレッドセーフか 以下のようなシングルトンパターンは日常的に使うデザインパターンの一つだと思います。 ただ、今回はSingletonクラスのgetInstanceメソッドに、わざとロックを掛けずに実装してみました。この場合にどういうことが起こりうるか考えてみたいと思います。 public class Singleton { private static Singleton instance; public static Singleton getInstance() { // バリアがない if (instance == null) { // Normal Load

国内で国内向けのアプリケーションを作っている限りは、タイムゾーンを意識することはほとんどありません。しかし、Google App Engine等を利用する場合、多国対応のアプリケーションを作るためにはタイムゾーンを正しく扱うことが必要不可欠です。というわけで、タイムゾーンをGAE/Slim3を使う場合に考慮すべき事をまとめました。 デフォルトのタイムゾーン Javaの場合、システムで持つデフォルトのタイムゾーンがあり、普段は暗黙的に利用されています。開発環境とプロダクション環境ではデフォルトのタイムゾーンが異なります。 開発環境 +0900 Asia/Tokyo プロダクション環境 +0000 UTC ※開発環境のタイムゾーンはシステムに依存します。 デフォルトのタイムゾーンを指定する GAE上を使うけどアプリケーションは国内向けであるのであれば、デフォルトのタイムゾーンを変更するのが簡単

元ネタはこちらですが、「優れたJavaプログラマ」を見分ける質問ではありません*1。次のような状況を想定してください。 受託業務を中心にしている弊社は、Javaで業務系ウェブアプリケーションの開発を行う事になりました。しかし社内のリソースを使うにも１−２名足らない事が見積もりから解っています。そこで、中堅エンジニアを1−2名募集することになりました。正社員か派遣かは問いませんが、経験が３年程度の中堅プログラマが必要です。同等またはそれ以上のスキルを持つ正社員がプロジェクトを牽引しますが、ゼロから教えながら教育することはできないので、必要最低限のスキルを持っていることが条件になります。 こんな状況を想定して、面接の質問を考えてみました。経験が３年程度あれば、問題なく答えられるはずです*2。尚、質問はホーム言語がJavaである前提です。 下記質問にそれぞれ50文字以内を目安に簡単に説明すること

Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす

はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ

「あばばばばばばばば」 はい、この記事は、「じゃば あばばばば かれんだー - 邪 2010」の9日目、12/21日のものですのよ? 昨日は、id:nekopのBytemanによるJava黒魔術 - nekopの日記でした。このBytemanが利用している「Java(TM) java.lang.instrument」を利用したもうひとつの例として、JRebelというプロダクトを利用した動的なクラス再ローディングについて、ちょいと紹介しようと思いますのよ奥さん? そもそもjava.lang.instrument APIってなんぞ? Instrument APIは、監視／観察の対象となるアプリケーションのバイトコードをほかのバイトコードに置き換える（BCIを行う）ための枠組みを提供する。置き換えの方法としては、以下の2とおりが提供されている。 ●クラスがロードされる過程に割り込み、そのバイトコ

SpringやStrutsやGoogle Web Toolkitなど、たくさんあるJava VM対応のWebフレームワーク。どれがどのような特徴を持ち、何を選べばいいのでしょう？ 11月15日から行われたJava開発者が集うイベント「Devoxx 2010」。このイベントで行われたMatt Raible氏によるセッション「Comparing JVM Web Frameworks」（JVM Webフレームワークの比較）のプレゼンテーションが、同氏のブログにポストされたエントリ「My Comparing JVM Web Frameworks Presentation from Devoxx 2010」で公開されています。 その内容は、開発者の方々に非常に参考になるのではないかと思うので、全56枚のプレゼンテーションの中からポイントとなる部分を紹介します。 評価優秀とされたのはSpring、GW

こんな感じででけた。もしこのコードを試すのであれば、ラーニングテストなので、適宜org.junit.Testをインポートしてね。 @Test public void exitしないことを確認しよう() throws Exception { System.setSecurityManager(new SecurityManager() { @Override public void checkExit(int status) { throw new SecurityException(); } @Override public void checkPermission(final Permission perm) { } @Override public void checkPermission(final Permission perm, final Object context) { }

「標準出力に結果を出すプログラムをJUnit 4.1でテストする方法」について書きます。 テスト対象となるプログラム(Hello.java) たとえば、以下のようなプログラムHello.javaがあったとしましょう。 public class Hello { public static void main(String[] args) { System.out.println("Hello!"); System.out.println("http://www.hyuki.com/"); } }これは次のようにすれば、普通にコンパイルと実行ができます。 C:\work> javac -version Hello.java javac 1.5.0_06 C:\work> java Hello Hello! http://www.hyuki.com/ 懸念事項 テスト（ここではJUnit 4.1

JavaによるRESTfulシステム構築 作者: Bill Burke,arton,菅野良二出版社/メーカー: オライリージャパン発売日: 2010/08/23メディア: 大型本購入: 28人 クリック: 804回この商品を含むブログ (40件) を見る これ，本当にタイトル勿体無いなぁって思う本でした． いや，タイトルに偽りは無いんだけど，これだと REST に興味無い人は手に取らないだろうなぁと思って，それは凄く勿体無い内容なので，ホントみんな読むと良いと思う． 簡単に説明すると，Java で REST を扱うために JAX-RS という API があるんだけど( JSR311 )，そのエキスパートグループの一人であり，さらにその実装である RESTEasy の作者が書いている本です． で，この人は元々 SOAP とかのどちらかというと Fat な仕様大好きっこだったので，この本には色