Historically, CDS archives are created as read-only files:

$ java -Xshare:dump -XX:SharedArchiveFile=foo.jsa
$ ls -l foo.jsa
-r--r--r-- 1 iklam iklam 15245312 May 8 22:37 foo.jsa

When AOT cache was introduced in JEP 483, the implementation was derived from CDS. As a result, AOT caches are also created as read-only files:

$ java -XX:AOTMode=record -XX:AOTConfiguration=hw.aotconf -cp HelloWorld.jar HelloWorld
Hello World
AOTConfiguration recorded: hw.aotconf

$ java -XX:AOTMode=create -XX:AOTConfiguration=hw.aotconf -XX:AOTCache=hw.aot -cp HelloWorld.jar
Reading AOTConfiguration hw.aotconf and writing AOTCache hw.aot
AOTCache creation is complete: hw.aot 9887744 bytes

$ ls -l hw.aot
-r--r--r-- 1 iklam iklam 9887744 May 8 22:35 hw.aot

This behavior is odd and makes it difficult to delete the files (you need to do "chmod u+w hw.aot" first).

When CDS was developed over 20 years, the original authors might have thought that since the CDS archive contains "executable" code, making the file read-only might have some security benefit.

However, all other JDK tools create files, including executable binaries, in read/write mode, so there's no reason why AOT caches/CDS archives should be any different.

$ javac HelloWorld.java
$ ls -l HelloWorld.class
-rw-r--r-- 1 iklam iklam 425 May 8 22:41 HelloWorld.class

$ jar cf HelloWorld.jar HelloWorld.class
$ ls -l HelloWorld.jar
-rw-rw-r-- 1 iklam iklam 724 May 8 22:41 HelloWorld.jar

$ jlink --add-modules java.base --output myjdk
$ ls -l myjdk/bin/java myjdk/lib/libjava.so
-rwxrwxr-x 1 iklam iklam 12376 May 8 22:32 myjdk/bin/java
-rw-rw-r-- 1 iklam iklam 171104 May 8 22:32 myjdk/lib/libjava.so