VCSSLの最新版をリリース、Java24上での非互換な挙動に対処

RINEARN では先日、VCSSLの最新版 Ver.3.4.50 をリリースしました。以下のページからダウンロードできます：

• 最新版VCSSLのダウンロード

今回のリリースは機能追加ではなく、「Java 24 環境上において、それ以前の環境と微妙に変わってしまう挙動」への対処がメインです。

以下、詳細をお知らせいたします。

先月リリースされた「Java 24」

Java 24 のリリース

VCSSLのインタープリタはJava言語で実装されており、Java言語の実行環境（Java仮想マシン）上で動作します。 その土台となるJava言語は、（一時期は停滞していましたが）近年は開発が活発化していて更新ペースが速く、概ね半年ごと（春と秋）にメジャーバージョンアップします。

そして先月、Java言語＆環境の最新メジャーアップデート版である Java 24 がリリースされました。

メジャーアップデートでは一部挙動が変わる場合がある

Java言語環境のメジャーアップデートでは、既存コードの挙動が変わってしまう事が一応あり得ます。 Java言語では、そのような破壊的変更はなるべく生じないように配慮されているのですが、それでも「挙動が実装依存」とされているような処理の振る舞い変わってしまうケースがたまにあります。

となると、そのJava言語の実行環境上で走る、VCSSL実行環境やその他Java製アプリケーションの挙動も、つられて変化してしまう事がしばしば生じ得ます。

今回は、実際に微妙に変わってしまった挙動を、過去の環境と（なるべく）同じにするための対策版

今回もそうで、詳細は後ほど解説しますが、どうも 「特定の条件下でのファイルパス取得処理（仕様は実装依存）の挙動が、Java 23 以前と Java 24 で微妙に変わっている」（※ どの処理を使って取得するかにもよります） という現象が生じていました。

詳細は後述しますが、後者で得られるファイルパスも別に間違いではない（特殊な条件下での形式が微妙に違う）ものなので、新しく書かれるVCSSLスクリプトにおいては大して問題にならないかもしれません。

しかし、過去に書かれたVCSSLスクリプトの処理においては、ファイルパスの形式が変わると記述当時の想定と違ってしまい、問題となる可能性があります。

そのような「環境やバージョンによって挙動が微妙に変わる」というような点は、完全に無くす事は難しいのですが、なるべくなら無くしたいところです。

そこで今回のアップデートでは、VCSSLのインタープリタ側に対策措置を入れ込み、その上で走るVCSSLスクリプトの挙動を、過去の環境と（なるべく）同じにするための回避策を入れ込みました。

差異が生じていた挙動

今回のアップデートで対策した点について説明するために、まずどのような差異が生じていたかを見てみましょう。

前提: ネットワークドライブについて

まずは前提の説明です。Windows では、ネットワーク上にある他のPCの共有フォルダなどを、手元のPCの「ネットワークドライブ」に割り当てて、手元のPC自身に直接接続されているドライブ（Cドライブなど）と同じような感覚で扱えます。

例えば、LAN内にあるローカルIPアドレス「192.168.1.3」のPCが、共有フォルダを公開していたとしましょう。それを Windows 上でのUNC形式で表すと、以下のようなパスだったとします：

このフォルダを、例としてネットワークドライブ「Z」に割り当てるよう設定すると、Cドライブのように「Zドライブ」が出現し、その中身は、上記のフォルダの中身と対応するようになります。そうすると、例えばファイル

に、

としてアクセスできるようになります。入れ子になっているフォルダ階層も、同じ感覚でアクセスできます。

「ネットワークドライブ上のファイルのパスを取得する」という処理の挙動で問題発生

さて、VCSSLでは、File ライブラリの getFilePath 関数を用いて、ファイルの絶対パスを取得できます。

そして、この getFilePath 関数で、ネットワークドライブ上にあるファイルの絶対パスを取得した場合の挙動が、Java 23 環境上と Java 24 環境上で異なるという問題が生じていました。

たとえば以下のようなVCSSLスクリプトで問題が生じます：

これを Java 23 上と 24 上で走るVCSSL実行環境で実行すると、それぞれ以下の結果が得られます：

このように Java 24 上で走るVCSSL実行環境では、ネットワークドライブ部分（Z:）が、ローカルIPアドレスでのUNC形式のパス（\\\\192.168.1.3\share）にまで展開されてしまっていました。Java 23 以前では素直にネットワークドライブ表記のままだったので、挙動が変わってしまったわけです。

付随的な問題

VCSSLスクリプトの処理内容によっては、この「UNC形式への展開」が、付随的な問題を発生させてしまう場合があります。具体的には、「VCSSLスクリプトから、exe やコマンドなどの外部プロセスを実行している場合で、さらにネットワークドライブが絡む場合」が該当します。

というのも、Java経由で Windows のコマンド処理などを行う場合、UNC形式が使えない場面が結構あります。典型的には、Windows のコマンドプロンプトではUNC形式のパスをカレントディレクトリに設定できません。また、外部プロセス実行の際の作業ディレクトリとしても、Java経由だとUNC形式のパスは通りません。

そのような事情で、以下のような「突っ込んだ使い方をしている」ケースでは、既存処理が失敗してしまう可能性があります：

• ネットワークドライブ上にある exe ファイルを参照し、外部プロセスとして実行するVCSSLスクリプト
• ネットワークドライブ上にVCSSLスクリプトがあり、そこを外部プロセスの作業ディレクトリとして用いるような使用状況

今回のアップデート（Ver.3.4.50）では、UNC形式への展開がされないように対策
―― ただし完全な互換の保証はなし

そこで今回のVCSSLのアップデート（Ver.3.4.50）では、絶対パスを取得する際の内部処理を少し変えて、上で見たような「UNC形式への展開が生じている既存処理」を "迂回" するような形で対策しました。

結果的に、先ほどのコード例では、Java 24 環境上でも以下の通り、Java 23 環境以前と同じ結果が得られるようになっています：

ただ、もともと絶対パスの取得に用いていた内部処理も、今回の「迂回策」によって用いた内部処理も、どちらもJava言語的には「挙動は実装依存」という扱いのものです。

従って、あらゆるパターンの入力に対して、以前のバージョンとの等価性が確かめられたわけではありません。逆に、トリッキーな入力パターンでは、今回の対策によって挙動が変わってしまっている可能性もあるかもしれません。

しかしながら、「ネットワークドライブのパスが、UNC形式のパスになる」という挙動は、先述の通り影響範囲が大きく、そちらを解消する事を最優先しました。

最後に

Java 24 上で既存の VCSSL スクリプトを実行する場合は、VCSSL 3.4.50 以降のバージョンを

今回の更新によって対策された挙動については、以上の通りです。

混乱とお手数をお掛けしてしまい誠に申し訳ございませんが、Java 24 上の環境で、過去に記述された VCSSL スクリプトを実行する場合は、VCSSL 3.4.50 以降のバージョンをご使用いただうようお願いいたします。 「それでも何か挙動が変わってるぞ？」という場合は、スクリプト（または該当処理のコードスニペット）をお送りいただけましたら調査いたしますので、御気軽にお尋ねいただけますと幸いです。

VCSSLのアップデートについては、今後も随時このコーナーでお伝えしていきます。