Github user tejasapatil commented on a diff in the pull request:

    https://github.com/apache/spark/pull/13042#discussion_r62808294
  
    --- Diff: 
common/network-common/src/main/java/org/apache/spark/network/util/JavaUtils.java
 ---
    @@ -79,14 +80,32 @@ public static String bytesToString(ByteBuffer b) {
         return Unpooled.wrappedBuffer(b).toString(StandardCharsets.UTF_8);
       }
     
    -  /*
    +  /**
        * Delete a file or directory and its contents recursively.
        * Don't follow directories if they are symlinks.
    -   * Throws an exception if deletion is unsuccessful.
    +   *
    +   * @param file Input file / dir to be deleted
    +   * @throws IOException if deletion is unsuccessful
        */
       public static void deleteRecursively(File file) throws IOException {
         if (file == null) { return; }
     
    +    // On Unix systems, use operating system command to run faster
    +    // If that does not work out, fallback to the Java IO way
    +    if (SystemUtils.IS_OS_UNIX) {
    --- End diff --
    
    It lead to cyclic dependency between spark-core and spark-network-common.
    I could move those methods related to finding OS from 
org.apache.spark.util.Utils (existing `isWindows`, `isMac` and new one 
`isUnix`) to a util class in `spark-network-common` (could be named as 
`OSIdentificationUtils`). That would need changing all instances in the 
codebase where those are being used to refer to the `OSIdentificationUtils` and 
also depend on `spark-network-common`. There are ~40 such places in the 
codebase. 
    As far as code organization is concerned, it would seem weird because 
`spark-core` seems to be a better place to host such utilities. Also, there are 
other methods related to OS stuff in spark-core's classes and one might as well 
move those to `OSIdentificationUtils` to make the logical grouping better but 
it means more refac and moving things around which will make this diff 
un-necessarily bigger than it is supposed to be.
    
    I have left this part as it is so get your comments.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org

Reply via email to