水冷服を使って一ヶ月ぐらい経ったのでレビュー

まとめ

• 脇の下を冷やそう（個人差はあるかも）
• うまくハマる用途とハマらなさそうな用途はある
• 今はまだ洗練されていないガジェットではある（けど今必要）

買った製品

山真製鋸 アイスマンベスト PRO 2023

yamashinseikyo.com

ワークマンの水冷服も「話題のアイスマンインナーベストPRO! ついにワークマンとコラボ!」とあるのでコレと同等品なはずです。

workman.jp

冷却効果はどんな感じか？

日陰や室内だとかなり涼しく感じます。一方、三十℃台後半直射日光下のような環境だとあまり涼しい感じはしません。「涼しい」ではなく「活動限界を伸ばす」的な印象で、「野外エアコン」的な効果を期待している人は失望するかなと。とはいえ汗の出方はだいぶ抑えられます。

また、これは個人差があるかもしれませんが、通常の装着方法だと背中と胸が局所的に冷えるだけで全身が冷えてこないのですね。特に頭部がしんどい。「体は冷えているけれど頭部が熱々」状態になります。
対応策としては、デフォルトの装着方法とは別にマニュアルに書かれている「腋下を冷やす装着方法」（びろーんと伸びている部分を胸ではなく脇に当てる着方）だと「体は冷えているけれど頭部が熱々」状態がだいぶ改善される印象です。

ref. https://yamashinseikyo.com/item-photo/water/iceman/manual/iceman-manual.pdf

「水冷服使ってみたけどあんま効果なくない？」「思ってたほどじゃない」的な印象の人は一度この方法を試すと良いかもです。ただし、この装着方法でも直射日光下だと帽子は必須かなと。日光の熱が強すぎます。

持続時間はどれぐらいか？

凍ったペットボトル一本でだいたい１時間半ぐらいは持つ感じです。間欠運転モードを使ってもせいぜいプラス三十分ぐらいで、このモードはあくまで「バッテリーを長持ちさせる」目的っぽいです。ポンプを完全に切った状態でも加えて三十分ぐらい。

長期間使用する場合は予備の凍結ペットボトルを持っておくか、コンビニで凍結ペットボトル飲料や氷を買うという選択肢はあります。

リュックサックと相性悪いのでは？（なんとかなる）

https://twitter.com/ka_ka_xyz/status/1678931597121265670

物理出社した時に水冷服の上に「macBook + iPad + その他もろもろ」が入ったリュックを背負ってみたけど、なんとかなりました（「なんとかなった」であって「すごい合う」では無いのは注意）。

• リュックの背中に当たる側に、クッションになりそうなものを多めに詰めておく
• リュックの肩紐は長めにしておく
• 肩の上について。水冷服の水が流れる部分がリュックの肩紐で潰されないよう気をつける

あたりがコツ。ただ、荷物を背負うという点ではどうしても不便になります。毎日だと辛そう。

相性の良い用途と悪そうな用途

三十分～１時間半程度で収まるような用途には最適です。例えば「近所への買い物」「通勤時に使用し、勤務中は職場の冷凍庫でペットボトルを凍らせておいて、退勤時にも使用」的な用途。

一方、「長時間の野外作業」的な用途だとあんまり向かない感じ。使うなら、クーラーボックスに凍結ペットボトルを入れておいて交換できるようにする感じですかね。となると一人で使うには厳しくて、チーム全員で凍結ペットボトルを管理するような方向なのかなと。

不満点

まず前提として、現時点でも「使える」製品です。でもそれはそれとして不満点はあって

• 腋下・頸部の冷却に最適化したデザインにして欲しい

上で書いた通り、腋下を冷却する装着方法はあるのですが、形状をもっと腋下冷却に最適化して欲しい感じです。また、現状だと首の前側あたりも当たって欲しい部位に当たってない感じがあって、そちらも改善を期待したいところ。

ref
weathernews.jp

• バッテリーとコントローラーは分けたほうが良くない？

現製品だとバッテリーとコントローラーが一体化した専用ユニットを使うのですが、給電はモバイルバッテリーに任せたほうが良いんじゃないかな感が。（品質問題はあるものの）モバイルバッテリーがここまで普及してる状況で、それとは別にバッテリーを持つのも面倒なので。

