読者です 読者をやめる 読者になる 読者になる

JJUG CCC 2013 Fall

JJUG CCC 2013 Fallに行ってきました。

基調講演-1 Javaと未来のこととCCC

鈴木雄介さん (日本Javaユーザーグループ 会長) 資料

Javaの現在と未来

世界中でユーザーグループ(JUG)の活動が活発になってきている。アフリカとかでも

IoT時代に向けて

2015年 → 2020年
接続されるデバイス数 250億 → 500億
一人当たりのデバイス数 3.47 → 6.58

Beyond Java 8

  • Modular Platform(Jigsaw)
  • Unified Type System
  • Language Interoperability
  • Memory-efficient data structure
  • Java on GPUs(Sumatora)

Project Avatar

  • HTML5+Java EE
  • Thin Serer Architecture(TSA)

IoT(Internet of Things)から考える未来

ブラジャーもネットにつながる時代に。

インターネットに接続するもの

  • GPS
  • テレマティクス
  • スマートグリッド
  • 人体情報の測定(医療)
  • などなど

テクノロジーの6つの要素(ガートナー)

  1. テクノロジによる人間の能力の増大
  2. マシンによる人間の作業の代行
  3. 人とマシンのコラボレーション
  4. マシンによる人と環境の認識力の向上
  5. マシンへの人の理解の高まり
  6. より賢くなる人とマシン

プログラミング対象の変化

ユーザーがITを意識しなくてもよくなる。渋滞情報を自動で通知等

ユーザーがどのボタンを押したら何が起きるか
 →
周りで何が起きたらユーザーに何をすべきか

  • トリガーがシステムの外側にある
  • オープンな世界、無限の可能性
  • テストとは何か

「人間の判断」から「外部化された判断基準」

  • 使うこと/考えることの自動化

ITの作り方

  • いかに効率よくソフトウェアを作るか

現在

  • サービスを提供し、フィードバックをもらう
     アジャイル、DevOps、リーンスタートアップ
  • いかに早くサイクルを回すか

基調講演-2 2013 エンタープライズ Java 最前線

寺田佳央さん (日本オラクル)

JavaEE7

EE6からEE7になって以下の機能が追加された

  • Concurrency Utilities for EE(JSR-236)
  • Batch Application(JSR-352)
  • Java API for JSON(JSR-353)
  • Java API for WebSocket(JSR-356)

JavaEEにこれから触れる人は、EE6を勉強してから上記の差分を学ぶのが良いと思う。

Projecct Avatar

PCの電源が切れたのでメモとれず orz

JSR 310 “Date and Time API” への招待 2

蓮沼賢志さん (GlassFish Users Group Japan) 資料

秒について

昔19世紀近く使われていた秒の定義は正確ではなかった。(太陽の位置を元に算出された値)
現在は原子の特性を利用した正確な秒の定義が利用されている。(数億年に1秒ずれるかどうか)

世界標準時について

イギリスのグリニッジ天文台を通る経度を標準時(GMT)として定められた。
ただし、観測地点によってその位置がずれる。

そこで、観測地点に依存しない世界時(UT)が定義された。(1928年) さらに原子時計に基づく原子時(TAI)(1955)が定義された。

しかし、太陽の公転との関係でずれが生じてきたため、UTとTAIの間をとって協定世界時(UTC)(1972年)が定められた。

Javaのミリ秒は1970年を起点になっているが、UTCが定められたのはその後。
ほとんどのプログラムでは、その際に生じた誤差は無視している。

タイムゾーン

各地域のタイムゾーンはtz database(tzdb)で定義されている。
tzdbはたまに更新されているので、できるだけ最新を使うように。

Javaのクラス

java.util.Data
日付・時刻の表現のみに徹する

java.util.Calendar
Javaの国際化対応(JDK1.1)で導入
日付・時刻の作成・編集に用いる

java.time.* (JSR310)
JDK8から導入
Date/Calendar代替が当初の目標
日付・時刻を総合的に扱うフレームワーク
Date/Calendarを置き換えるもの

java.util.Dateの課題

  • フィールド操作が面倒
  • 年フィールド+1900が実際の年
  • 月が0から始まる
  • 日付部と時刻部が混在している
  • 日付演算が貧弱

java.util.Calendarの課題

  • フィールド操作が面倒
  • 月が0から始まる → 定数でお茶を濁す
  • 日付演算が貧弱(Dateよりはまし)

JDK8よりCalendar.Builderを導入して多少改善された。
new alendar.Builder().setDate(2013, NOVEMVER,9).~

それでも貧弱

JSR310 Date and Time API

  • Date、Calendar、DateFormat等を置き換えることが目的→失敗
  • ISO8601形式の日付。時刻表現
  • ImmutableかつスレッドセーフなAPI

デメリット

  • JSK8 APIの中でも最大規模→複雑
  • 既存APIとの相互運用はガン無視→後から多少改善された

その他

OffsetDateTime vs ZonedDateTime

  • OffsetDateTime - UTCからの時差のみ考慮(計算が早い)
  • ZonedDateTime - タイムゾーンを考慮

タイムゾーン ≠ UTCからの時差
タイムゾーンは以下も考慮している

  • 夏時間
  • 時差の改定(ごくまれ発生に)

Chronology(暦)も対応。和暦とか

JSR310とDate/Calendarの変換は無い!必要なら自前で!

ThreeTen backport
JSR310からJDK8依存の部分を取り除いてJDK7でも使えるようにしたOSSライブラリ
リリース前の勉強とかにでも。

徹底解説!Project Lambdaのすべて

bitter_foxさん (立命館大学 立命館コンピュータクラブ) 資料

ラムダ式は既に知っていることが多かったので殴り書き程度で。。。

ラムダ式の引数ではアンダーバー("_")は使用不可。
Javaでは違うが、多言語では特殊な意味を持つので、混乱を避けるため。
また、将来のために予約語とされている。

なぜいろいろと省略できるのか
縦に長くなった匿名クラスを、ラムダにしたことで横に長くならないため。

スコープの注意点
thisが表すものが匿名クラスと異なる。

BufferReaderのStreamは br.lines()

非終端操作 : filterやmap等のStreamを返すメソッド
終端操作 : foreach、reduce等のStreamを返さないメソッド
終端操作が呼ばれるまで非終端操作は行われない。