Closures Cookbook

TS-5579 
BGGA Review
	=>演算子が嫌な感じだなぁ…、
	っつうか、レキシカルコンテキストはイラナイのだけどな。

Aggregate Operations
	Closures と、Fluent Interfacesのコンボで、超ｷﾒｪ。
	ライブラリ作るのが大変すぐる。っつうか、コード読むのも、特に読み易いとも思えないんだが…
	これ、どうやってデバッグすんだ？
	特に、lexicalcontext的な話を、ちゃんとデバッグすんの、スゲェ面倒だぞ、きっと。
	スタックにどんだけメモリ食うのかもよく分らん…。
	っつうか、それぞれのOperations部分が、Colosureなら、それぞれヒープに領域とるよねぇ？
	…大丈夫なの？VMが、そこは、最適化するの？
	TS-5515の内容が、非常に参考になるらしい。(寝てたな…ぁぅぁ…)

An API
	Closures使わないケースと使うケースで、どう変わるかねぇ…
	段階を追って、
		メソッド呼び出し
		→独立したクラス
			・戻り値がある時に、何か混ざっちゃうのは、イマイチじゃね？とか。
			・まぁ、デフォルト値次第で、コードの綺麗さは、そこそこ変わるだしなぁ…
		→Multicatchｷﾀｰ!!
		→Rethrowｽｹﾞｰｰｰｰ
		
		→クロージャを使って、APIを書き直してみたり。
			ああ、そうか、Genericsがあるから、Callableで大概良くなるのか。
			でも、俺が好きな、コーディングパターンは、使えないのかな…
			メソッドを複数用意したinterfaceを、ボチボチ呼ぶみたいなアレは…

クロージャと、型引数をExceptionのサブクラスにするコードパターンは相性がいいんだってさ。
interface Block {
	void execute() throws T;
}
こういうのね。

つまり、
interface Executable {
	R execute() throws E;
}

 execute(Executable executor) throws X {
	return executor.execute();
}
まぁ、こうしろ、と言う事か。ｷﾒｪな…

型引数の time() throws X {} なんぞ？
型引数の前置キーワードでthrowsなんて増えるの？


引数の無いクロージャでは、=>演算子を使わない、簡易記法がアリって事らし。


withstreamのサンプルは、穴が開くほど読むべき。
ナンゾ、ｽｺﾞｲ量のコードが、小さく再表現されていた。
クロージャが二重に使われる事で、原型を留めていない様な呼び出しになっていた。
function type notation ???

public class With1 {
    /**
     * A "with" statement that closes your closeable at the end.  Any
     * IOException thrown from the close() method is silently
     * swallowed. Example usage: <pre>
     *    with (InputStream s : new InputStream(...)) {
     *        // code using s
     *    }
     * </pre>
     */
    public static <T extends Closeable,R,throws X> R with(T t, {T==>R throws X} block) throws X {
	try {
	    return block.invoke(t);
	} finally {
	    try {
		t.close();
	    } catch (IOException ex) {
		// ignore exceptions throws from close()
	    }
	}
    }

    static int counter;

    static class MyCloseable implements Closeable {
	final String s;
	MyCloseable(String s) {
	    this.s = s;
	    counter += 1;
	}
	public void close() throws IOException {
	    counter += 2;
	    throw new IOException(); // it will be ignored
	}
    }

    public static void main(String[] args) {
	with (MyCloseable c : new MyCloseable("testing")) {
	    if (c.s != "testing") throw new AssertionError(c.s);
	    if (counter != 1) throw new AssertionError(counter);
	}
	if (counter != 3) throw new AssertionError(counter);
    }
}


eachEntryのサンプルも、何か凄く違和感があるぞ。
forはキーワードなのに、今までと全く違う使い方をしている。
プレゼンで見たのと違うけど、eachのサンプルはこんな感じ。

public class Bloch1 {
    static <T> void each(Collection<T> c, {T=>void} block) {
	for (T t : c) block.invoke(t);
    }

    public static void main(String[] args) {
	List<Integer> li = Arrays.asList(1, 2, 3, 4, 5);
	each(li, { int i => System.out.println(i); });
    }
}

引数の型に、interfaceじゃなくて、メソッドの構造を指定出来るのか。
っつうか、Scalaにも、こんなのあった様なｷｶﾞｽ。
Structural Subtypingとか、そんなんじゃなかったっけか…。


withLockのサンプルは、リエントラントロックが、大きく変わるっつうか、
あれじゃ、syncブロック使えばイイジャン。アフォかｗｗｗｗ

Modularity in Java Platform

TS-6185 
JSR-277かね？
OSGiとか、何か色々とッ散らかってる感すらあるなぁ…

機能としては、大体この３つが要るヨネ？とか。
・Package
・AccessControl
・Interfaces

まぁ、そうね。OSGiも大体そんなもんだ。


またキーワード増やすのかよ…
package の前にmoduleて…、アフォか！！！！
アノテーション位にしとけよ…