• 結露なんとかならない？

これはもう物理現象なのでしょうがない……高温多湿環境が悪い。そして高温乾燥環境だと空冷服のほうが多分楽。

とまあ色々と思うところはあるとはいえ、今目の前にある猛暑への対応としては現行製品で「使える」のは確かです。仮に「ぼくのかんがえたさいきょうの改善バージョン」が来年出たとしても、今年の暑さを乗り切る役にはたたないので。

野原ひろしとホーマー・シンプソン

Webをふらついてたらとても面白い記事を見かけたのでメモ。

『The Life in The Simpsons Is No Longer Attainable』 (『ザ・シンプソンズで描かれるライフスタイルはもはや達成不可能です』)
www.theatlantic.com

長期シリーズ化している『ザ・シンプソンズ』で描かれるシンプソン家の生活水準は、放送開始当時の90年代では妥当だったものの、2020年時点から見ると同じような収入状況では手が届かないものだよねと言う話です。

で、当然これ本邦の『クレヨンしんちゃん』における「ひろしハイスペ過ぎワロス」問題を思い出してしまうわけで。

https://t.co/0gs40Ftfg6

「"The Simpsons"のホーマー一家の家計設定は90年代当時は妥当だったが、現在のアメリカ中産階級からかけ離れている」的な記事を見つけて、日本での「野原ひろし一家の家計設定は……」論とのあまりの類似性に爆笑している。

— Ka-Ka (@ka_ka_xyz) 2023年1月15日

両者についてどのへんが一致していてどのへんが異なるのかをメモってみます。

注意: 『クレヨンしんちゃん』も『ザ・シンプソンズ』も10年以上まともに見ていないので、見る人が見たらかなり見当違いなことを書いている可能性はあります。

野原ひろしの場合

『90年代初頭の感覚だと「うだつの上がらないサラリーマン」的に描かれていた野原ひろしが現在の基準で見ると勝ち組エリートサラリーマンじゃねーかワロス』的な話はWeb上では頻出していますが、とりあえず目についたものを数件ピックアップしてみます。

rebuild-life.hatenablog.jp

togetter.com

ちなみに、35歳で年収650万円と言う数字の根拠については以下のpixiv大百科記事が参考になりました。公式設定というよりエピソードからの推定値な模様です。また、記事を読んだ限りだと手取りではなく額面（ついでに、このpixiv大百科でも『The Atlantic』記事への言及がありました）。

dic.pixiv.net

さて、ここで現実社会で30代の所得分布が90年代以降にどう変化したのかのデータを見てみます。

第1部 少子化対策の現状（第1章 4）: 子ども・子育て本部 - 内閣府

第1-1-18図　30歳代の所得分布

ヒストグラムの階層の切り方がちょっと気になるところですが、野原ひろしが含まれる「500~699万円」階層の比率は1997年には約24%だったのが、2017年には16%程度まで低下しています。これぐらいの給与水準の人が劇的に少なくなり、逆に年収299万円以下の層が増えているのが分かります。

90年代以降に日本全体で給与水準が下がり、野原ひろし的な給与水準が相対的に「勝ち組」化しているのは確かです。一方でネットでよく言われるような庶民には手の届かないライフスタイルという訳でも無いよねという印象。減ったは減ったけどそこそこの割合で居る感じですね。

ホーマー・シンプソンの場合

『The Life in The Simpsons Is No Longer Attainable』をざっくりまとめると

• 90年代時点でホーマー・シンプソンの年収は約 25,000ドル
• 当時は、この収入で5人家族を支えて（余裕は無いものの）そこそこ安定した生活を送るという設定には説得力があった
• この収入をインフレ調整すると2020年時点で42,000 ドル（全米での収入中央値のだいたい真ん中ぐらい）になるはず
• でも2020年時点だと家や医療費や大学授業料はそれ以上に上がってるし、インフレ調整後の収入で安定した生活とか無理無理絶対無理

