じゅくちょーです。私はJava製JITコンパイラGraalにとても強く興味を持っています。 Graal の検索結果 - Fight the Future Graalのコードを読んでいる内に、自分はGraalの前にそもそもコンパイラをよく理解していないと感じるようになりました。コンパイラに関してはたくさんよい書籍があるようですが、きしださんのブログで以下の書籍を見つけ、読みました。 d.hatena.ne.jp コンパイラとバーチャルマシン (IT Text) 作者: 今城哲二,岩沢京子,千葉雄司,布広永示出版社/メーカー: オーム社発売日: 2004/09/01メディア: 単行本購入: 2人 クリック: 21回この商品を含むブログ (13件) を見る 大学生の教科書向けの本です。200pちょいと薄いです。わかりやすくおもしろい本でした。 この本にはCのサブセットな言語Chavaのコンパイラ

注：本記事の内容はJavaで公式にドキュメントされているものではなく筆者の見解です。とはいえクラスを設計する上で有用な指針たり得ると思われるので公開したものです。 おさらい - 検査例外と非検査例外 Javaの例外クラスには「catchしないとコンパイルエラーになる」検査例外（チェック例外、checked exception）とそうでない非検査例外（非チェック例外、unchecked exception）があります。 検査例外は最近は嫌われる傾向がありC#では採用されていませんしAltJava言語も軒並み不採用、さらにはJavaの新しめのライブラリにも非検査例外しか投げないものが出てきていますが、適切に使えば安全なプログラミングのための強力な武器であり、検査例外の有意義さについては @irxground さんの Javaの検査例外の存在意義 をご覧ください。 例外クラスを自作する場合、検査

ってことで、例外のお話です。 どうも僕の知っている限りでは、チェック例外という言語機能をもっているのはJavaだけみたいです。 僕個人としては、すばらしい機能なんですが。 Javaで最初にチェック例外を学んだ時、「そうそう、これこれ、これが欲しかったのよ！」 って思ったあの頃の想いは今も色あせていません。 「ずっと好きだったんだぜ～♪」って斉藤和義の曲を口ずさむくらいに、今もチェック例外を愛しています。 しかし、このチェック例外、他の言語からdisられまくって、最近の言語には取り込まれないという悲しいお話になっています。 過去に様々な議論があった中で、結論としてチェック例外は役に立たないってことになったらしいです。 経緯は知らんがね、そんなん。僕には役立ってるんだから。 ってことで、僕の立場から見た、チェック例外についての考察と扱いを書きます。 反論したい方、自重をお願いします。 だって、

例えば、GoFデザインパターンのIIteratorでは、もうJavaやC#では拡張forなりforeachがあるのでほぼ不要になっており意識して実装することも無くなってきていると思うわけだが、ここにきてDecoratorパターンもパターンとして意識する必要性が無くなってくるのではないかと思う。 というのも、Java SE8では、ラムダ式が遂に実装されることばかりがクローズアップされるが、実はインターフェイスのデフォルト実装が導入されるというかなり重大な変更も予定されている。構文はまだ変更されるかもしれないが、こんな感じになるらしい。 public interface Sample { public Object doSomething() default { return null; } } あのRubyの父親まつもとゆきひろも指摘していたらしいJavaの大きな欠点だった「実装を共有できな

先日参加したSQiP「キーワード駆動テストシステムを作ろう」で学んだ、ランナーの役割をJUnitでも実践できるのかを検証する為に、JUnit4のソースコードを読んでみました。 作ったクラス図 折角、なんちゃってクラス図を書いたので公開します。 参考にしたサイト 最初は「ランナーってなんだ？」というところから入って、こちらのサイトを参考にし始めたのですが、分かったような分からないようなままになっていました。 www.mscharhag.com もやもやしたまま、SQiPのチュートリアルを迎えて、ランナーの役割が分かったところで、JUnitのソースを読むと不思議と頭に入ってきました。 途中、こちらのサイトも参考にさせて頂いたり d.hatena.ne.jp ihirokyさんは、super.runChild()をオーバーライドしたrunChild()の中で呼び出しています。これも一つの方法です

イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja

