タグ別アーカイブ: Java

プログラミング小噺三題

スタティックメソッドはどうですか

ちょっと、仕事プログラムで1つのファイルが肥大化傾向があって、「Java クラス 分割」というキーワードでググってみた。
そもそもJavaってのはクラスを分割して書けないという融通の利かない言語で、割と常識的なこととか初心者向けのことを書いてるページが並ぶ。

『何をクラス分割の指針とすべきか』(https://iwamototakashi.hatenadiary.jp/entry/20090530/p1)に書いてあるLCOM (Lack of Cohesion in Methods) ってのが面白い。
元ネタはITmedia。

で、常々失敗したOOPプログラムに接していると、いかに変数を減らすか、いかにインスタンスを減らすかばかり考えているわけですよ、最近は。
で、先程のページの

『ちなみにインスタンス変数のないクラスは、ほぼ不要であると個人的には思っています。そのようなクラスは、
スタティックメソッドの集まりになるのでしょうが:

Static methods are procedural! In OO language stick to OO. And as far as Math.abs(-5) goes, I think Java got it wrong.
I really want to write -5.abs(). Ruby got that one right. Static Methods are Death to Testability

という Miško Hevery 氏の意見(http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/)に私は賛成です。』

なんてことを読んじゃうと、喧嘩売ってんのかと思う。いやまぁ、勝手に読んでるのは私ですが。10年も前の記事なんで、今でも同じ考えとは限らないなと思う。

例に上がってるMath.abs(-5)の書き方は重要ですよ。これ、どっからでも呼べますから。
色々考えて最近はDBのテーブルアクセスは全部スタティックメソッドにしてる。SampleTbl.Record rec = SampleTbl.getById(String id)って感じ。
OOP的な意味では全てファクトリですよ。ファクトリしかないのだから全部スタティックメソッド。
レコードは普通にクラスなんで好きにすればいいけど、本質的にはget/setしかない。
で、SampleTbl.getByIdはコード上どこからでも好きに呼べるのが重要。誰がDBアクセスインスタンスを持ってるかとか気にしない。
そういうのは基本戦略としてメソッド内に封じ込める。

まぁ、スタティックメソッドの集まりに価値のある応用もあるってこと。

あと、Math.abs(-5)を先に作って、-5.abs()は最終的にMath.abs(-5)を呼ぶというような実装もよくやる。逆ではない。

私も関数型言語に触れるまではスタティックメソッドを活用しようとはあまり思わなかった。この10年でだいぶコードの書き方が変わった。

モンティ・ホール問題

三つの選択肢のどれかが当り。出題者はどれが当りか知っている。
回答者が選択した一つ以外の残り二つから出題者がはずれを選んで開ける。
さて、回答者は選択を維持するか変えるかどっちが有利か。これがモンティ・ホール問題。

モンティ・ホール問題が納得いかなくて、なるべく愚直にプログラムを書いてみようかと思い、
具体的にどう書こうかと考えてる間に納得してしまった。でもPythonで一応愚直に書いてみた。
「モンティ・ホール問題 プログラム」でググると似たような愚直なプログラムを書いた人は結構いるので掲載はしない。

Ubuntu 18.04のカスタマイズ

最近Ubuntuを使いにくいなぁと思っていた。問題はGUIで上にバッテリーステータスや日付表示されるパネルのフォントサイズを変更できなかったからだ。
UbuntuがUnityをやめてGNOME 3に移行したことで、どうやって設定変更したら良いのかわからなくなったのだ。VAIO Pro 11は割と画面解像度が高いので、
そのままでは非常に小さい文字しか表示されない。FirefoxやTerminalは個別にフォントサイズを大きくできるのでいいのだが、パネルに表示される日付やらバッテリー残量やらアプリのメニューやらは小さいまま。Unityの頃はディスプレイ画面のdpiを指定することで全体の文字サイズを調整できたのだがそういった機能はなくなったようだ。Kotlinのお試しのためVAIOを活用しようかなと思い、ちょっとググる。

GNOME 3のExtensionでUser Themesを有効にする。~/.themesに独自テーマのディレクトリを用意し、~/.themes/<テーマ名>/gnome-shell/gnome-shell.cssを作る。

# gnome-shell.css
stage {
    font-size: 18pt;
}

Tweaksの[外観 – テーマ – GNOME Shell]で上記<テーマ名>を選ぶ。
これでようやくGNOME 3のパネルの文字が読めるようになる。ともかく老眼には厳しい話だ。

GNOME 3のウィンドウマネージャはMutterというそうだ。dconf-editorでorg.gnome.mutterに幾つか設定がある。
edge-tilingをオフにすると、Ubuntu 18.04でかなりイライラさせられる「ウィンドウを移動させたいだけなのに、
上に持っていくと最大サイズにされてしまう」という問題が解消する。あぁ、嬉しい。

Ubuntuを起動したまま放置すると例えば30分でブランクスクリーンになるように設定している。
マウスを動かしたりするとブランクスクリーンを解除するのだが、Unityの頃にはなかった変な画面になっている。
真ん中にドカンと時計が表示されるロック画面とは違う謎画面。この画面の解除にはキーボード入力を要求する。いや、正確ではないな。
マウスで解除する方法はあるにはあるが、タッチスクリーンにおけるスワイプアップ相当の動きをマウスで行う必要がある。
これ決めた人は明らかに変。どう考えてもおかしい。キーボードくらい押せばいいとか思うでしょ。マシンを落とす(パワーオフにする)にはメニューから電源オフをするのが正しい手順で、
キーボードがなくてもちゃんと行える。逆に、キーボードに電源ボタンがない限り、キーボードだけでマシンを落とす方法はUIには用意されていない。
ノートパソコンはキーボードの近くに電源ボタンがあるからマシだが、デスクトップ機の電源を落とすのに電源ボタンを押すなんてことは普通しない。
という状況にも拘わらずキーボードを要求する、GNOMEは。とにかくストレス。

GNOME Shell Extensionsに「Disable Screen Shield」というツールがあると知る。
その邪魔な画面はScreen Shieldというらしい。これを無効にしてくれる。あぁ、嬉しい。そもそもScreen Shield自体がオプトインにすべき機能だろうに、
更にはオプトアウトすら用意していない。「GNOME Screen Shield」でググると世界中で迷惑がられてます。


アンテナハウス製品におけるJava 11以降の動作確認と動作保証

2019年1月でJava 8のサポートが切れます。
そして、2018年9月下旬、Java 11が予定通り出荷され、お客様からの問い合わせが入っていますので、アンテナハウス製品におけるJava 11以降の動作確認、動作保証について、現段階での方針をお知らせします。

Oracleが、これまで無償で配布してきたJDKのサポートを有償化するという話が出て、いろいろと混乱した話が飛び交いましたが、OpenJDKを使えば、無償で使えます。
OpenJDKは、OracleからJDKのソースコードの提供を受けて、いろんな企業や団体がビルドして無償で配布しているもので、企業や団体によって、有償サポートがあったりなかったり、サポート料やサポート期間もマチマチです。
この辺は、Linuxに各種のディストリビューションがあるのと似ています。
詳しい話は、参考に挙げた記事やサイトをお読みください。

アンテナハウスは、OpenJDKの中でも、LTS(Long Term Support)バージョンのOpenJDKを、無償で、最低4年間は、セキュリティやバグフィックスのアップデートを提供するといっているAdoptOpenJDKによって、動作確認と動作保証を始めています。
AdoptOpenJDKのJava 11は、最低、2022年9月までアップデートが提供される予定です。

AdoptOpenJDK

AdoptOpenJDK Support

First Availability End of Availability [1]
Java 8 (LTS) March 2014 At Least Sep 2023 [2]
Java 9 Sept 2017 March 2018
Java 10 March 2018 Sept 2018
Java 11 (LTS) Sept 2018 At Least Sept 2022 [2]

AdoptOpenJDKでダウンロードできるバイナリのうち、アンテナハウスが動作確認、動作保証の対象とするJava 11は、「OpenJDK 11 Hotspot」です。
Hotspotは、元々Sun(Javaの本家)が作ったJVM(Java仮想マシン)です。Oracleがメンテナンスや機能拡張をしています。これがリファレンスと考えてよいので、このJVMのみ動作保証対象にする予定です。
理由は、JVMは多くの実装があるので、やり出したら、きりがないからです。
たとえば、上記サイトには、Java 11でも、
「OpenJDK 11 with Eclipse OpenJ9」
がありますが、OpenJ9は、IBMが開発したJVMです。これは動作保証の対象にはしない予定です。
アンテナハウス自身が、動作確認、動作保証をするJVMを限定することについては、何卒、ご了承ください。

現在、アンテナハウス製品で使われているJavaのコードは、Java 8のコンパイラでビルドして出荷していますが、動作確認を始めた製品では、いずれも、問題なくJava 11で動いています。
アンテナハウスの製品のうち、Javaを使っている製品については、いずれ、各製品のウェブページで、動作確認が取れたことをお知らせしていく予定です。
なお、Java 8のコンパイラからJava 11のコンパイラに切り替える時期は未定です。
Java 11のコンパイラでビルドすると、Java 11の実行環境が必要になり、Java 8では動かなくなることが予想されます。
2019年1月でJava 8のサポートが切れるといっても、すぐ、Java 11に乗り換えられるお客様は、そんなに多くないだろうと考えていますので、2019年早々のコンパイラの切り替えは考えていません。
Javaを使っているアンテナハウス製品のリリース時期によりますが、今後、1年から数年をかけて、コンパイラを切り替えていくことになるでしょう。

参考:
【GlassFish勉強会レポート】各JDKベンダの動向を知ってJava 11に備えよう
2018年10月5日
杉山貴章

Javaは今も無償です

Oracle Java SE サポート・ロードマップ
(2018年 9月25日更新)

Time to look beyond Oracle’s JDK
Monday, 3 September 2018