[jira] [Updated] (KAFKA-13928) Improve File I/O by using Java NIO.2

["Divij Vaidya (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KAFKA-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divij Vaidya updated KAFKA-13928:
---------------------------------
    Description: 
Java NIO.2 APIs we launched in JDK 7: [https://blogs.oracle.com/javamagazine/post/path-files-input-output]. Currently multiple places of Kafka code base use File handling provided by old Java IO which can be replaced with newer (& better) NIO.2 APIs.

The disadvantages of using the legacy File.io Java methods are described by the following blog: [https://docs.oracle.com/javase/tutorial/essential/io/legacy.html.|https://docs.oracle.com/javase/tutorial/essential/io/legacy.html] To summarize the disadvanatges from this article:
{quote}Prior to the Java SE 7 release, the {{java.io.File}} class was the mechanism used for file I/O, but it had several drawbacks.
 * Many methods didn't throw exceptions when they failed, so it was impossible to obtain a useful error message. For example, if a file deletion failed, the program would receive a "delete fail" but wouldn't know if it was because the file didn't exist, the user didn't have permissions, or there was some other problem.
 * The {{rename}} method didn't work consistently across platforms.
 * There was no real support for symbolic links.
 * More support for metadata was desired, such as file permissions, file owner, and other security attributes.
 * Accessing file metadata was inefficient.
 * Many of the {{File}} methods didn't scale. Requesting a large directory listing over a server could result in a hang. Large directories could also cause memory resource problems, resulting in a denial of service.
 * It was not possible to write reliable code that could recursively walk a file tree and respond appropriately if there were circular symbolic links.{quote}
This Jira will consist of multiple smaller changes where we would replace one Java method per change from the Kafka code base.

  was:
Java NIO.2 APIs we launched in JDK 7: [https://blogs.oracle.com/javamagazine/post/path-files-input-output] 

Currently multiple places of Kafka code base use File handling provided by old Java IO which can be replaced with newer (& better) NIO.2 APIs.


> Improve File I/O by using Java NIO.2
> ------------------------------------
>
>                 Key: KAFKA-13928
>                 URL: https://issues.apache.org/jira/browse/KAFKA-13928
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Divij Vaidya
>            Priority: Minor
>
> Java NIO.2 APIs we launched in JDK 7: [https://blogs.oracle.com/javamagazine/post/path-files-input-output]. Currently multiple places of Kafka code base use File handling provided by old Java IO which can be replaced with newer (& better) NIO.2 APIs.
> The disadvantages of using the legacy File.io Java methods are described by the following blog: [https://docs.oracle.com/javase/tutorial/essential/io/legacy.html.|https://docs.oracle.com/javase/tutorial/essential/io/legacy.html] To summarize the disadvanatges from this article:
> {quote}Prior to the Java SE 7 release, the {{java.io.File}} class was the mechanism used for file I/O, but it had several drawbacks.
>  * Many methods didn't throw exceptions when they failed, so it was impossible to obtain a useful error message. For example, if a file deletion failed, the program would receive a "delete fail" but wouldn't know if it was because the file didn't exist, the user didn't have permissions, or there was some other problem.
>  * The {{rename}} method didn't work consistently across platforms.
>  * There was no real support for symbolic links.
>  * More support for metadata was desired, such as file permissions, file owner, and other security attributes.
>  * Accessing file metadata was inefficient.
>  * Many of the {{File}} methods didn't scale. Requesting a large directory listing over a server could result in a hang. Large directories could also cause memory resource problems, resulting in a denial of service.
>  * It was not possible to write reliable code that could recursively walk a file tree and respond appropriately if there were circular symbolic links.{quote}
> This Jira will consist of multiple smaller changes where we would replace one Java method per change from the Kafka code base.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)