と。「仮に（経済成長の結果生じた）インフレを調整した給与であっても、90年代当時と同じ水準の生活は無理」という話です。中流層の生活がここ数十年でだいぶ辛くなったと。

まとめ

90年代から続く長期シリーズである『クレヨンしんちゃん』と『ザ・シンプソンズ』の両方について「もうこの設定で"普通の中流"は無理じゃねーか」的な言説がある。内容としては

• 『クレヨンしんちゃん』の野原ひろしの場合、日本で続くデフレにより連載開始当初の「うだつの上がらない普通の会社員」的な設定が相対的に「勝ち組」化したという語られ方（ただ、今でもそういう水準の人はそこそこ居る）
• 『ザ・シンプソンズ』のホーマー・シンプソンについては、米国で続くインフレを調整した後の（統計上は「中流」のはずの）収入では生活がきっつい。「中流の没落」的な語られ方（少なくとも、今回取り上げた記事だとそう）。

と。

背景にある経済状況が明確に違っていても、90年代的な「中流」が成り立たなくなっているという点で共通するというのはなかなか闇が深いというか。

近傍恒星系ビューワ（Nearby Stars Viewer）つくったよ

連休なのでつくった。半径100光年ぐらいの近傍恒星系立体図。

Screen shot of Nearby Stars Viewer

うごくもの（github pages）。IE以外のメジャーなブラウザなら多分うごくはず。
ka-ka-xyz.github.io

ソース
github.com

コード自体はMITライセンスですが、近傍恒星系のCSVデータについてはコードから除外しています（このあたりは後述）。

なぜ作ったのか（おじさんなのでアプリをネタに自分語りする）

こういうの（図は wikipedia: 近い恒星の一覧から）を自分で作ってぐりぐり動かしてみたいなーという欲求がどこから来たのかと言う話。

「太陽系の近くにある恒星系の立体表示」について、自分の原体験としては中学～高校の頃に読んだベンフォード『星々の海をこえて』に出てきた近傍恒星系立体星図です。年代としては90年代前半ぐらい。

星々の海をこえて (ハヤカワ文庫SF)

ベンフォード『星々の海をこえて』星図

「太陽系の近くにいろんな恒星系があって位置も分かっていて立体的に俯瞰することができる」という概念、痺れませんか？自分は痺れた。

で、次に出会ったのが数年後に石原藤夫『《光世紀世界》への招待 －近距離の恒星をさぐる－』に出ていた星表。

www.shokabo.co.jp

この頃はまだ「光世紀世界」シリーズは未読だったのですが、この本で初めて存在を知った記憶。さらにその頃から谷甲州「航空宇宙軍史」シリーズの『終わりなき索敵』の連載も始まって、脳内はまさに近傍恒星系ブーム……だったような気がしないでもない。

終わりなき索敵〈上〉 [航空宇宙軍史] (ハヤカワ文庫JA 569)

終わりなき索敵〈下〉 (ハヤカワ文庫JA―航空宇宙軍史 570)

で、それから数年後。大学に入ってから『《光世紀世界》への招待』の星表から20～30個ぐらい抜き出して「近傍恒星系ビューワ」的なモノを作ってました。開発環境はBorland C++ Builder。当時はまだコードを気軽に公開するには結構ハードルが高かったし、データも書籍からコピーしているものだったのでフリーウェアとして公開するのも微妙だしということでそのままお蔵入り。
あと、出来もあまり良くなかった。

で、いつの日かまた（ちゃんとマトモな形で）作り直してみたいなあ……と思ったり忘れてたりしていたけれど、なんとなく今作ってみたという流れ。

近傍恒星系のデータについて

ぶっちゃけ、プログラムそのものは（今の自分にとっては）全く面倒ではないのです（あ、コード見てまさかり投げないで）。面倒なのはデータを揃えること……ではあるのですが、そのあたりは先達はあらまほしきことで、独自にまとめられている方々がいらっしゃいました。CSVデータとして直交座標の値（x,y,z）があるので、あとはもうそれを表示するだけなのです。すごい。

100lightyear.hatenadiary.jp

startide.jp

