Java Developer is a demanded specialty with high salary. This is due to the popularity and reliability of the Java programming language. Deep Understanding of Debugging in Java We break down key concepts and techniques, allowing students to not only identify and fix bugs, but also effectively optimize code to improve application performance. Practical Experience in Real Projects We place great imp
渡辺です。 先日、「JUnitのオブジェクト等価比較を怠けたい!」というスライドが公開されました。「オブジェクトのカスタムアサーションをどのように実現するか」という問題は、ユニットテストを実践していくとよく発生します。この問題に関して、先日のJJUG CCCでも相談されました。また、簡単に書ける仕組みは共有した方が良いのですよね。そんなわけで、cmtestというライブラリにまとめましたので紹介したいと思います。 Objectクラスのequalsメソッド Javaではオブジェクト同士の比較にはObjectクラスのequalsメソッドを利用することが定石です。これはユニットテストのアサーションでも同様です。テストした結果に作られる実測値と、テストの期待値を比較する時、通常はequalsメソッドを利用します。equalsメソッドを使った比較を行うのであれば、定番のassertThat構文を利用で
Javaの常識を変える「Play framework」とは 「Play framework」は、サーバサイドJavaとScalaのためのMVCフレームワークです。この連載では、主にJavaのフレームワークとしてのPlay frameworkを紹介していきます。でも「Javaで、Web向けで、MVCで……」なんて、ありふれた感じですよね。それなら「Scalaで、どう作るのか」という話の方が興味あるという方もいるでしょう。 しかし、Play frameworkはバージョン1まではJavaのフレームワークとして作られていました。また、ScalaはJavaVM上で動作するプログラミング言語です。つまり現在の最新バージョンの2でも基礎の部分で動いているのはJavaです。Play frameworkを知るためには、まず基礎から固めていくのが正攻法だと思います。Scalaについて知りたい読者は、以下の記
Javaのジェネリクスで,型パラメータ T のインスタンスが欲しくなったことはあるだろうか? 昨今のオブジェクト指向プログラミングにおいて,ジェネリクスは必須の基本文法だ。 扱う対象のクラスが抽象化されて汎用的になりつつ,なおかつ型安全性が確保される。 そのおかげで,処理の重複や分岐をコーディングする必要が無くなり,コード量が驚異的に削減される。 そういう基本的な原則を踏まえると, 「型パラメータのインスタンスが欲しい」 というシチュエーションは,Javaのジェネリクスの本来の導入目的に真っ向から逆らう。 なぜなら,ジェネリクスは型を抽象化して透過的に扱えるようにするための機構なのだから, せっかく抽象化した物をわざわざ具体化してどうするというお怒りを生む事になるのだ。 頑張って詳細なクラス情報を「T」でパラメータ化して具体性を隠ぺいしたにも関らず, その T に対して .class で具
Javaのややこしいジェネリクスの話をしよう。*1 再帰的ジェネリクス クラスHogeがあったとして、型変数Tを取る。 public class Hoge<T> {} このHogeの型変数Tがextends Hogeとすると public class Hoge<T extends Hoge> {} すると、T extends Hoge の Hoge が raw型だと警告される。Hogeの<>の部分にHoge型を継承した型を指定しなければならない。ここで型変数T が extends Hogeだったので、丁度いいからT型をおさめよう。 public class Hoge<T extends Hoge<T>> {} これは再帰的ジェネリクス(recursive generics)と呼ばれているようだ。 追記:僕は勝手に自己言及型ジェネリクスなどと呼んでいた。情報サンクス!併せてタイトルなども表現
Javajava-ja@lingrのログを見ていたら、なにやらキーワード引数の話から、マップをサクっと作れないと「流れるようなインターフェース」が作りにくいとかそんな話になってて、「せめてMapのリテラルさえあれば…」とかいう話に行っていました(敷居が高かったので、下に紹介するブログのURLを貼って逃げた(笑))。 JavaにMap生成リテラルが欲しい!という話は結構昔からぽろぽろ出てますよね。たしかにMapがささっと作れるのと作れないのとではMapを使う時のモチベーションが違う。気軽に使えない。 国内はもちろん海外のブログでもそういう話題は上がってまして、私のお気に入りは、odz bufferさんにて紹介されてた、このNicolas Lehuen氏のアイデアです。このアイデアを使うと、下記のようにBuilderみたいに簡単にHashMapを生成できます。 // Example usage
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること(getterやsetterなどは本物の
技術ネタじゃないところで盛り上げてしまった。技術ネタいこう、技術ネタ。 さて、JUnitを使う際、hamcrestライブラリを使って、英語として読めるようなassertionを書く、なんてのは流行ってたり流行っていなかったり? JUnit4限定だけれど、assertionの際、assertEqualsとか色々assertionのメソッドはあるけど、全てassertThatで書くことができるはず。assertThatメソッドの第一引数にテスト対象、第二引数にhamcrestのMatcherインターフェイスの実装を与えます。なんのこっちゃですが。 Jiemamyでは、なるべくassertThat以外のassertionメソッドを使わないようにテストを書いています。(もしかしたらもう一つも残ってないかも。) まぁ、以下のように書くと、英語っぽいのが書けますよ、と。 assertThat(aaaa
昨日、Java 7th moon 富山が開催されました。参加者21名と小規模ながら、会場は非常に盛り上がりました。ああ、凄く楽しい。こんなに楽しいのは久しぶりだ。スピーカーをしてくださった皆さん、参加してくださった皆さん、本当にありがとうございます! LT(ライトニングトーク)で昔のネタを引っ張り出してSemicolonless Javaをやったのだけど、LTなので時間もなく一番アツイ部分が伝えられなかったのでちょっと書いておこう。 歴史 Semicolonless Java(セミコロンレスJava)はJavaのサブセットで、Java言語からただひとつセミコロンを取り除いただけのプログラム言語だ。 この言語自体は1996年にJavaがリリースされたと同時に実装が存在したが、誰にも知られていなかった。この言語が発見されたのは2010/3/21で場所は熱海。java-ja温泉というイベントの2
ジェネリクスでは、「型」を変数にした「型変数」というものを取り扱う。型変数で何が嬉しいかというと、メジャーな例ではコレクションAPIが挙げられる。java.util.Listとかjava.util.Mapとかのデータを格納するタイプのユーティリティクラスのことだ。 2004年にJavaのバージョンが5.0となるまでは、Javaにはジェネリクスの機能はなかった。なので、Listにデータを格納し、取得する場合は List list = new ArrayList(); list.add("hello!"); String str = (String) list.get(0); といったソースコードになる。 add()の引数はObject型で宣言されており、どんな参照型でもadd()することができた。 get()の戻り値もObject型で宣言されておりキャストが必要だった。このキャストはプログラ
このエントリーは、@cero-tさんのエントリーの次で、Java Advent Calendar 2011の6番目のエントリーです。自分自身の今年のメインテーマがTDD(テスト駆動開発)と言う事もあり、関連エントリーとしてJUnitについて書きたいかと思います。今更JUnit?と思われた方も普段からJUnitを使っていあなたも気軽にお読みください。尚、色々な話題を駆け足で紹介するので、どれも簡単な紹介程度になってしまいますが、ご了承願います。 JUnit4 スタイル JUnitがアノテーションに対応し結構な月日が流れましたが、古いコーディング規約のままでテストコードを書いていませんか?JUnit4では、アノテーションとアサーションを使ったテストコードを書くことが基本スタイルです。かつては、TestCaseのサブクラスを作り、testではじまるメソッドを定義していましたが、今は Testアノ
This document discusses usage trends of the Eclipse integrated development environment. It notes that Eclipse usage increased 20% in 2011, with the biggest increases being 10% for Eclipse itself, 10% for plugins, and 200% for Android Development Tools. It then provides many tips and shortcuts for using Eclipse more efficiently.Read less
簡単なアスペクトの使用例 まず簡単な例として、HelloWorldプログラムにAspectJを適用してみましょう。 アスペクトの記述 まず、ごく普通の単純なJavaプログラムであるHelloWorldクラスを用意します。 /** * HelloWorld.java * * @author <a href="mailto:torutk@alles.or.jp">Toru TAKAHASHI</a> * @version */ package hello; public class HelloWorld { public static void main(String[] args) { new HelloWorld().sayHello(); } void sayHello() { System.out.println("Hello world!"); } } // HelloWorld 普
1. 環境別の設定はプロファイルで 環境毎に切り替えたいっていう設定ファイルは大抵のプロジェクトにはあると思います。DB接続先設定だったり、ロギング設定、場合によってはweb.xmlの初期化パラメータとか。最近流行り?のAppEngineだとデプロイ先の設定、開発時のcronの設定とか。こういった環境毎の設定を都度都度書き換えてなんてことをやってたらバージョン管理上うまくない*1ですし、Hudson、その他自動化スクリプトからデプロイを行ったりする際に色々とうまくないです。なので、こういった設定はプロファイルを使ってサクっと切り替えられるようにしてます。 詳しいプロファイルの使い方*2についてはそのうち別エントリで書く*3!...と思います。基本的なことはTECHSCOREさんのここを参照すればかなり分かるはずです。自分はここで覚えました。ただMaven3からはprofiles.xmlの使
Javadocはソースコードとドキュメンテーションコメントからリファレンスドキュメントを作成するツールです。ソースコード中のクラス宣言やメソッド宣言と、それらの内容についての説明が書かれたドキュメンテーションコメントを、Javadocが解析してHTML形式のリファレンスドキュメントを作成します。 ソースコードを書く開発者は通常、クラスやメソッドを設計・開発しながら、設計について「なぜそうなっているのか」といった説明や利用の仕方をドキュメンテーションコメントとして残すことができます。つまり、Javadocで作成したリファレンスドキュメントをみれば、クラスやメソッドの設計や利用について、開発者の意図したところが理解できるのです。 しかし、通常のJavadocで作成されたリファレンスドキュメントだけだと、ソースコードをどういう意図で作ったのかはわかりますが、そのソースコードが正しいかということま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く