Google Collections 1.0 は Java Collections Framework の機能強化された実装を提供するSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
GoogleのJavaコレクションを使う理由、Multimapが便利 | エンタープライズ | マイコミジャーナル
Javalobby - The heart of the Java developer community Googleが公開しているJavaライブラリのひとつにGoogle Collections Libraryがある。2009年12月30日(米国時間)にバージョン1.0になり、以後APIが互換性のない変更を受けることはないという宣言が発表された。0x1fff: 35 Google open-source projects that you probably don't knowでもGoogleプロジェクトのひとつとして紹介されている。 JavaにははじめからCollectionsライブラリが用意されている。Collectionsライブラリはまさまざまなデータを格納する便利な入れ物をまとめたもの。Google Collections LibraryはJavaの標準のCollectionラ
プログラマのためのGoogleプロジェクト35、+23、+34 | エンタープライズ | マイコミジャーナル
Blog of 0x1fff 0x1fff: 35 Google open-source projects that you probably don't knowにおいてGoogle Codeでホスティングされているプロジェクトから35のプロジェクトが紹介されている。もとはポーランド語で記載された0x1fff: 34 projekty Open Source udost?pnione przez Googleを英訳したものとあるが、翻訳する段階で1つプロジェクトが追加されて35になっている。その後さらに25のプロジェクトが、その後さらに34のプロジェクトが追加され、合計92のプロジェクトがまとめられている。マイコミジャーナルでニュースやハウツーとして取り上げたものも多い。取り上げられているプロジェクトは次のとおり。 テキストファイル処理 Google CRUSH (Custom Repo
「Google Collections Library」でJavaのコレクションを補完する：CodeZine
はじめに 何年も前のことですが、私が初めてJavaに興味を覚えた理由の1つは、Javaプラットフォームに標準でコレクションライブラリが組み込まれていたからでした。当時、C++の世界ではまだSTL（Standard Template Library）が定着しておらず、開発者たちは適当なコレクションライブラリを購入して利用するか（Rogue Waveが流行っていました）、自分の手でライブラリを書くしかありませんでした。正確な数は忘れましたが、私自身も、さまざまな目的でさまざまな種類のプリミティブやオブジェクトの連結リストを実装しました。さらに、もっと複雑なコレクションや平衡2分探索木、ハッシュテーブルなども自分で実装しました。そのようにしてソフトウェア工学の原理を絶えず意識することは決して無駄なことでありませんでしたが、生産性を考えるとそうとばかりも言えませんでした。 しかし、Javaによって
(その14)トランザクション管理 - あるまに
AOP用途の73%を占めるトランザクション管理*1。これが分かればとりあえずGuiceを使ってみようという人が増えるかもしれないので、ちょっと試してみます。 トランザクション機能は他ライブラリを使う Guiceはトランザクションに関する機能を一切持っていません。ドキュメントを見ると"@Transactional"とか書いてあって紛らわしいのですが、「そういうアノテーションを使えば？」という程度の話です。なので、実際にトランザクション管理を行う場合は、自力で実装するか、他のライブラリの機能を使う事になります。今回はSpringのTransactionInterceptorを使ってみますが、Sesar2でもたぶん同じような事が出来ますし、ちょっとインターセプタを書けばHibernateのトランザクション機能を使う事も出来るはずです。 今回の要件 メソッドに@Transactionalと書くと、
(その13) Springframeworkとの統合(2) Spring管理のBeanをGuiceに個別登録 - あるまに
Springとの統合手段2つ目、SpringIntegration#fromSpringメソッドについてです。 fromSpring()メソッドのインタフェースは以下のようになっています。 /** Creates a provider which looks up objects from Spring using the given name. */ public static <T> Provider<T> fromSpring(Class<T> type, String name) 戻りの型Providerは前回見た通り、injectするインスタンスを提供するインタフェースです。JavaDocコメントによれば、Springから指定した名前でオブジェクトを取得してくれるそうです。 fromSpring()を使ってみる。 XML定義とBean関連はその11と同じものを使用しますので省略。
(その12) Providerについて - あるまに
Spring統合の2回目の予定でしたが、前提としてProviderを理解していると良さそうだったので（というか、理解していないとAPIがよく分からなかったので）、予定を変更してProviderを見てみます。 Providerインタフェースは、Keyクラスと共にGuiceのDIの核となっているもので、一言で言うと「Guiceがinjectするインスタンスを提供するインタフェース」です。User's Guideに掲載されている図を引用します。 正確には原典を当たって頂くとして、Bindingはinjectする為の1組のマッピングで、Keyが「どこに（何に対して）injectするか」を示す値。Providerが、「injectするインスタンスを提供するインタフェース」です。つまり、色々なものをいっぱい省いて誤解を恐れつつ一言で言うと、「GuiceのDIとは、@Implementアノテーションがつ
おおたに6号機の春なりかけ。 - Guice User's Guide
id:iad_otomamayさんがGuiceのユーザーガイドを翻訳（すげーはえー！）してくれてたので、 一覧にしてみた。ありがとうございます、あとでじっくり読ませてもらいます＞id:iad_otomamayさん Guice User's Guide ■Java on Guice ■1. Introduction ■2. Plain Old Factories ■3. Dependency Injection By Hand 続きを読む JavaExpressの後継として、新たにJavaExpertが創刊されます。 このJavaExpertの特集2として、id:yone098さん、id:manholeさんと 一緒にTeedaの入門記事を書かせていただきました。 TeedaCoreから始まり、Extension、Ajaxと全部をまとめて紹介するのはこれが初めてじゃないでしょうか。 もちろんS
(その11) Springframeworkとの統合(1) Spring管理のBeanをGuiceに一括登録 - あるまに
GuiceはSpringと統合する為のクラスを用意しています。その名もずばりSpringIntegration。統合と言っても様々な形態が考えられると思いますが、現時点でGuiceが用意しているのは、Springのコンテナで管理されているBeanをGuiceから取得/injectできるようにするものです。それほど凝った事はしていなくて、シンプルなBeanFactoryのラッパーとなっています。 SpringIntegrationクラスにはpublicメソッドが2つしか無いので、両方見てみます。今回はbindAll()メソッド。 SpringIntegration#bindAllメソッドを呼び出すと、Springに名前で登録されているBeanが全てGuiceに登録されます。その際、Guiceコンテナに登録されるインデックス（Keyクラス）は「型と名前のセット」になっています。JavaDocに
(その10) 同じ型で異なる実装クラスをinjectしたい場合 - あるまに
いくつか手段があります。 アノテーションそのもので区別。 ex ) @JasracService / @ElicenseService アノテーションで指定する文字列で区別。 ex) @Named("JASRAC") / @Named("eLicense") 以下、それぞれ見ています。 アノテーションそのもので区別 どの実装をinjectするかを、アノテーションで指定する方法です。まずインタフェースと実装クラス。 public interface Service { String getResponse(String msg); /** 実装その1 */ class TypeAServiceImpl implements Service { public String getResponse(String msg) { return "TypeA : " + msg; } } /** 実装
(その9）AOP含めたパフォーマンス比較を再度 - あるまに
ちょっと数字を出す事の責任を感じてます…。 前置きさせて下さい。 ベースとなっているGuice付属のソースのJavaDocコメントには、以下の文で始まっています。"A semi-useless microbenchmark." 誤解を恐れつつ言えば、このマイクロベンチマークは「大豆100粒を箸で移す競争」みたいなものではないかと。速いにこした事はないですが、それがどれだけ食事の速さにつながるかは、料理や食べ方次第で全く違う、という。…いや、全然うまい事言えてないですね。 という事で、コンテナからのインスタンス取得処理と、取得した1つのインスタンスをひたすら呼び出す処理を分けて計測しました。前者を全フレームワークで実行→後者を全フレームワークで実行、という順序です。 - get instance from factory - Spring: 1,891 creations/s Guice:
訂正：AOPパフォーマンス比較 - あるまに
すみません、以前のSpringとGuiceのAOPパフォーマンス比較ですが、テストコードに間違いがありまして、条件が同じになってませんでした。 Guiceは毎回エンハンスしたインスタンスを作っていた一方、Springは1つのProxyを使い回していたという…。数字を見て何らかの感想をもってしまった方、本当にすみません。 // 訂正前（デフォルトなのでシングルトン） RootBeanDefinition proxy = new RootBeanDefinition(ProxyFactoryBean.class); // 訂正後（シングルトン指定をfalseに） RootBeanDefinition proxy = new RootBeanDefinition(ProxyFactoryBean.class, false); 修正後の計測結果は次の記事にあります。
(その8) Seasar2をAOPパフォーマンス比較対象に追加 - あるまに
id:koichikさんに「S2も比較に追加して」というコメントを頂いたので、言われた通りの方法で追加して試しました。Seasar2のテストコードはま!さんのSeasar2用コードにkoichikさんの記述を追加しただけのものです。Seasar2は触った事がないのでシングルトンかどうか分からなかったのですが、デバッグしながら見たらinjectされたオブジェクトのIDが呼び出しのたびに異なっていたので、毎回インスタンス化しているのだろう（＝条件は同じだろう）と判断しました。また、上記Springの訂正も含まれています。 最初の3回の結果は以下です。Springにとってはちょっと…. Spring: 1,734 creations/s Guice: 35,161 creations/s S2: 18,395 creations/s Spring: 1,776 creations/s Guice
番外編。スレッドセーフ - あるまに
Injectorはスレッドセーフだそうです。Injectorはインタフェースだから表現が若干不正確な気もするけど。
Google Guice（その7） 実装クラスの指定方法 - あるまに
インタフェースの実装クラスを指定する方法は、その2で書いたbind(インタフェース).to(実装クラス);が基本です。しかし他にもいくつかあって、その中でもちょっと毛色が違う@ImplementedByアノテーションを紹介します。 これはインタフェースにアノテーションで実装クラスを指定する方法です。 @ImplementedBy(ServiceImpl.class) public interface Service { String getResponse(String msg); } bind()で実装クラスを指定したらそちらが優先、指定が無ければこのアノテーション指定が使われるので、デフォルトの実装をアノテーションで指定しておき、必要があった時だけbind()で上書きするという使い方ができます。 指定が無くてよいので、呼び出し側は↓だけ。 public class Main { pub
Google Guice（その6） AOP使用時のパフォーマンス比較 - あるまに
※下記はコードが間違っていて訂正したので、その8をご参照下さい。 その5でid:shot6さんにコメントを頂いた事もあり、AOP使用時のパフォーマンスを比較してみます。 使うのは、Guice付属のパフォーマンス比較コードにAOP設定とAOPを挟んだメソッドの呼び出しを追加したものです。 SpringのAOPはとりあえずノーマルなProxyで。 // 設定 RootBeanDefinition proxy = new RootBeanDefinition(ProxyFactoryBean.class); MutablePropertyValues proxyValues = new MutablePropertyValues(); proxyValues.addPropertyValue("target", new RuntimeBeanReference("barImpl")); prox
Google Guice(その5) パフォーマンス比較 - あるまに
Guiceのテストコードに含まれる、パフォーマンス比較測定を実行してみます。 内容は、以下のような依存関係を持たせたオブジェクトをひたすらコンテナから取得し続けて、1秒間に取得できた回数を表示するというものです。 Foo foo = new Foo(); foo.setI(5); foo.setS("test"); Bar bar = new BarImpl(tee, 5); Bar copy = new BarImpl(tee, 5); foo.setBar(bar); foo.setCopy(copy); さて、実行したら*1以下のような結果が10回表示されました（どれも近い数値だったので1回分） Spring: 3,603 creations/s Guice: 152,207 creations/s By Hand: 6,666,666 creations/s GuiceはSprin
Google Guice(その4) メソッドやコンストラクタへのInject指定 - あるまに
その2で書いたコードでは、下記のようにフィールドに@Injectを宣言してInjectしてました。 @Inject private Service service; GuiceはもちろんメソッドやコンストラクタにもInject出来ます。 import sample.guice.service.Service; import com.google.inject.Inject; public class InjectSample { // フィールド @Inject private Service service; // コンストラクタ @Inject public InjectSample(Service service) { System.out.println("コンストラクタ <" + service + ">"); } // メソッド @Inject public void inje
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Androidメモ
パフォーマンス計測コード公開 - あるまに
