Java Community ProcessにAssociate Memberとして登録しました。
tomotaka.hatenablog.comJCPのメンバー登録方法(個人 or JUG経由)は、前回のJCPイベントをした際に実際にメンバーに登録されたtomotakaさんのブログを参考にしていただければと思います! - JCPにAssociate Member(個人)として登録 - tomoTaka’s blog https://t.co/RYNhP4X8p1 #kanjava
— じゅくちょー Koichi Sakata (@jyukutyo) July 20, 2018
このツイートとリンクの記事を見て、「あ、これ(JCP)って誰でも参加できるんだ」ということを知り、Associate Memberとして登録を行いました!
JCPそのものやメンバシップについては、じゅくちょーさんの記事が詳しいです。 www.sakatakoichi.com www.sakatakoichi.com
Associate Memberになることで、Java Specification Request(JSR)にContributorとして参加することが出来たり*1、EC選挙で投票を行えたりします。
基本的な登録の流れは上に貼り付けたtomotakaさんの記事の通りなのですが、一部「これは...?」と思った部分があったのでそのあたりを書きたいと思います。
1. 現在はManual Signatureのみ(でも中身は電子署名と一緒?)
The Java Community Process(SM) Program - Participation - newMembership
私が登録したタイミングでは、Manual Signatureにするかどうかのチェックボックスが無く、キャプチャのNOTEに記載があるとおりManual Signatureによる登録プロセスになる模様です。
ただ、SubmitしたところPDFの契約書がメールで届き、それにAcrobat Readerで署名を行い返信する、先程貼り付けたtomotakaさんの記事と同じようなプロセスで登録できました。
FAX送らないといけないのかななどとドキドキしながらメールを待っていましたがあまり気にすることはなかったのかもしれません。
2. 英語の契約書について
完全に私の問題なのですがちゃんとした英語の契約書を書くのが初めてで、 一回目の契約書の送信では記載に誤りがあったために受理されず修正を依頼されてしまいました。
- Signature: 手書きフォントでの署名(Acrobat ReaderのFill & Signを利用する)
- Name: 通常のフォントでの名前(通常の記入(編集)で入力する)
- Title: 役職
- Date: 署名をした日付(dd/mm/yyyy)
最終的に受理された契約書の記載です。
修正を依頼されたのはSignatureのところで、SignatureとNameの違いがわからずどちらも同じようにゴシック体で「Noriyuki Kazusawa」と記載したのですが、Signatureは手書き(cursive)のフォントで記載する必要があったようです。
(契約書が添付された)最初に受信したメールをよく見たら、「署名をするときはAcrobat ReaderのFill & Signを使うと良い(意訳)」と記載があったので、ちゃんと読むべきでした。
登録を終えて
Membersに私も名前が載りました!日本人で個人登録している人は2018年7月時点で9人*2らしいのでざっと見ても日本人はだいぶ少ないですね.. JUG経由での参加をする方が多いのでしょうか
The Java Community Process(SM) Program - Participation - JCP Members
Associate Memberの登録に際して、JCP 浜本様には多大なご協力をいただき登録をすることが出来ました。 浜本様には私の契約書の誤りからその後のJCPプロフィールの同期等についても丁寧にご対応していただき感謝しております!
*1:ContributorになるにはPMOとSpec Leadの承認が必要なようなので、誰でもなれるわけでは無さそうです。多分。
*2:https://jcp.org/aboutJava/communityprocess/JCP_Japan_JUG_visit_July2018.pdf
Gradleでファイルの改行コードをCRLFからLFに変換する
コード
// build.gradle import org.apache.tools.ant.filters.FixCrLfFilter task convert(type: Copy) { from file("CRLFなファイルの置き場所") into file("変換後のファイルの置き場所") filter(FixCrLfFilter, eol:FixCrLfFilter.CrLf.newInstance("lf")) }
ANTLRでの例
今回は、ANTLRv4で出力したコード(Windows環境で出力するとCRLFで出てくる)をLFに変換するコードを記述します。
やり方
1. ANTLRの出力先を一時ディレクトリにする
2でCopyタスクを利用するとき、コピー元とコピー先が一緒だとうまくいかないので、ANTLRv4の出力先を変更します。
Karaffeの例
generateGrammarSource { - outputDirectory = file("${projectDir}/src/main/java/org/karaffe/compiler/frontend/karaffe/antlrautogenerated") + outputDirectory = file("${projectDir}/build/tmp_antlr") }
元々は "${projectDir}/src/main/java/org/karaffe/compiler/frontend/karaffe/antlrautogenerated"
に出力していたのですが、 "${projectDir}/build/tmp_antlr"
に変更しています。
2. 一時ディレクトリから、本来出力したいディレクトリにCopyタスクを使ってコピーする
AntのFixCrLfFilterとCopyタスクを利用して、CRLFからLFに変換します。
task filter(type: Copy, dependsOn: generateGrammarSource) { from file("${projectDir}/build/tmp_antlr") into file("${projectDir}/src/main/java/org/karaffe/compiler/frontend/karaffe/antlrautogenerated") filter(FixCrLfFilter, eol:FixCrLfFilter.CrLf.newInstance("lf")) } compileJava.dependsOn filter
一時ディレクトリに置かれたファイルの改行コードを変換しながら移動するfilter
タスクを実装しました。
このfilter
タスクは、ANTLRが生成したファイルがあることが前提となるので、 dependsOn
に ANTLRプラグインのタスク generateGrammarSource
を設定しています。
さらに、この移動したファイルは compileJava
で利用するため、 compileJavaの依存タスクとしてfilterタスクを追加しています。
これにより、
generateGrammarSource
-> filter
-> compileJava
の順番でタスクが流れていきます。
ANTLR以外で使う場合でも、dependsOnとかを修正すれば使えるかなと。
OpenJDKで遊んでいたらバグを見つけたのでBug Reportを出した話
概要
OpenJDK 11(11-ea+15)で、 java -XX:
とするとセグメンテーション違反で落ちるエラーに遭遇しました。
既に修正が入った最新のEA版が公開されていてもう大丈夫かなという雰囲気なのでバグ発見から報告、修正までの流れ等を記事にします。*1
報告したバグレポートのURL
Java Bug System: [JDK-8204055] SIGSEGV in java -XX: - Java Bug System
Java Bug Database: Bug ID: JDK-8204055 SIGSEGV in java -XX:
見つけたきっかけ
先日のJava Day TokyoでGraalのセッションが聞けたので試そうとしてたのですがなかなかうまく行かなくて、 その試行錯誤中にたまたまtypoし
$ java -XX:
を実行してしまったのが始まりでした。
Unrecognized VM optionとまでは出るのですが、その後のセグフォがなんか変だなというところから、よくよく見てみるとどうやらOpenJDK 10では再現しないことが分かり、バグ報告に至りました。
JDK 11のjavaコマンドで -XX: だけつけるとセグフォで落ちるw
— noko(バイトコードになりたいイッヌ) (@noko_k) May 29, 2018
なんかGraalが有効にならんな〜ってやってたらたまたまバグ踏んだっぽい。 pic.twitter.com/IhbRxabN6c
— noko(バイトコードになりたいイッヌ) (@noko_k) 2018年5月29日
報告方法
以前からバグ報告ページBug Reportがあることは知っていて*2、 既存バグを検索してもそれっぽいのが無かったので普通にバグ報告をしました。
Report Classificationを書くときにちょっと迷うのがComponent/Subcomponentに自分のイメージしたやつがないときなんですが、
間違った選択をして報告をしてしまっても、良い感じに修正してくれるのが良いなぁと思いました。
実際、今回のチケットではjavaコマンドだったのでtoolsのlauncherがそれっぽいかな?とか思っていたのですが、報告後にhotspot/runtimeに修正されていました。
(こういうのってどこで調べれば良いのかがわからない。。。)
バグ報告をすると、Oracleによるレビューが入った上でJDK Bug SystemとOracle Java Bug Databaseに公開されるという流れになるみたいです。
私の場合、報告してから公開されるまで1日ぐらいかかりました。 OracleかOpenJDKのサイトで見たような気がしますが、セキュリティ的な理由とかで すぐ公開しちゃまずいバグかどうか等をレビューして判断しているみたいですね。
昨日のこれチケットになったhttps://t.co/NMeODm21YR
— noko(バイトコードになりたいイッヌ) (@noko_k) 2018年5月30日
報告してから解決に向かうまで
報告者には、バグ報告ページで入力したメールアドレスにこのようなメールが届きます。
記載されているURLを見て、初めて重複バグなのか等がわかるという感じですね。 バグに関する調査や、修正作業はバグチケット上のコメントでやり取りされ、他のチケットの関連付けや修正方法の検討がどんどん進んでいきます。
ところで、「Assigneeに記載されている方の名前、どこかで見たことある気がする...」と思ってググったら、この本を書いた方でした。なんかすごい方っぽい....!
https://www.amazon.co.jp/Programming-Language-Gosling-Holmes-Arnold/dp/0321349806
私の報告したバグが、Oracleのすごいエンジニアによって徐々に紐解かれていくようのは、見ててとても楽しいものですね。
このコメントが投下されたのを見たときは思わず「おぉー!」っとなり、しばらくしてリポジトリに修正がpushされたのを確認して二度「おぉ〜!」となったのは、今まで無かった体験でした。
The SEGV was introduced with the fuzzy matching flag logic refactoring in JDK-8198554. In:
Proposed fix has three parts:
- Update StringUtils::similarity to assert the two strings are not NULL and not zero-length.
- Update Arguments::process_argument to not call fuzzy_match for a zero-length arg.
- Update match_jfr_option to not trip-over the zero-length arg. (Still not quite sure why it does what it does there.)
修正コミット: jdk/jdk: 01e20d8850e3
OpenJDK 11(jdk-11-ea+17) では
修正されていることが確認できました🎉
> /opt/jdk-11-ea15/bin/java -XX: Unrecognized VM option '' fish: '/opt/jdk-11-ea15/bin/java -XX:' terminated by signal SIGSEGV (Address boundary error) > /opt/jdk-11-ea17/bin/java -XX: Unrecognized VM option '' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
おわりに
以上、バグの発見からその報告、解決までを体験できたのでそれを記事にしました。
バグ報告をすると今までにない体験を得られ、英語が書けなくてもコードは伝わる(もちろんちゃんと書けるならそのほうが良い)、ちゃんと修正されるというのが一番の収穫でした。 修正のスピード感も想像よりもずっと速くて、流れも全部コメントで追えることができてというのも良い体験でした。
今度はバグレポと一緒にパッチを送信できるようになりたいなぁという気持ちになったので、のんびり頑張っていきたいと思います。