Linux deletes a file completely differently than the way Windows does. First, a brief explanation on how files are managed in the *unix native file systems.
The file is kept on the disk in the multilevel structure called
i-node. Each i-node has an unique number on the single filesystem. The i-node structure keeps different information about a file, like its size, data blocks allocated for the file etc., but for the sake of this answer the most important data element is a
link counter. The
directories are the files that keep records about the files. Each record has the i-node number it refers to, the file name length and the file name itself. This scheme allows one to have 'pointers', i.e. 'links' to the same file in different places with different names. The link counter of the i-node actually keeps the number of links that refer to this i-node.
What happens when some process opens the file? First the
open() function searches for the file record. Then it checks if the in-memory i-node structure for this i-node already exists. This may happen if some application already had this file opened. Otherwise, the system initializes a new in-memory i-node structure. Then the system increases the in-memory i-node structure open counter and returns to the application its file descriptor.
The Linux library call to delete a file is called
unlink. This function removes the file record from a directory and decrements the i-node's link counter. If the system found that an in-memory i-node structure exists and its open counter is not zero then this call returns the control to the application. Otherwise it checks if the link-counter became zero and if it does then the system frees all blocks allocated for the i-node and the i-node itself and returns to the application.
What happens that an application closes a file? The function
close() decrements the open counter and checks its value. If the value is non-zero the function returns to the application. Otherwise it checks if the i-node link counter is zero. If it is zero, it frees all blocks of the file and the i-node before returning to the application.
This mechanism allows you to "delete" a file while it is opened. At the same time the application that opened a file still has access to the data in the file. So, JRE, in your example, still keeps its version of file opened while there is another, updated version on the disk.
More over, this feature allows you to update the glibc(libc) - the core library of all applications - in your system without interrupting its normal operation.
20 years ago we did not know any other file system than FAT under DOS. This file system has a different structure and management principles. These principles do not allow you to delete a file when it is opened, so the DOS and lately Windows has to deny any delete requests on a file that is open. Probably NTFS would allow the same behavior as *nix file systems but Microsoft decided to maintain the habitual behavior of the file deletion.
This is the answer. Not short, but now you have the idea.
A good read on sources of
Win32 mess: https://web.archive.org/web/20190218083407/https://blogs.msdn.microsoft.com/oldnewthing/20040607-00/?p=38993
Credits to @Jon