JJUG CCC 2017 Fall ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く
JJUG CCC 2017 Fall に行ってきました！ 今回は自分好みな「普段使ってるアレ、深掘りするとこうなってるんだぜ」的なセッションをいろいろ聞けて大満足でした。 印象に残っているのが「DBのTCPプロトコルとJDBC / yohei yamana さん」。 「かっちりした PostgreSQL とやんちゃな MySQL という感じがする」という話があって、自分が普段使ってる印象がそのまま JDBC にも現れているんだなーと思いました。なかなかこういうものは深掘りできないので、面白い！と思ったところをポイント抑えて紹介してもらえたのは嬉しかったです。 あと、今回のメインセッションで唯一の難易度 ★★★ だった「CPUから見たG1GC / 数村憲治さん」。 難しすぎて理解できていない*1ですが、なんでこうなるの！？という不可思議現象に迫るというお話は聞いていてワクワクしました。これを
Java9 でも String クラスがリファクタリングされていました （JEP 254: Compact Strings 編） - 地平線に行く
本日、ついに JavaSE 9 がリリースされました！ そこで、かねてから噂になっていた JEP 254: Compact Strings がどのように実装されているのか調べてみました。 Compact Strings の概要 これまで String クラスや StringBuilder クラスなどの内部では、文字列を UTF-16 でエンコードして char 配列で保持していました。 つまり、一文字あたり*1常に char ひとつ = 2バイト分のメモリを使っていました。 しかし、これだと 1 バイトで表せる LATIN1（ASCII コード ＋ ラテン文字）の文字列の場合、その半分が 0x00 になるという無駄がありました。 そこで、内部表現を変更し、文字列が LATIN1 のみで構成されるときは 1 文字を 1 バイトで保持するようにリファクタリングされました。 ちなみに、LATIN
JJUG CCC 2016 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く
JJUG CCC 2016 Spring に行ってきました！ 今回は、改善系のネタを中心に聞いていました。 この手の話はやっぱり、勉強会っぽくて、そして自分の世界が広がる（そんなやり方があったのか！っておどろく）のでとても好きです。 最近、自分の仕事がプロジェクトをよくしていこうぜ！というのでとても参考になりました。 ありがとうございました！ 次回は Java 9 の話がもっと出てくるのかな…？ あと、今回はスマートフォン用タイムテーブルを勝手に作ってみました。 懇親会や Twitter で聞いた限り、たくさんの方に使っていただけたみたいでうれしいです。 また、次も作ると思うのでそのときはまたご利用ください！ JJUG CCC 2016 Spring - Timetable (非公式) さて、毎回のことですが*1、残念ながら時間がかぶってしまって参加できなかったセッションもあったので、あと
JJUG CCC 2015 Fall ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く
JJUG CCC 2015 Fall に行ってきました！ 今回は、ちょうどJava 8 と 9 のちょうど間、ということで Java 自体の話よりもその周辺の話、特にライブラリの話が多かった気がします*1。 こういう話がきけるのが Java らしい（ライブラリが豊富な Java ならでは）ですね。 すぐにライブラリ使ってみよう！というとそんなことはないのですが、そのライブラリが持つ考え方を聞ける*2というのがとても貴重で楽しかったです。 さて、毎回のことですが*3、残念ながら時間がかぶってしまって参加できなかったセッションもあったので、あとで読むために現時点で発表者の方が公開されている資料一覧をまとめしました。*4 （あとで JJUG CCC 2015 Fall のページにもリンクが載ると思うんですが、とりあえず自分の方で調べました） Room A+B+C+D keynote-1 基調講演
Java8 で java.lang.Object#hashCode() の生成アルゴリズムが変更されていました。 - 地平線に行く
java.lang.Object#hashCode()の性質という記事で書いたのですが、Java の Object#hashCode() の値はただの乱数となっています。 この乱数のアルゴリズムが、Java SE 8 で「線形合同法」から「XORシフト方式」に変更になっていました。 といっても、変更されたのはたった1文字。 VMオプションのデフォルト設定が -XX:hashCode=0 から -XX:hashCode=5 に変わっただけでした。 hotspot-rt Udiff hotspot/src/share/vm/runtime/globals.hpp どういうこと？ もともと、Java の以前の実装*1 *2から、Object#hashCode() のアルゴリズムはVMオプション -XX:hashCode=? で選べるようになっていました。 ですが、デフォルトは長いこと 0(=線形
「null」をフラグとして使うのは、やめた方がいい - 地平線に行く
null をフラグとして使うのは、やめた方がいいと思います。 null は、ただ変数が初期化されていないことを表しているだけです。 この意味以外で、null を使わない方がいいと思います。 null をフラグとして使う 「null をフラグとして使う」というのは、「null なら xxxx」というように、null が何らかの意味を持って使われていることを指します。 例えば、下記のコードでは「null はゲストユーザを指すフラグ」として使われています。 /** * ユーザ用のヘッダを作る処理 */ public String createHeader(User user){ (…中略…) String name; if(user != null){ name = user.getName(); }else{ name = "Guest"; // null ならゲストユーザ } 問題点 これの
Java7 Update6 で String クラスがさらにリファクタリングされていました - 地平線に行く
2012年8月14日に登場した Java SE 7 Update6 で、またしても String クラスがリファクタリングされていました！ そこで、そこがどういう風に変わったのかを詳しく調べてみました。 フィールド変数 count と offset が削除されました Stringクラスにあった4つのフィールド変数のうち、count と offset が削除されました。 /** The value is used for character storage. */ private final char value[]; - /** The offset is the first index of the storage that is used. */ - private final int offset; - - /** The count is the number of charact
Java6 と Java7 の挙動の違いは、バグではありませんでした。 - 地平線に行く
前回の記事（「Java6 と Java7 の挙動の違い（バグ？）」）に、id:expf さんからコメントをいただきました。 おそらく、最初のprintStackTrace呼び出しではStackOverflowErrorが出ていると思います。 その後、１つ前のTest.mainがcatch→printStackTrace呼び出し→StackOverflowError を繰り返して、少しずつ使えるスタックが増えます。 Java6のケースだと、途中で何回か「クラス名は出力できたがその後のスタック出力前にStackOverflowError」があるため、「java.lang.StackOverflowError」が何回も出力されているのだと思います。 Java7のケースでは、IdentityHashMapの初期化まで処理が進むようになると、初期化中にStackOverflowErrorが出て、１つ
java.lang.Object#hashCode()の性質 - 地平線に行く
この前、ふと Object クラスの JavaDoc を見ていたら、こんな記述がありました。 できるかぎり、Object クラスで定義される hashCode メソッドは、異なるオブジェクトについては異なる整数値を返します。 Oracle Technology Network for Java Developers | Oracle Technology Network | Oracle この「できるかぎり」って、どのぐらいなんでしょうか。 オブジェクト数に比例して、衝突していました。 さくっとコードを書いてみました*1。 結果は以下のグラフの通りです。 （一定数（横軸）のオブジェクトを生成し、ハッシュコードの衝突割合（縦軸）を調べました） オブジェクトが増えれば増えるほど、衝突確率が高まっていきます。 オブジェクトが100万個だと衝突確率は 1.46% でしたが、5,000万個だと 47
Java7 で String クラスがリファクタリングされていました - 地平線に行く
先日、ついに JavaSE 7 がリリースされました！ そこで、早速ダウンロードして、Java7 のソースコード(src.zip)を Java6と比較してみたところ、公表はされていないのですが、ちょこちょことリファクタリングされていることがわかりました。 そこで、そのうち String クラスについて調べてみました。 splitメソッド - 独自処理による高速化 いままでは、String#split(〜) は正規表現 (Patternクラス) に処理を移譲するだけでした。 // (Java6) Stringクラス、2291行目〜 public String[] split(String regex, int limit) { return Pattern.compile(regex).split(this, limit); } それが、単純な区切り文字なら正規表現を使わないで独自に処理をす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
