第2回 Java7はここが違う！

前回＜＞次回

登場人物

• NRT
  猪突猛進なプログラマー
  考える前に体力勝負でプログラミングするタイプ。
  たまに鋭い洞察力を見せるため、
  周囲からは落ち着いてさえいれば…と言われている。
  
• SSK
  冷静沈着なプログラマー
  20:80の法則に習い、実は仕事の一部分を学習に当てている。
  他の人はそれに気がついていない。
  Java7についても以前からチェックはしていた。
  
• SKR
  紅一点なプログラマー
  暗算は早いけど、プログラミングはそこそこ。

※登場人物は忍者ではありません。架空のプログラマーです。

新機能：Underscores in Numeric Literals

※前回から会話が続いています。

SSK「しかし、これはこれで見にくいな。」

   0b0001001000110100 
 & 0b0100001100100001
// 0b0000001000100000 ←これが答え

結果：544

NRT「見にくい？“0”と“1”が並んで見やすいってばよ？」

SSK「じゃあこの計算結果を暗算で出すとしたらどうだ？」

NRT「なぬ～！？(目をこらして)…6ビット目と9ビッ」

SSK「(さえぎる)そこで間違えているぞ。6ビット目と10ビット目が正解だ。
       32＋512で544になる。」

NRT「そんなこと言ってもよ？
       こんなに“0”と“1”が並んじゃ………ハッ！？」

SSK「そういうことだ。
       数字が長く並ぶほど読みにくくなる。
       別に10進数でも起こりうることなんだが、2進数では特に顕著だ。
       SKRなら間違いはないだろうが…嫌な顔はされるかもな。
       NRT、どうしたらいいと思う？」

NRT「普通に考えたら4桁ごとに区切ればいいってばよ？」

   0b 0001 0010 0011 0100 
 & 0b 0100 0011 0010 0001
// 0b 0000 0010 0010 0000 ←これはコンパイルエラー

NRT「うげ、コンパイルエラーだってばよ…」

SSK「だがその発想で正解だ。
       Java SE 7からは“_”(アンダーバー)で区切れるようになった。」

   0b0001_0010_0011_0100 
 & 0b0100_0011_0010_0001
// 0b0000_0010_0010_0000 ←これが答え

NRT「おお！コンパイルが通ったってばよ！？
       でも“0b”と数字の間には使えないのか…」

SSK「ああ、“0b_0010”や“0x_11BF”のような書き方はできない。
       そこは制限だと思ってくれ。
       代わりに、“123__456”(アンダーバー2連続)な書き方はできる。
       前後の兼ね合いで長めに伸ばしたい場合でも何とかなるわけだ。
       だが小数点の前後“3._14”、“1_.14”はアウトだ。」

NRT「う～ん、使い方を間違いそうでおっかないってばよ…」

SSK「そこまで身構える必要はないだろ。
       コンパイルエラーならIDEが自動検知できるしな。」

NRT「IDE………そういや、なんでさっきからeclipse使わずにメモ帳なんだってばよ？」

SSK「eclipseの公式サポートはまだらしい。
       β版があるそうなんだが、まだ入れてない。
       数ヶ月もすれば出るんじゃないか？」

NRT「了解♪じゃあ、俺はそれまでゆっくりしてるってばよ～」

SSK「(勉強しろよ…)」

前回＜＞次回

追記：ああ、Rubyでは実装済みなのね…