Previously, the underlying RandomAccessDataFile was not closed when
the JarFile that was using it was closed. This causes a problem on
Windows as the open file handle prevents the file from being deleted.
This commit updates JarFile to close the underlying
RandomAccessDataFile when it is closed and has a JarFileType of
DIRECT.
Previously, when accessing the manifest of a jar file that maps to a
nested directory (BOOT-INF/classes) a new JarFile was created from the
root jar file, the manifest was retrieved, and the new JarFile was
closed. This could lead to the underlying RandomAccessDataFile being
closed while it was still in use.
This commit improves JarFile to retrieve the manifest from the
existing outer JarFile, thereby avoiding the need to create and close
a new JarFile.
Unfortunately, PropertiesLauncher creates a number of scenarios where
a JarFile with a type of direct is closed while it’s still being used.
To accommodate this behaviour, RandomAccessDataFile has been updated
so that it can re-open the underlying RandomAccessFile if it is used
after it has been closed.
Closes gh-12296
Previously, working with a JarFile created a large amount of garbage
that was allocated on the thread local allocation buffer (TLAB).
The TLAB allocations made a significant contribution to GC pressure
and slowed down startup. This commit reduces the amount of garbage
by making a number of changes.
Reading from a RandomAccessDataFile has been reworked to avoid
creating new RandomAccessFile instances. A single RandomAccessFile
is now created for an entire jar file and it is used to read data from
anywhere in that jar file, including entries in nested jar files. To
ensure that reads remain thread-safe, a lock is taken on the
RandomAccessFile that is shared by all RandomAccessDataFile instances
that are provided access to (portions of) the same jar file.
Reading all of the bytes from a RandomAccessData has been reworked to
avoid the use of an InputStream that was created, used to read the
data, and then thrown away. In place of the InputStream-based
mechanism a method has been introduced that returns all of the
RandomAccessData as a byte[]. Building on this change, a method has
also been introduced to read a portion of a RandomAccessData as a
byte[]. This avoids the need to create a new RandomAccessData
subsection where the subsection was only used to read its entire
contents and then thrown away.
Decoding of an MS-DOS datetime has been reworked to use LocalDataTime
rather than GregorianCalendar. The former produces less garbage than
the latter.
Closes gh-12226
Phillip Webb
Andy Wilkinson
Stephane Nicoll
Johnny Lim
Madhura Bhave
igor-suhorukov
hanyong
andrey.onufreyko