今回は「拡張光世紀星表 (仮称)」の半径100光年ぶんの「拡張光世紀星表 (2016-10-23)」を使用することに。以下のとおり「データについては特に権利を主張できるようなものではなく、ご自由に利用いただいてかまいません。」とのことで、ご許諾いただけました。

はじめまして。

ブラウザ上で「光世紀拡張星表(仮称)」を表示するモノを作ってみました。
せっかくなのでgithubで（もし可能であれば制約の緩いMITライセンスで）公開したいのですが、CSVデータの利用について何かしら制約はあるのでしょうか？ pic.twitter.com/iV1pBbRPVO

— Ka-Ka (@ka_ka_xyz) 2022年5月5日

こんにちは。はじめまして。

注目いただきありがとうございます。データについては特に権利を主張できるようなものではなく、ご自由に利用いただいてかまいません。公開を楽しみにしています。(自分もThree.jsによるビジュアライザを作ってみようという野心はあるのですが手がついていません。)

— dtanak (@dtanak) 2022年5月5日

ただ、MITライセンスは条件として「著作権表示」が入るので、公開コードには「拡張光世紀星表 (2016-10-23)」のデータは含めていません（デモ用のgithub pages側のデータには含めていますが）。また、ライセンスファイルに「stars.csvの内容については除外する」と明示しました（ほんとにこれでいいのかどうか自信はあんまりないですが）。

github.com
github.com

開発メモ的な

three.js何となく分かってきた？ pic.twitter.com/z02cmEYiZy

— Ka-Ka (@ka_ka_xyz) 2022年5月2日

create-react-app雑感

ejectして色々ビビるなど。

package.jsonをみてると、「なんでこいつがdevDependenciesじゃなくてdependenciesに居るの？」なpackageがてんこ盛りで目眩が……

— Ka-Ka (@ka_ka_xyz) 2022年5月1日

「reactとtypescriptが使える最低限の環境がほしい」みたいな用途には色々過剰な気がする。

three.js雑感

「こういうふうに書けば動くよ」的な情報は結構大量にあるのだけれど、古いAPIを使ったものが多く、このビューワで使用したバージョンでは動かない（プロパティやメソッドが存在しなかったりクラス自体が存在しなかったり）というケースがかなりあるという印象。
結構試行錯誤が必要でした。
ただ、事前にぼんやりと「マウスやタッチ操作でカメラを動かすのは大変そうだなあ」的に思ってた部分についてはOrbitControlsを使うとほぼ何も書かずに解決できてとても便利。

threejs.org

眉村卓『引き潮のとき』感想

近所の図書館に眉村卓『引き潮のとき』全巻（1～5巻）の在庫があったので年末の時間を使って読んでみた。と感想を書きたいところだけれど、結構思い入れのある（一方で、これまで全巻読む機会が無かった）作品なので、まずはちょっと昔語りを。

『引き潮のとき』との出会い

自分がSFマガジンを読み始めたのが、谷甲州『終わりなき索敵』の連載が始まった１９９２年で、そのときに連載中の『引き潮のとき』を読んだのが眉村卓との初遭遇でした。ただ、その時点で『引き潮のとき』連載が既に100話を超えていて(当時のSFMは月刊だったので、つまり既に8～9年の間連載が続いていて)、当然ながらあらすじもかなり大胆不敵に圧縮されてたのでよく分からず、他の『司政官』シリーズについてもまだ読んでおらずという状態だったので、正直なところ最初は

読んでいて非常に心地よいものの、延々と自問自答を繰り返しているだけで話がどんどん先へ続いていって、一年経ってもストーリーが進んだのか進んでないのかよく分からない（そもそもあらすじにある最終目的の「星区ブロック化阻止」というのもよく分からない）。最終話も読んだけど、しかしこれはどう解釈したら良いのか…

という感じだったのですね。
ただ、その後に復刊されたハヤカワJA版『司政官』を読んだり、更にその後にハルキ文庫で復刊された『消滅の光輪』を読んだりして『司政官』シリーズの世界観や独特の自問自答文章スタイルにも慣れて、『司政官』シリーズのファンにはなったのですが、しかしこのシリーズと初遭遇した『引き潮のとき』だけは、「そもそもストーリーの最初の頃が全くわからない」という状態のままでずるずると来てしまったのです。なんといっても文庫化されなかったし。