個人的にBuilderパターンはオブジェクトの生成制御や、ものによっては可読性が高くて好きなパターンなんですが、その実装には用途によっていくつかパターンがあるので、まとめてみました。 生成するオブジェクトの条件 クラス名:People フィールド:String name(必須), Integer age(必須), String hobby(オプション) 必須要素はnullを禁止 PeopleクラスはStringを返り値とするhelloメソッドを持つ 今回はBuilderパターンの比較のため、パターン上必要でない限りgetterなどのメソッドは省略 Native Builder Builderパターンではなく、ただのコンストラクタ。Builderパターンを使いたくなるのはこれをやりたくないからだけど、比較のために記載。 class People { private String name;

Cargo Tracker とは エリック・エヴァンスのドメイン駆動設計 で紹介されている様々なパターンを実際に使用して、有志が作成したサンプル Web アプリのこと。 DDD Sample Application - Introduction オリジナルは Spring Framework を使用している。 一方、この実装を Java EE 7 で置き換えたサンプルが公開されている。 Cargo Tracker この実装を読みながら、 DDD で紹介されている以下のパターンがどのように実装されているのかを確かめてみる。 レイヤ化アーキテクチャ エンティティ 値オブジェクト 集約 リポジトリ サンプルアプリを動かす ソースのダウンロード このページ の一番下に zip のリンクがあるので、そこからダウンロードする。 環境準備 以下のソフトウェアをインストールする。 JDK 7 以上 Mav

これの続きです！ レビューしてもろた！ おぉ。メソッドわけない前提で、price<sumのほうが正常系なんだから先に異常系を抜けるべきってのと、正常系だけresultの値設定順が違うのと、最初のthrowがただのgotoになっててバグぽい。「続：僕の好きなコードの書き方」 http://t.co/6drsy6VG8I— きしだલ (@kis) May 8, 2015 そっこーでコメントくれてた！確かに確かに！ @bufferings 僕ならstaticイニシャライザで、def(1, 0); def(5, 0); def(10, 10); みたいなのたくさん定義してMapで持っとく。— CEROMETAL (@cero_t) May 12, 2015 なるほどですなー。 あと、@haradakiro にも「お邪魔したいのでテストコードも晒さないかな、ちらっちらっ」ってコメント頂きました。 レ

HASUNUMA Kenji (Deprecated) @khasunuma_old Date and Time APIを説明するにISO 8601にまで踏み込むのは蛇足だという方は非常に多く、過去にJava界隈の重鎮から叩かれたことがあります。しかし、過去のセッションやブログを見る限り、ISO 8601には触れずに解説したものは、ほぼ例外なく爆死しています。 2015-05-09 05:11:10 HASUNUMA Kenji (Deprecated) @khasunuma_old Date and Time APIがISO 8601ベースになったのは、先行したJoda-Timeが同様にISO 8601ベースにしてうまくまとまったから。Stephenは暦が無数にあることを承知の上で、ISO 8601という国際規格を「人間向け」の基準と定めたのです。 2015-05-09 05:13:45

The document discusses various techniques in Perl for dealing with reference cycles and memory leaks caused by strong references, including using weak references, extracting needed data from objects before destroying them, and passing objects into subroutines to avoid capturing them. It also discusses analogous techniques used in Objective-C like weak references and guard objects to break cycles.

こんな記事があった。 「 getter/setterとはなんだったのか」- プログラマーの脳みそ JavaBeansはGUIなどで再利用可能なコンポーネントを提供する際の規格のようなもので(僕もあまり詳しくない)2000年ぐらいにGUIのコンポーネントを作るときに意識したような、どうでもよかったような、イマイチ恩恵が実感できなかった代物だった JBuilder2とか3の頃のJava開発といえば、AWTやSwingといったGUIアプリケーションを作ることがまだ当たり前だった時代。「部品」といえば、GUI部品のことを指していました。GUI部品といえば、ペタペタツールの存在を忘れてはなりません。当時のJava IDEは、こぞってVisual Basicの開発環境に追いつけ追い越せという状況だったんです。 それらのIDEが目指したもの、それは「コーディングなしでGUI画面を作れるようにすること」で

Javaのgetter/setterのお話。 僕は当時を語るには若すぎるのだけど、過去を振り返って書いてみる。当時を知る人は誤りがあれば指摘してほしいし、情報があればコメントなりトラックバックなりして欲しい。前世紀の話というのは今となっては探すことがなかなか難しくなりつつある。 「privateな変数にpublicなアクセサを定義する」？ - ネットの海の片隅で getter/setterとは何か Javaのオブジェクトにフィールドがあったとして、そのフィールドに値を設定するメソッドがsetter(せったー)、そのフィールドの値を取得するメソッドがgetter(げったー)と呼ばれる。慣習としてsetterはsetXXX(int value)といった様にsetから始まる名前をつけ、引数はひとつ。戻り値はvoid型。getterはgetXXX()といった様にgetから始まる名前をつけ、引数はな

「Ｊａｖａの高速化の方法」というページに、次のような高速化手法が書かれていました。 文字列がNULLかどうかの判断は IF文を使用せずに 例外処理NullPointerException で置き換える if文の場合です。 if(obj == null) { /* process */ } try/catchの場合です。 try { /* process */ } catch (NullPointerException e) {} たまにこういう謎の高速化手法を教えてもらうのですが、どうしてもすぐには信じられないので少し調べました。 ifとtry/catchのオーバーヘッドは？ Stack Overflowに、ドンピシャな質問がありました。 Java if vs. try/catch overhead 読んでみると、「例外処理は例外的な処理に使うものだから、通常のフローでnullになるような

はじめに みなさんはじめまして。 アメーバ事業本部ゲーム部門でJavaエンジニアをやってる朝倉です。

tl;dr: This book details my strong opinions on the best way to test, while acknowledging alternative styles and various contexts in which tests are written. Whether you prefer my style or not, this book will help you write better Unit Tests. From the Preface: Over a dozen years ago I read Refactoring for the first time; it immediately became my bible. While Refactoring isn’t about testing, it expl

APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本（ソフトカバー） まもなく書店に並びます。序章「なぜ新たなデザイン本が必要なのか」の冒頭からの抜粋です。 みなさんは、「プログラミングの世界にはもう十分な数のデザイン本があるのでは」と思うかもしれません。実際、数多くの本があるので、なぜ私がもう1 冊書かなければならないのか（そして、なぜみなさんが読まなければならないのか）と疑問に思うことは当然です。特に、オブジェクト指向システムでのデザインパターンに関しては、いわゆる4 人組（Gang of Four）と呼ばれる人達が執筆した有名なDesign Patterns: Elements of Reusable Object-Oriented Soft