AWSは、ローカルマシン上にLinuxコンテナのランタイム、ビルドツール、コマンドラインツールなど一式を簡単にインストールし、コンテナを用いた開発環境を開始できるソフトウェア「Finch」のWindows版を公開しました。
AWS、オープンソースのコンテナ開発ツール「Finch」のWindows版リリース。コンテナのビルドや実行環境一式 － Publickey
⇧「WSL 2 instance」というのが何なのかモヤる...
おそらく、仮想マシンのことだとは思うけど...
⇧ とあったので、調べてみたところ、
⇧ 全てのディストリビューションに「.vhdx」ファイルが存在すると。
「.vhdx」ファイルはと言うと、
VHD (Virtual Hard Disk) and its successor VHDX are file formats representing a virtual hard disk drive (HDD). They may contain what is found on a physical HDD, such as disk partitions and a file system, which in turn can contain files and folders. They are typically used as the hard disk of a virtual machine, are built into modern versions of Windows, and are the native file format for Microsoft's hypervisor (virtual machine system), Hyper-V.
⇧「仮想ハードディスク」らしく、
『They are typically used as the hard disk of a virtual machine』
とあるので、「仮想マシン」に利用されるとあるので、Finchの言うとことろの「WSL 2 instance」は、「仮想マシン」ないしは、「仮想マシン＋α」と言ったところでしょうかね。
「WSL 2（Windows Subsystem for Linux 2）」がブラックボックスなのでよく分からんけども...
「WSL 2（Windows Subsystem for Linux 2）」も「Light-weight VM」を謳っているとは言え、自分の環境を確認してみたところ、「.vhdx」ファイルのサイズだけで、
29.6 GB 12.2 GB 7.85 GB 2.34 GB 1.29 GB 2.92 GB 9.52 GB 878 MB
⇧ となり、合計で、
66.577421875 GB
⇧ となり、相当にディスク容量を消費している...
SSD（Solid State Drive）で10TBぐらいあれば、ディスク容量の逼迫に悩まなくて済むのかなぁ...
プロパティファイルでkeyが変わったりしなければ、Javaで再コンパイル不要という話
ソースコードの修正とか変更をしていなくて、プロパティファイルなどの値だけしか変更しなかった場合も、デプロイする際に毎回1つのjarやwarにビルドするような開発現場が多くて、意識したことが無かったのだけど、職場の方に教えてもらい、プロパティファイルの値だけしか変更していない場合、Javaファイルの再コンパイルは不要と伺ったので、備忘録として。
これまで、*.classファイルに対してのイメージが曖昧だったのですが、クラスローダーで読み込まれて処理が順々に実施されていくので、当然、プロパティファイルが処理されるのも、プロパティファイルを読み込む処理が記述されているところになると。
*.classファイル、または、クラスパスに追加されているファイル群は、「Java仮想マシン（JVM：Java Virtual Machine）」で読み込まれて処理されていくと思われるのだけど、
「Java仮想マシン（JVM：Java Virtual Machine）」のClass Loaderの階層が分からないのですが、
⇧ 何某かのClass Loaderで、*.classファイルが処理されますと。
一般的な「Java仮想マシン（JVM：Java Virtual Machine）」だと、
javaeesupportpatterns.blogspot.com
⇧ 上図のような階層になるんかな？
話を戻すと、*.classファイルにコンパイルされると、そこで全てがfixすると思っていたんだけど、fixするのは*.classファイルの処理の実行時なんですな。
なので、プロパティファイルのkeyとかが変わっていなくて、Javaのソースコード（拡張子が「.java」のファイル）とかも変更が無いのであれば、*.classファイルの処理が実行されるタイミングでプロパティファイルのkeyを元に、プロパティファイルのvalueを取得してくれますと。
ということは、*.classファイルにコンパイルした後に、プロパティファイルのvalueの値を変更したとしても、新たな*.classファイルを生成するための再コンパイル不要で変更したプロパティファイルのvalueの値を参照してくれると。
当然、プロパティファイルのkeyを変更したり追加したりしたら、Javaのソースコード側も変更することになると思うので、当然、再コンパイルが必要と。
何となく、
⇧ jarやwarで1つにまとめてデプロイするフローに慣れてて、個別にビルドするってシチュエーションになることがなく、Javaが最終的にどのように処理されるか深く考えて来なかったけど、Class Loaderとかも意識できるようになりたいものですな。
正直、MavenやGradleといったビルドツールが、内部でどんなことしてるか分からないから、差分コンパイルとかしてる可能性も無きにしも非ずなので何とも言えんけど...
何と言うか、ビルドやデプロイなんかの煩わしい部分は、極力、機械的に処理できるようにしたいところですね。
「継続的インティグレーション/継続的デリバリー（CI/CD：Continuous Integration／Continuous Delivery）」が、お手軽に構築できれば良いんですけどね...
それができたら苦労はしないと...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