bookmeter.com

bookmeter.com

で、10年ほど前に創元推理文庫で『司政官』シリーズが復刊されたときに、いよいよ文庫化されるか！と思ったのですが、されずじまい。

www.tsogen.co.jp

www.tsogen.co.jp

その当時だと古書で全巻揃えたら3万円ちょっとぐらいになっていて、そこまでかけて古書で揃えるよりも創元推理文庫で文庫化を待つか…と思っていたのですが、2019年に著者の眉村卓氏が死去。

www.asahi.com

そしてあれよあれよという間に古書価格が高騰(現在はだいぶ落ち着いてますが)

定期的に眉村卓『引き潮のとき』を全巻揃えたらいくら掛かるか検索してるのだけど、流石にここまでぶっ飛んだ値段が付くと「あ、止め止め」ってなるな

（著作権利者にお金が流れる訳でもなし pic.twitter.com/jAhRFPxuBX

— Ka-Ka (@ka_ka_xyz) 2020年5月24日

これはもう手を出せないな…古書で買っても権利者にお金が廻るわけでもないし…ということで、復刊待ちも古書で揃えるのも諦め、図書館で借りて読むことに。

ということで感想（ネタバレあり）

『アルスラーン戦記』完走、またはエラム史観の誘惑

ネタバレを含むのでTwitterではなくこちらで。

完走に至るまでの経緯

改めて書く必要も無いとはおもいますが、『アルスラーン戦記』について。
ざっくり言うと、架空世界における中世イラン風のパルス王国（ただし、イスラム教要素なし）を舞台とした大河ファンタジー小説シリーズです。

第一部(1巻から7巻)までは、パルスの王太子であるアルスラーンが、パルス王国へ侵攻してきたルシタニア王国(史実の十字軍に相当)を撃退し、王位に就くまでの物語が語られます。そして第二部(8巻～16巻)では、太古の昔に封印された「蛇王」ザッハークの復活とそれを阻止しようとするアルスラーン王という、第一部と比較するとファンタジー色が全面に出たストーリーとなります。

小説版『アルスラーン戦記』については中学生の頃(1990年代初頭)から読み始めていて、当時の自分にとっては『アラブから見た十字軍』のような視点や、「奴隷を開放するだけでは問題は解決しない。その後の衣食住も含めた解決が必要」といった主張は眩しく思えたものです。流石に2020年時点だと後者はともかく前者のキリスト教観は雑すぎる感じはありますが、しかしながら『アルスラーン戦記』で描かれた中世キリスト教観が踏み台になることで、あとに続く中世キリスト教を扱った諸作品においてより深いキリスト教の描き方が出来たのではないかとも思います*1。

ただ、第二部に入ってからは、作者の書こうとしている物語と自分が求めている物語にかなり食い違いが出てきたというか、超自然の怪物や陰謀が大きな力を持つというストーリーなのでどうししても第一部とはノリがかなり違うのが気になって、いつしか新刊を買うのも止めてしまいました。
(あと、90年代中盤ぐらいからの田中芳樹作品は全体的になんというか「失速」していたという印象があって……)

という感じだったのですが、先日ちょっとしたきっかけで荒川弘コミック版『アルスラーン戦記』を読んでいたら、これがまた面白くて面白くて(現在、小説版の第一部中盤ぐらいまで進展してます)。

www.hanmoto.com

これでなんというか「アルスラーン読みたい欲求」が再点火したので小説版も1巻から読み直し、これまで読んでいなかった10巻以降もまとめ買いして読んでみたのですねという経緯。

以下、結末への言及を含むネタバレ注意。

*1:荒川弘コミック版『アルスラーン戦記』では、このあたりのフォローがちゃんと入っていて流石

『「就職氷河期」なんてあったんだろうか？』論について

ブコメだと書ききれないのでここで。

finalvent.cocolog-nifty.com

とあるもののちょっと微妙で。失業率から見てみるとまるで違った光景が見えてくるわけで

統計局ホームページ/労働力調査 長期時系列データ
労働力調査　長期時系列データ の「表3 (4) 年齢階級（5歳階級）別完全失業者数及び完全失業率」から年齢階層別の完全失業率をグラフ化したもの

