JavaのSwitch構文を高速化する方法。

Java

Switchを使うと以下の二つの命令のどちらかがコンパイラによって生成される。


lookupswitch - switch文のcase式の値が不連続である場合値を探しながらジャンプ先を探す。

tableswitch - switch文のcase式の値が連続である場合キー値をindexとしジャンプ先アドレスを値とする配列を作り高速にジャンプする。


つまり、特に問題がないかぎり、値を連続で定義するほうが、高速化できそうだ。



全然関係ないけども、下記の書き方はコンパイル可能。

		int l = 1 ;
		    l |=l ;

Java7とJavaEE6が流行らない理由

Java

Java5からアノテーションとジェネリックが導入されて、Java6を経てようやくJava7がでてきますが、Java6になってもこのアノテーションとジェネリックがそこまで受け入れられていないように見受けられます。


ビジネスの上で重要なJavaEEもようやくJavaEE6になり、アノテーションベースの機能が取り入れられます。


このアノテーションベースは従来のプログラミングとは若干、方法が異なります。
そのため、よりビジネス上のリスクを避けたいJavaEE界隈ではアノテーションベースが
特に受け入れられにくいのではないでしょうか。


さらに、オラクルのサン買収で、Java界隈のオープンソーサー含むJava使いはモチベーションも下がっており、結果的にJava7も含め流行するとは考えにくいと言わざるを得ません。


合わせて、昨今スマートフォンの人気が高まっており、相対的にJavaEE6の需要が下がることも一因となります。


当たり前ですが、今の時期は新興市場の開拓、そして受注力の強化、営業戦略がIT業界で力を入れるべきところなんですよね。不景気でも流行るためにはここをクリアしておくことが前提ではないでしょうか。

再認識、プログラミングにおいて数学の知識は必要だ。

世間一般のプログラミングには数学の知識なんて必要ないんじゃないかと
思っていたんだけども、あるときやっぱ必要だと思った。


それはテストのとき、
例えばある計算処理を行うプログラムを作ったとして
それをテストする時にテスト結果が正しいかどうかって
机上で計算できて初めて判断できるじゃん。

単純な四則演算だったらいいけどそうでない物は結構大変。
それだけでテスト工数増大だ。
FP法なんかI／Oの数で判断してたりするから
例えば複雑な計算結果を出力するプログラムでOが一つの場合、
Oが一つだけだからテスト工数これだけ
みたいな考えだったら遅延のもとだな。

まぁそういうのは段階的にモジュール分割するような設計にするだろうけども
それもFP法にはあらわれない。


あらら、工数見積もりって単純な四則演算じゃないよ、かなり複雑なんだよ。
って話もしなくちゃいけないのかな。

多様化は結構たいへんだ。

エンターティンメントも仕事も、いろんなものがITの影響で多様化してきている。

それっていいことかもしれないが、結構たいへんなこともある。

夢はそんなに多くは見れないけども、やりたい事や、欲はたくさんある。

昔ほど、周りの目を気にしなくてもよくなったので、自分はやりやすい。

人生８０年、少ししかないんだから自分らしく生きていけばいいんだろう。

思うままに生きればいい。