module-info.javaとかｗｗｗｗｗ
もうダメだｗｗｗｗｗｗｗ

VMレベルでmoduleサポートするのか。
つまり、VMが理解するメタモデルの量が増える訳だな。
まぁ、しかし、今の今までmoduleシステムが、真っ当に動いてなかったのには、
それなりに理由があると思うんだがなぁ…
Jar Hellってば最悪だよね、みたいなのは、DLL Hellの頃と変わってないじゃんよう。
でも、それはそれで、テキトーに動くんであって、COMや.NETの様な解決策が、
必ずしも正解じゃないと考えている人達はいる訳だよね…


The JAM Module System
JavaSE7に入ってくるのん？これは、OSGi実装の足回り足りえるのん？んぐー

JAMのmetadataは、がりがりとアノテーションを書く。これは、良筋。
でも、俺としては、META-INF/MANIFEST.MFに書いて欲しいんだけどなぁ…
ソースコードじゃなくてさ。っつうか、modulurityとコードって、
ほんとは、全然関係なくネ？とかさ。
正直、スコープのモデルと全然違うコンテキストを用意するんなら、それこそ、
メタモデルをソースコード上に書きたく無い…

既存のスコープモデルの上に、moduleが追加されるんなら、
つまりは、スコープの数と種類が2倍になる訳だよね…、
まぁ、何かさ頑張らなくてもいいんじゃないかな…
JVM上で動作する言語ではそれぞれ、moduleを意識したスコープモデルを実装してさ、
本家のJavaでは、既存のままでもいいんじゃないかなぁ。


つまりは、Cでasm{}みたいにさ、もう、最終的には何でも出来る領域って残しておいて欲しいんだよネェ…
スコープまわりの情報を絞る為の設計ってさ、つまりは、
再利用可能性を定義する事なんだけど、それって、妥当な設計するのがスゲェ難しくて、
結局の所、卑近な表現をすると、スコープを絞った中に、Hackしたい対象はある訳だよ。
クリーンに設計されたinterfaceはそれはそれで必要なのだけど、
そんなに上手く可視性を設計出来ると思うのは、何か、ねじが飛んでるんじゃねぇの？みたいなー。


複雑な可視性構造を出来る様にしたトコロで、地獄の種類が変わるだけだと思うナリ。


A framework for the module System
	moduleのリポジトリモデルねぇ…単なるツリー構造じゃん…
	まぁ、何か、他に構造があるのかといわれれば、ねぇけども。
	おおう、複数のRepositoryが、1つのJVMのなかで、ゴタゴタと通信するモデルについて説明している。
	うん。やっぱり、結局ツリー構造を作らざるを得ないのだね。
	後は、このツリーが、シンボリックリンク的な事がサックリと無駄なく、
	効率的に出来るかどうかが、問題になるかな。


OSGi in the java Module System
	結局、現状キチンと実装されていて、
	実績のあるJavaのModuleシステムって、OSGiしかないんじゃね？
	あー、そんな事も無いか。EJBコンテナとか、DIコンテナもある種のmoduleシステムだな。
	でも、スコープを再定義する様なmoduleシステムで、稼動実績がキチンとあるのは、OSGiだけなのかな…

Debugging Data Races

TS-6237

物凄い早口で、まくし立てられたので、途中メモは、無理ですた。
気付いたトコロと、知らんかったやり口を中心に、質疑応答中にメモした感じ。


String でないToken、例えば、longを、per-Threadなring-bufferに突っ込むべし。
マジで！。つまり、タイミングによって、どこがバグっとったのか検知しる。
Stringは、重いからダメなんだってさ。


Double-Chekced-lockingっぽいコードには、バグが入ってるかもねー、とか。

複数スレッドによる、読み込みと、たまに書き込まれるnullのパターンは、確かにﾔｳﾞｧｲ。
キャッシュミス系のバグは、マジで見つからない。
厳密な話、キャッシュ系は、結局の所、読み込みの無いタイミングで、書き込むしかないんじゃねぇの？
つまり、サーバ起動時にキャッシュしる。それ以外は、読込みのみにしる。


ドキュメント超重要。とかｗｗｗｗｗ
テキトーなコードを自前実装すんな、とか。
ドキュメントだって言ってるのは、Genericな超絶アイディアが無いからだって、まぁ、そりゃそうか。


java.util.concurrentは、ちゃんとテストされてるからイイよ。とか。
printfデバッグは、凄く簡単で、イイのだけど、書き込みバッファを食っちゃって、
バグが隠れるケースが、あるから気をつけるべき。まぁ、確かにそうだ。
logging系フレームワークによって、タイミングが変わるケースも、忘れないで。
つまるところ、Data Raceなバグを発見する為には、I/Oを伴うデバッグ方法はダメだっつう事か。


ring-bufferに、System.nanotime突っ込んで、後で検証する…とか…ないわー


FindBugsは、オヌヌメだってさ。マルチスレッド系のバグパターン検知は確かに色々詰まってるねぇ…