年齢階層別完全失業率

これを見る限りだと

1. 失業率を見ると1990年台中盤から2000年台前半までの所謂「氷河期」には24歳までの年齢で特に顕著に他の期間では見られない失業率の上昇と長期の高止まりが発生しており、特異な期間と言って良いのではないか
2. 大卒者が含まれない年齢階層(15～19歳、グラフの青色系列)でも「氷河期」で失業率は高止まりしており、"安定雇用を求めて増加した大卒者"や"そもそも大学生が増えた分、就職先は争われるようになるだろう。"という話でもなさそう

といえるかなと。失業率だとここまではっきり見えている就職難が有効求人倍率で見えてこないあたりは本職の社会学者の人の守備範囲だと思うが、少なくとも失業率を見ないで有効求人倍率でだけ語るのは無理があると思う。
また、

思い返すと、私が子供のころや青年期でもいつも就職しやすかったわけでもない。当時、就職できなかった人はどうなったかというと、おそらく自営業になっていたのではないか。

とあるものの

中小企業庁：2．中小企業を巡る環境の変化と開業率

を見ると、1970年台以降ずっと20代の自営業者は少なく、30代以降で増える（まあ元手とかは必要だろうし）データがあって、新規大卒者が自営業者になるというルートは70年台でもかなり珍しいものだったはず。30代以降でも1980年台からずっと減少傾向は続いていて自営業者が減少しているものの、新規大卒者云々とはまた別の話。

Javaコード内でjfrファイルを読もうとすると互換性に気をつけないといけない話

まとめ:

• jfrファイルをjavaコードから読み込むときは、jfrの監視対象javaプロセスのバージョンに気をつける必要がある。
• JMCから開く場合には特に気にする必要はない
• ローカルでざっくり見た結果だから保証はしないよ

Java Flight Recorder (JFR)とは

Java Flight Recorder (JFR)は実行中のJavaプロセスのプロファイルを取得するツールです。
現在のところは本番環境で使用するには商業利用ライセンスが必要ですが、本番ではない環境でのパフォーマンス問題調査に無くてはならないものです。

Java Flight Recorderについて

注意:
Java Flight Recorderを本番で使用するには、商用ライセンスが必要です。

将来的にJava Mission Control (JMC)がオープンソースへ移行することでJFRの商用ライセンス縛りも外れるのではないか...と言われていますが、Oracleからその辺あんまり詳しいアナウンスは出ていないのでよくわかりません。
JMC Open Sourced! – Marcus Hirt

で、このJFRで生成される*.jfrファイルは、通常はJMCから読み込むのですが、実はJavaコード中で読み込むことも可能です。しかし...というのが本題。

jfrファイルを読み込む方法

1. jfr.jarを使用する (java8まで)

${JDK_HOME}/jre/lib/jfr.jar にclasspathを通すと、jfrファイルを読み込むAPIを参照できます。
読み込みはざっくりこんな感じ。

非公開APIなので注意すること。
あと、JFRファイルはデフォルトで圧縮がかかっているようなので、読み込む前に解凍処理を忘れずに。

2. java jfr APIを使用する

Java9以降、jfrを読み込むためのAPIが公開APIとして実装されました。
jdk.jfr (Java SE 9 & JDK 9 )

読み込みはざっくりこんな感じ

バージョン互換問題

Java9以降であれば公開APIを使えば良いんじゃないかと思っていましたが、思わぬ罠がありました。

測定条件は以下の通り

• java1.8 (1.8.172)、java9 (9.0.1) 、java10 (10.0.1)でjavaアプリ(apache jmeter)を立ち上げ、JFR取得対象とする
• java1.8、java9、java10それぞれのjcmdを使用して、上のそれぞれのアプリについてのJFRを取得する
• 上で貼ったコードをjava9環境で実行する(java8 のjfr.jarへclasspathを通した状態)

結果は以下の通り

