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つの要素(ガートナー)
- テクノロジによる人間の能力の増大
- マシンによる人間の作業の代行
- 人とマシンのコラボレーション
- マシンによる人と環境の認識力の向上
- マシンへの人の理解の高まり
- より賢くなる人とマシン
プログラミング対象の変化
ユーザーが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を返さないメソッド
終端操作が呼ばれるまで非終端操作は行われない。
