Oracle Certified Java Programmer, Gold SE 11取得しました
先日、OCJ-PのJava11対応バージョンの日本語試験が夏前にリリースされていたことに気が付きました。これは少なくとも私の認識している限りではJava8対応バージョンの試験のリリース後の初めての新バージョンの試験であり、Java9で行われた重大な変更であるモジュールシステムの導入やその後加えられたインターフェース定義の拡張などの内容を含むものです。
受験したのは"Upgrade OCJP Java 6, 7 & 8 to Java SE 11 Developer"(1Z0-817)試験です。OCJ-Pの旧バージョン保持者に対してアップグレード機会を提供するものです。私の場合はJava SE 8→Java SE 11ということになります(数年前にJava SE 6→Java SE 8にアップグレードしました)。Oracle社の公式サイトによればその内容は以下の通り:
- モジュールの理解
- モジュール型アプリケーションにおけるサービス
- ディレクティブなど、サービスのコンポーネント
- サービス・タイプの設計。ServiceLoaderを使用したサービスのロード。コンシューマ・モジュールとプロバイダ・モジュールが含まれているサービスの依存関係のチェック
- Javaのインタフェース
- メソッドによるインタフェースの作成および使用
- 関数型インタフェースの定義および記述
- ストリームに対するラムダ演算
- map、peekおよびflatMapメソッドを使用したストリーム・データの抽出
- findFirst、findAny、anyMatch、allMatchおよびnoneMatchメソッドによる検索を使用したストリーム・データの検索
- オプション・クラスの使用
- ストリームに対するcount、max、min、averageおよびsum演算を使用した計算の実行
- ラムダ式を使用したコレクションのソート
- ストリームに対するCollectorsの使用(groupingByおよびpartitioningBy演算を含む)
- I/O(基本およびNIO2)
- モジュール型アプリケーションへの移行
- Local Variable Typeインタフェースの使用
- ラムダ式の理解
- 並列ストリーム
- 並列ストリームを使用するコードの開発
- ストリームで分解と縮小を実装
- 例外処理とアサーション
- try-with-resources構造の使用
- カスタム例外クラスの作成および使用
実際に受験したところの感想としては、(当たり前といえばそうですが)この箇条書きにあるとおりの内容が出題されたように思います。
モジュールについて「トップダウン移行とボトムアップ移行」という聞き慣れない言葉がありますが、私は「トップダウン移行=既存リソースのJARをモジュールシステムの中で運用する、つまりAutomatic ModuleやUnnamed Moduleを利用する」と理解し、「ボトムアップ移行=新規/既存リソースにmodule-info.javaを組込みコンパイル方法も相応の内容にすることでモジュール化する、つまりNamed Moduleを利用する」と理解しました。
試験で出題される問題の実際についてはここで述べられませんが、Java SE 8の資格を持っている方については、以下の事項をCodeZineやQiitaの記事で学習することで受験準備になると思います:
清水克行『喧嘩両成敗の誕生』
- 作者: 清水克行
- 出版社/メーカー: 講談社
- 発売日: 2006/02/11
- メディア: 単行本(ソフトカバー)
- 購入: 4人 クリック: 50回
- この商品を含むブログ (37件) を見る
中世の「喧嘩」に関する処罰のあり方、それに対する人びとの「もっともだ」「やりすぎだ」「足りていない」といった種々の感想を平易に紹介してくれている点でよし。
ただ「喧嘩両成敗」もしくは「喧嘩両成敗的」措置の結果としての構図に執着しすぎ、紛争当事者双方が厳しく処断されることの、そこに至る意味というか、そうする時の権力者の意図が必ずしも正しく顧みられていないのではないかという印象を受けた。
「両成敗」もしくは「両成敗的」措置には、「平衡」「秩序回復」の意味が込められているケースと、私闘というかたちで検断という本来当事者らに行使を許されていない行為を行い、ときの権力者の権利を侵して秩序を乱したことに対する処罰という意味が込められているケースがあるであろうことは、まま容易に想像がつく。
前者後者の「両成敗」はそもそも処罰の次元を異にしている。前者は紛争当事者やそれを見守る世間一般の思いが権力者の口をして語らせているようなものであり、後者は惣無事令・喧嘩停止令に従わない無法を罰する権力の立場が彼自身の口をして語らせているようなものである。
本書にはそれらを「両成敗」を一緒くた(もしくは一報を無視)している印象を受けた。
ftp通信のputコマンドで553エラー
直近職場で、ftp通信によりファイルをリモートサーバ上にアップロードしてリネームするバッチPGMのエラー事象に悩まされました。
事象はftp通信のputコマンドを実行すると553エラーが発生してしまうというもの。
このエラーコードをキーにしてインターネット上でトラブルシューティング情報を探すと、見つかるのは大概「指定したパスのディレクトリやファイルに対する権限不足」によるエラーのケースです。しかし私が立ち会った事象において権限設定は問題ありませんでした。
あれこれ調べた結果、「バッチPGMがファイルアップロード先を指定する際、ftpプロトコルの仕様に沿ったURLを組み立てられていなかった」が原因とわかりました。
どういうことかというと、ftpでファイルパスを指定する方法にはローカルのファイルシステム同様に相対パスと絶対パスの2つが存在し、ftpのURLもこれに応じて異なるかたちになるのですが、バッチPGMはこれを考慮できていなかったのです:
ドメイン名の直後のスラッシュ(/)はあくまでもURLを構成するフラグメントを区切る文字でありファイルシステムのルートを表すものということでしょうか。ルートを表すにはその後ろにURIエンコードされたスラッシュ(%2f)を記載してパスを記述する必要があるのです。
もちろん相対パス(ftp接続ユーザのホームディレクトリからの相対パス)と絶対パス(ftp接続したリモートサーバのルートからの絶対パス)とでは指示す先がまったく異なります。指し先が異なれば権限どころか存在すらしないというのが普通でしょう。