発端
Java6までは言語仕様の中に命名規約の章があったけどJava7からはなくなった。あとパッケージ名もドメイン名逆順にしろというのが、ローカルでの利用を意図してるなら単一の識別子だけでいいということになった。そのころからlombokみたいにプロダクト名だけのパッケージ名を見るようになった気がする
— きしだൠ (@kis) 2019年1月22日
今までjavaパッケージの命名はドメイン名の逆順というのが通例だと思っていたが、たしかにそれに沿わないライブラリも特にScala系のライブラリで見ることが増えてきた。
そもそもこの命名規則は確かに衝突を避けるためには合理的ではあるもののコード中の記述量が増えるため後発の言語でもまったく真似されていない。
最近のJavaでより短いパッケージの命名が許容されるならとても嬉しいと思い、本当にJavaのFQDN逆順命名規約は無視していいのか調べた。
調査内容
Java言語仕様を当たる
発端となったtweetにも書いてある通り、パッケージの命名規則は言語仕様レベルで記述がある。
そこでJava SE 6から最新の11までの仕様書を調べてみた。
関係する文章をすべて引用・翻訳すると長くなってしまうため以下では要約しつつ翻訳する。また、差分がわかりやすいようにgitコミット化もしてみた。
Java SE 6言語仕様 (gitコミット)
「6 名前」下の「6.8 命名規約」下の「6.8.1 パッケージ名」
広く配布する意図がある場合、パッケージ名は7.7節で述べられる規約に従うべきです。
逆に局所的にしか使わない場合でも、トップレベルのパッケージ名は小文字から始まるべきです。
「7 パッケージ」下の「7.7 一意なパッケージ名」
所有しているインターネットドメイン名を各レベルに分割して順序を逆にしたものをパッケージ名に使用する。
その意図は異なるライブラリ間のパッケージ名1の衝突を避けることである。
Java SE 7言語仕様 (gitコミット(前回との差分))
Java SE 6の「7.7 一意なパッケージ名」および「6.8 命名規約」の項目がなくなり、その中の記述が「6.1 宣言」下の「パッケージ名」へ移っている。
Java SE 8言語仕様 (gitコミット(前回との差分))
「6.1 宣言」下「パッケージ名」の項目はまったく変わっていない。
Java SE 9言語仕様 (gitコミット(前回との差分))
モジュールの追加により項目名が「パッケージ名とモジュール名」に変わった他、モジュール名の命名規約についても書かれている2。
また非常に重要な変更として次の一文が削除されている
Names of packages intended only for local use should have a first identifier that begins with a lowercase letter
利用が局所的なパッケージの名前も最初の識別子の最初の文字は小文字であるべきです。
Java SE 10言語仕様 (gitコミット(前回との差分))
関連個所はJava SE 9と全く変わっていない。
Java SE 11言語仕様 (gitコミット(前回との差分))
関連個所はJava SE 10と全く変わっていない。
[補足] Java SE 8の時点で書かれたチュートリアル内の「パッケージの命名」項目
ほぼJava SE 8の「6.1 宣言」下「パッケージ名」の項目と同じだが、局所的な利用についての記述はない。
言語仕様調査まとめ
言語仕様としては依然ドメイン名の利用を推奨しており、むしろ局所的な利用に関する言及が削除されたりとドメイン名の利用推奨を強化する動きになっている。
最初のtweetの
Java6までは言語仕様の中に命名規約の章があったけどJava7からはなくなった。
はそこ単体では事実ではあるものの記述された内容は他所へ移っただけなので語弊がある。
あとパッケージ名もドメイン名逆順にしろというのが、ローカルでの利用を意図してるなら単一の識別子だけでいいということになった。
これに関してはだれがいいということにしたのか明確に書かれていないが、少なくともJava言語仕様レベルではそのような記述はなくむしろローカルでの利用に関する記述は削除されている。
実際のライブラリをあたる
実際に世の中でよく使われているライブラリがこの命名規則に従っているか調べた。
maven repositoryのpopularからの調査
maven repositoryは公開されているライブラリの相互参照数を調査して、よく他のライブラリから参照されているものをpopularとして表示してくれる。
そこで、最も他のライブラリからの参照が多いトップ100においてパッケージの命名規則がドメインの逆順に従っているかを調べた。
調査のために書いたコード
調査結果
| jarが取得できたライブラリ数 | 規約に従わないライブラリの数 |
|---|---|
| 92 | 9 |
一部素直にjarが取れなかったライブラリは調査から除いている。
具体的に規約に従わないライブラリは以下だった。
| トップレベルパッケージ名 | ライブラリ名 |
|---|---|
| clojure | clojure-1.10.0.jar |
| clojure | tools.nrepl-0.2.13.jar |
| complete,project.clj | clojure-complete-0.2.5.jar |
| scala | scala-library-2.13.0-M5-1775dba.jar |
| scala | scalajs-library_2.12-1.0.0-M6.jar |
| scala | scala-reflect-2.13.0-M5-1775dba.jar |
| kotlin | kotlin-stdlib-1.3.21.jar |
| lombok | lombok-1.18.6.jar |
| okhttp3 | okhttp-3.13.1.jar |
参考: 別角度からの調査
The Top 100 Java Libraries in 2018 - Based on 277,975 Source Files | OverOps Blog
似たようなJavaライブラリの人気度調査を行っている記事があったので、こちらでリストアップされているライブラリについても同様の調査を行った。
調査結果
| ライブラリ数 | 規約に従わないライブラリの数 |
|---|---|
| 100 | 2 |
具体的に規約に従わないライブラリは以下だった。
- backtype.storm
- junit.framework
結論
今回の調査では、Pure Javaの領域ではFQDN逆順命名規約を無視する流れは見つけられなかった。
言語仕様書上は依然所持ドメインの逆順規約を強く推奨しており ローカルでの利用の項目はむしろ最近削除されている。
また有名なライブラリを対象にpackageの命名を調べたが、clojure, scala, kotlinなど別言語用のライブラリを除けば命名規則を無視しているのはlombok, okhttp3, junitなど3全体の3%未満と非常に少なかった。
ただし、ぱっと調べた限りScalaにおいては人気上位のライブラリにおいてこの規約を無視しているライブラリは多い4。
Pure Java以外ではそういった流れがある可能性はあるのでこの点については追加調査が必要。