なぜジェネリックスなのか？ ジェネリックスはどのような問題を解決するものなのでしょうか？ それを理解するために、次のような箱 (Box) クラスを考えましょう。 public class Box { Object o; public Box(Object o) { this.o = o; } public Object get() { return o; } } これは単なる箱 (Box) を表すクラスです。コンストラクタで何かオブジェクトを受け取ったら、それを内部的に Object 型の o に保持しておき、get メソッドが呼ばれたときにそれを返すだけです。 これを利用するプログラムを考えましょう。 Box b = new Box(123); Integer i = (Integer) b.get(); System.out.println(i); // 123 Box のコンストラク
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
なぜ今Javaの例外処理か Javaにおける「チェック例外」はSwift、Objective-C、Ruby、JavaScriptといったネイティブ・ウェブアプリ開発でよく用いられる他の言語には現れないものです。 SwiftにはOptionalやErrorTypeがありますが、Javaにおいてもnullやエラーのハンドリングの実装方法をうまくやる必要があります。 なぜ例外を握りつぶしたらいけないのか、なぜアサーションが望ましいのか、なぜチェック例外と非チェックを分けたのか、という点を考えてみたいと思います。 参考資料 例外設計における大罪 （契約プログラミングについて） Effective Java読書会9日目 - 例外 （Javaにおける例外の扱いについて） 契約による設計から見た例外 （この記事の方がより詳しいけど難しいイメージ） チェック例外と非チェック例外の違い チェック例外→「回復
JSON(JavaScript Object Notation) JavaScriptにおいて，オブジェクトの定義を行う際に用いられる表記 RFC4627にて規定されている。 XMLより簡素な記述で扱いが楽 JSON-lib JSON-libはJavaからJSON形式を簡単に扱えるライブラリ ダウンロードは以下 http://json-lib.sourceforge.net/ 今回ダウンロードしたファイルは以下 json-lib-2.3-jdk15.jar json-lib-2.3-jdk15-sources.jar この他に以下のライブラリが必要 http://commons.apache.org/からダウンロード jakarta commons-lang 2.4 jakarta commons-beanutils 1.7.0 jakarta commons-collections 3.
Java SE 8ではメソッドの引数に「処理」を渡せる。匿名内部クラスの実装を大幅に簡易化 ここまで読み進めてきた方の中には、「Java SE 8で並列処理を簡単に実装できることはわかったけど、新しい機能の学習で苦労するのは嫌だな」と思った方がいらっしゃるかもしれません。 もちろん、これまでのJava SEからJava SE 8に移行するためには、ラムダ式など新しい言語仕様について学ぶ必要があります。しかし、上の例からも、その苦労以上のメリットがありそうだということはわかりますよね。皆さん、安心して、早くJava SE 8の新しいルールを学んでください。 それでは、Java SE 8によるプログラミングは、これまでとどう変わるのでしょうか。それについて簡単にご説明しましょう。 これまでのJavaプログラミングでは、まずクラスを書き、その中にメソッドを定義するというスタイルが一般的でした。メ
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
1.0.0 がリリースされました。やりましたね。 僕の観測範囲内に見えることが増えてきたので、興味本位で少しずつ触っています。 まず、ブラウザだけで試せるチュートリアルが大変素晴らしいので、Kotlin が肌に合うかどうか確認するといいですよ。 Kotlin Koansjs で実装されたエディタなのにシンタックスハイライトだけでなく、入力補完がガンガン効くので凄く良い。 僕の理解#大体 3 日くらいかけて言語仕様やマニュアルの類を読みながらチュートリアルをこなした結果、 Kotlin は 安全な次世代の Groovy であるという理解に到達しました。 僕が Groovy に対して持っていた不満は、大体以下の通り。 ランタイムがデカ過ぎるgroovy-all-2.4.6-indy.jar が 6.5Mバイトコードエンハンス等の危険な黒魔術がカジュアルに動く型がありそうで、実は殆どない型があま
僕もスタックトレースの読み方についてちょっと書いてみる。 例はOracle Technology Network for Java Developers | Oracle Technology Network | Oracleを使う。 1:class MyClass { 2: public static void main (String args) { 3: crunch(null); 4: } 5: static void crunch(int a) { 6: mash(a); 7: } 8: static void mash(int[] b) { 9: System.out.println(b[0]); 10: } 11: } これを実行すると以下のようになる Exception in thread "main" java.lang.NullPointerException at M
LinkedList クラスは List インターフェースおよび Deque インターフェースを実装したクラスの一つで、要素の数が可変のコレクションとなっています。それぞれの要素は前の要素と次の要素の情報を持っていて、先頭の要素から順番に辿っていくことで各要素へアクセスすることができます。要素の追加や削除を行ったときに影響を受けるのはその前後の要素だけのため、 ArrayList と比較して高速に行える場合がありますが、インデックスを指定して各要素へアクセスする場合に時間がかかる場合があります。ここでは Java における LinkedList クラスの使い方について解説します。 ※ LinkedList クラスは java.util パッケージに含まれています。利用する場合は java.util.LinkedList をインポートしてください。
Effective Java 第2版 (The Java Series)の項目22で言及されているように、原則として内部クラスはstaticにすることが推奨されます。主な理由は、staticでない内部クラスが暗黙的にエンクロージングクラス（トップレベルクラス）のインスタンスを参照するためです。 staticな内部クラスを持つクラスのヒープダンプ staticな内部クラスはエンクロージングクラスのインスタンスへの参照を持ちません。 class HiddenReferenceTest { private static class InnerClass {} } 非staticな内部クラスを持つクラスのヒープダンプ 一方、staticな内部クラスはエンクロージングクラスのインスタンスへの暗黙的な参照を持ちます。 class HiddenReferenceTest { private class
プログラミング関連Blog 私の興味の端から端までをお届けします！ 【免責事項】このサイトの情報は私の個人的な見解で、私以外の意見を代弁するものではありません。 最近、私が作成しているコードには staticなインナークラスが書かれていることが多い。 ビジネスロジックなクラスの中にstaticなインナークラスを作成すると 意外な利点があることを発見したからだ。 DIを使用したステートレスなビジネスロジッククラスの中にあるメソッドは 大抵がstaticなメソッドで収まることが多い。 そして、クラスの中でもやっている作業は以外に手続き型の流れとなるので メソッドを特定の部類に分類できる。 たとえば花を咲かせるクラスがあったとする。 インターフェイスとして実行するメソッドが一個公開される。 あとは内部処理として １．鉢を用意する。 ２．種をまく。 ３．花が咲くまで水を与える。 という具合な手続き
EffectiveJava読書会で意外とenumネタで需要がある気がしたので、ちょっと書いてみます。内容的に目新しいものは無いはずの事を書きますので、理解されている方はツッコミ所探しでもしてください。 読み方 enumは enumerate か enumeration が語源になってるわけで、素直にいけば「イニュム」になります。けれど実際どう読まれるかは別の話です。最も大事なのは伝わる事なので、私は基本相手が発音したものに合わせます。コウモリです。それはいい。 実現場では「いーなむ」と発音することが多いです。アクセントの位置は地域で変わるかもしれませんが、日本では「いーなむ」と言っておけば通じない事はないと思います。「いにゅーむ」とか下手に言っちゃうと「は？」って顔される可能性が非常に高いです。英語のセッションの動画見て「い（え）にゅーむ」って言う事にしたのですが、いざ言おうとしたら「いに
Builderパターン 個人的にBuilderパターンはオブジェクトの生成制御や、ものによっては可読性が高くて好きなパターンなんですが、その実装には用途によっていくつかパターンがあるので、まとめてみました。 生成するオブジェクトの条件 クラス名:People フィールド:String name(必須), Integer age(必須), String hobby(オプション) 必須要素はnullを禁止 PeopleクラスはStringを返り値とするhelloメソッドを持つ 今回はBuilderパターンの比較のため、パターン上必要でない限りgetterなどのメソッドは省略 Native Builder Builderパターンではなく、ただのコンストラクタ。Builderパターンを使いたくなるのはこれをやりたくないからだけど、比較のために記載。 class People { private S
はじめに じゃっばじゃばにしてやんよー♪っと ( ´ー`)フゥー．．．(ﾟДﾟ)ﾊｯ！ どーん 今日読んだところ 45 ページ〜 66 ページ 前回はこちら Effective Java 読書会 2 日目 「equals night」 - IT戦記 hashCode 2 契約 シグニフィカントなフィールドを変更しなければ、いつ hashCode を呼び出しても値は変わらない x.equals(y) が true の場合は、 x.hashCode() == y.hashCode() が true equals をオーバーライドしたら hashCode もオーバーライドすべき 前述の 2 契約を守るために必要 x.equals(y) が false の場合 かならずしも、 x.hashCode() != y.hashCode() になる必要はないが、 値がバラけているほうが HashMap の
Java入門では割愛としていたローカルクラスと、ついでに関連の強い匿名クラスについて書いておきます。ネストしたクラスとかインナークラス（内部クラス）とかはそこそこしっかり書いたつもりなので、読んでいただけると嬉しいです。 Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus) 作者:きしだ なおき,のざき ひろふみ,吉田 真也,菊田 洋一,渡辺 修司,伊賀 敏樹技術評論社Amazon 言語仕様とか読んでもいいと思いますし、この辺りも参考に見てみるといいと思います。 ローカルクラスの意義 - ぐるぐる～ 2009/3/14 Javaのクラス宣言5種+α - プログラマーの脳みそ 2012/3/8 Javaのクラスの使用 - ひしだま's 技術メモページ 2010/1/9 みなさまにはいつもおせわになってます。 宣言とか呼び方とか それぞれど
ConcurrentHashMapを使うときの注意点 タイトルの通りです。 ConcurrentHashMapは同期を取りつつ、パフォーマンスも優れたとても優秀なやつで、最近Webアプリケーションで、キャッシュみたいなものを作るときに使いました。 とはいえ同期を取るとはいっても以下のようなキーの存在を確認して、putするような複合アクションの呼び出し(いわゆるcheck-then-act)では同期されません。(別にこれは、従来のHahMapとかCollections.syncronizedMapとかでも同じです) // atomicではない操作。 if(!map.containsKey(key)) { map.put(key, value); } 以下が実証コードで、実行すると高い確率で複数スレッドで同一キーへのputを行います。 (今回のケースだとあまり問題にならないですが、valueを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