取得対象Java version	jcmdのJava version	jfr.jarによる読み込み	jfr APIによる読み込み
java1.8	java1.8	問題なし	エラー1
java1.8	java9	問題なし	エラー1
java1.8	java10	問題なし	エラー1
java 9	java1.8	エラー2	問題なし
java 9	java9	エラー2	問題なし
java 9	java10	エラー2	問題なし
java 10	java1.8	エラー3	問題なし
java 10	java9	エラー3	問題なし
java 10	java10	エラー3	問題なし

つまり、jfr.jarはjava9以降のプロセスから取得したjfrを読めないし、一方でjfr APIはjava1.8プロセスから取得したjfrを読めないという話ですね。そして、取得対象のバージョンには依存するものの取得する側のjcmd(多分JMCも)のバージョンには依存しない。
ローカル環境でしか検証していないけれど多分あってるはず。

エラー1の内容は以下の通り。

java.io.IOException: File version 0.9. Only Java Flight Recorder files of version 1.x can be read by this JDK.
	at jdk.jfr/jdk.jfr.internal.consumer.ChunkHeader.<init>(ChunkHeader.java:56)
	at jdk.jfr/jdk.jfr.internal.consumer.ChunkHeader.<init>(ChunkHeader.java:38)
	at jdk.jfr/jdk.jfr.consumer.ChunkParser.<init>(ChunkParser.java:35)
	at jdk.jfr/jdk.jfr.consumer.RecordingFile.findNext(RecordingFile.java:181)
	at jdk.jfr/jdk.jfr.consumer.RecordingFile.<init>(RecordingFile.java:63)
	at jdk.jfr/jdk.jfr.consumer.RecordingFile.readAllEvents(RecordingFile.java:168)
	at jfr_example.Jdk9JfrReader.read(Jdk9JfrReader.java:31)
	at jfr_example.Main.main(Main.java:23)

エラー2

java.lang.RuntimeException: oracle.jrockit.jfr.parser.ParseException: Bad descriptor section, id=65536
	at oracle.jrockit.jfr.parser.Parser$1.hasNext(Parser.java:165)
	at jfr_example.Jdk8JfrReader.read(Jdk8JfrReader.java:31)
	at jfr_example.Main.main(Main.java:18)
Caused by: oracle.jrockit.jfr.parser.ParseException: Bad descriptor section, id=65536
	at oracle.jrockit.jfr.parser.ChunkParser.readDescriptors(ChunkParser.java:555)
	at oracle.jrockit.jfr.parser.ChunkParser.begin(ChunkParser.java:230)
	at oracle.jrockit.jfr.parser.ChunkParser.<init>(ChunkParser.java:95)
	at oracle.jrockit.jfr.parser.Parser.next(Parser.java:124)
	at oracle.jrockit.jfr.parser.Parser$1.hasNext(Parser.java:163)
	... 2 more

エラー3

java.lang.RuntimeException: java.nio.BufferUnderflowException
	at oracle.jrockit.jfr.parser.Parser$1.hasNext(Parser.java:165)
	at jfr_example.Jdk8JfrReader.read(Jdk8JfrReader.java:31)
	at jfr_example.Main.main(Main.java:18)
Caused by: java.nio.BufferUnderflowException
	at java.base/java.nio.Buffer.nextGetIndex(Buffer.java:634)
	at java.base/java.nio.DirectByteBuffer.getInt(DirectByteBuffer.java:686)
	at oracle.jrockit.jfr.parser.MappedFLRInput.getInt(MappedFLRInput.java:79)
	at oracle.jrockit.jfr.parser.ChunkParser.readDescriptors(ChunkParser.java:552)
	at oracle.jrockit.jfr.parser.ChunkParser.begin(ChunkParser.java:230)
	at oracle.jrockit.jfr.parser.ChunkParser.<init>(ChunkParser.java:95)
	at oracle.jrockit.jfr.parser.Parser.next(Parser.java:124)
	at oracle.jrockit.jfr.parser.Parser$1.hasNext(Parser.java:163)
	... 2 more

なので、JFRをjavaから読む何かを書くときにはこの辺を気をつけないと「一年前に取得したJFRファイルが読めねー！」って事になるので注意が必要です。
あと、jfrファイルをJavaコードではなくJMCで開く場合には、特に問題は発生しません。