SOLR-16903: Migrate off java.io.File to java.nio.file.Path from core files #2924

mlbiscoc · 2024-12-23T19:53:34Z

https://issues.apache.org/jira/browse/SOLR-16903

Description

Still in draft. Tests seem to pass locally but a lot can still be refactored better around Path.

This should remove all imports of java.io.File inside main core files. This excludes test files as there are too many changes to include into this PR and will make that in a separate PR.

Solution

Found where import java.io.File; was being used and migrated logic to java.nio.file.Path as best as possible.

Tests

Tests pass locally

Checklist

Please review the following and check all that apply:

I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
I have created a Jira issue and added the issue ID to my pull request title.
I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
I have developed this patch against the main branch.
I have run ./gradlew check.
I have added tests for my changes.
I have added documentation for the Reference Guide

epugh · 2024-12-23T19:58:59Z

solr/core/src/java/org/apache/solr/core/CoreDescriptor.java

@@ -64,7 +63,7 @@ public class CoreDescriptor {
  public static final String SOLR_CORE_PROP_PREFIX = "solr.core.";

  public static final String DEFAULT_EXTERNAL_PROPERTIES_FILE =
-      "conf" + File.separator + "solrcore.properties";
+      Path.of("conf/solrcore.properties").toString();


is there any chance of different file seperators? I wasn't sure if that was one reason for using the File.separator, like on windows? Or is that one of the benefits of Path?

I was worried about this so started reading Path.of() documentation and oracle documentation. Filesystems.getDefault().getPath(String) which should return the OS path and developers can use the standard / regardless. It's also a benefit of Path for Solr to no longer have to do all these File.separator chars or OS checking...

I haven't actually tested this on something like a windows operating system to confirm though...

This is a really great benefit of the migration!

mlbiscoc

I think this is ready for review

mlbiscoc · 2024-12-24T18:24:44Z

solr/core/src/java/org/apache/solr/core/SolrCore.java

+    try {
+      totalSpace = Files.getFileStore(dataDirFile).getTotalSpace();
+      useableSpace = Files.getFileStore(dataDirFile).getUsableSpace();
+    } catch (Exception e) {
+      // TODO Metrics used to default to 0 with java.io.File even if directory didn't exist
+      // Should throw an exception and initialize data directory before metrics
+      totalSpace = 0L;
+      useableSpace = 0L;
+    }


This here was questionable. Upon a Solr core being initialized, metrics was trying to calculate and initialize a gauge for the data/ directories before the directory was ever created. This always failed with File but it defaults to 0. Path on the other hand throws an Exception. This didn't seem right but also moving where the initializeMetrics is called in a bunch of different places had tests failing and I wasn't sure why so I kept it as TODO.

But also if this is initializing metrics for a SolrCore registry upon creation, shouldn't it always be 0 as the data directory was most likely just created?

Do not pre-compute this stuff; it should only be calculated/fetched when the metric is fetched. Maybe could clarify that the TODO is to move metrics initialization to after data directory initialization, thus avoiding this exception (hopefully) but that may not be entirely possible.

Just initialized the gauges to 0 and added the TODO. Could be worth moving metric initialization to after the directory is created if we want that data point of the disk usage.

epugh

Really great progress here! I've been poking a bit around the FIleStore stuff, so great to see some of the improvements in that area as well. I put in a bunch of feedback, I hope it's useful. Ping me when you are ready for final review!

epugh · 2025-01-10T12:21:13Z

solr/api/src/java/org/apache/solr/client/api/endpoint/NodeFileStoreApis.java

@@ -63,5 +64,6 @@ SolrJerseyResponse getFile(
          String getFrom,
      @Parameter(description = "Indicates that (only) file metadata should be fetched")
          @QueryParam("meta")
-          Boolean meta);
+          Boolean meta)
+      throws IOException;


Just wanted to confirm this throw was needed? Maybe because of something else furthur down?

Actually no it isn't needed. It was due to my changes on List<FileDetails> list() method under DistribFileStore so I threw a SolrException instead which seems correct.

solr/core/src/java/org/apache/solr/core/CachingDirectoryFactory.java

epugh · 2025-01-10T12:22:15Z

solr/core/src/java/org/apache/solr/core/CoreDescriptor.java

@@ -64,7 +63,7 @@ public class CoreDescriptor {
  public static final String SOLR_CORE_PROP_PREFIX = "solr.core.";

  public static final String DEFAULT_EXTERNAL_PROPERTIES_FILE =
-      "conf" + File.separator + "solrcore.properties";
+      Path.of("conf/solrcore.properties").toString();


This is a really great benefit of the migration!

solr/core/src/java/org/apache/solr/core/DirectoryFactory.java

epugh · 2025-01-10T12:25:55Z

solr/core/src/java/org/apache/solr/core/SolrPaths.java

-    return (path != null && (!(path.endsWith("/") || path.endsWith("\\"))))
-        ? path + File.separator
-        : path;
+    return (path != null && (!(path.endsWith("/") || path.endsWith("\\")))) ? path + "/" : path;


wow that's gnarly.. Is there no existing normalize() function in any of our jars that would do this for us? I guess fixing that is orthongonal to this effort....

The code was fine as it was but perhaps got your attention because File is referenced. Since we only need to know the separator, try FileSystems.getDefault().getSeparator()

I was thinking, we shouldn't need to call FileSystems.getDefault().getSeparator() assuming callers of this eventually take this string and put it into a Path, but I don't think that is necessarily true. Seeing something like this line it's comparing strings 1:1 but my slash would probably break it on a different OS that uses a different delimiter. Directory strings should probably be checked through Path.equal(), not strings directly. I just put it back with FileSystems.getDefault().getSeparator()

epugh · 2025-01-10T12:43:13Z

solr/core/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java

+              if (Files.isDirectory(f)) {
+                fileInfo.add("directory", true);
+              } else {
+                // TODO? content type


lets. get rid of this todo.. this code hasn't changed in years, and if someone wants it they can add it later! we shouldn't litter our code with todos that are mostly ideas.. a todo really implies hey, someone SHOULD go do this very soon!

Got it. Removed it. Mostly trying to just untouch code unless needed so was just porting over anything including TODO's. Let me know if there is more that should be removed.

An aside: The question mark there definitely doesn't convey the urgency that Eric suggests. There just isn't a universal interpretation of TODOs across projects (sadly).

epugh · 2025-01-10T12:44:27Z

solr/core/src/java/org/apache/solr/spelling/AbstractLuceneSpellChecker.java

@@ -84,7 +83,7 @@ public String init(NamedList<?> config, SolrCore core) {
    // If indexDir is relative then create index inside core.getDataDir()
    if (indexDir != null) {
      if (!Path.of(indexDir).isAbsolute()) {
-        indexDir = core.getDataDir() + File.separator + indexDir;
+        indexDir = Path.of(core.getDataDir(), indexDir).toString();


can indexDir be a path?

Yes! Changed it as Path.

epugh · 2025-01-10T12:45:40Z

solr/core/src/java/org/apache/solr/spelling/suggest/fst/AnalyzingInfixLookupFactory.java

@@ -89,7 +88,7 @@ public Lookup create(NamedList<?> params, SolrCore core) {
    String indexPath =
        params.get(INDEX_PATH) != null ? params.get(INDEX_PATH).toString() : DEFAULT_INDEX_PATH;
    if (!Path.of(indexPath).isAbsolute()) {
-      indexPath = core.getDataDir() + File.separator + indexPath;
+      indexPath = Path.of(core.getDataDir(), indexPath).toString();


can indexPath be a Path? Also, is there an opportunity to align variable naming between indexPath and the use of indexDir in in AbstractLuceneSpellChecker?

Yes good catch. Much better than calling Path.of everywhere.

epugh · 2025-01-10T12:48:04Z

solr/core/src/java/org/apache/solr/util/VersionedFile.java

          }
        }

-        is = new FileInputStream(f);
+        is = new FileInputStream(f.toString());


Files.newInputStream() instead?

Added TODO. Might either make another story or just PR to move them all. I see about 34 instances of this used including inside of tests (which is a whole different monster 😵‍💫) but at least after this PR, there should be no uses of File in Solr itself.

I sympathize with wanting to keep the scope of this PR in-check. But here, we are talking about how to go from Path to an InputStream _for the very lines you are editing) (since lines like this previously didn't have a Path but now do). So I think it's in scope here. We're not talking about a full search of every case where we could use Files.newInputStream but didn't yet. It's just for the lines you are already editing. No new lines of code; no complexity.

Thats fair. I had a previous comment where I said the change wasn't 1:1 but here it is. Wasn't sure what I ran into then but for the PR where I changed to Path and there is a new FileInputStream I changed the new FileInputStream to Files.newInputStream(). We can tackle the rest in another.

epugh · 2025-01-10T12:48:19Z

solr/core/src/java/org/apache/solr/util/VersionedFile.java

      } catch (Exception e) {
        // swallow exception for now
      }
    }

    // allow exception to be thrown from the final try.
    if (is == null) {
-      is = new FileInputStream(f);
+      is = new FileInputStream(f.toString());


Files.newInputStream?

See comment above

dsmiley

I got half way through review today.

dsmiley · 2025-01-10T14:13:12Z

solr/core/src/java/org/apache/solr/cloud/ZkSolrResourceLoader.java

@@ -121,7 +120,7 @@ public InputStream openResource(String resource) throws IOException {

    try {
      // delegate to the class loader (looking into $INSTANCE_DIR/lib jars)
-      is = classLoader.getResourceAsStream(resource.replace(File.separatorChar, '/'));
+      is = classLoader.getResourceAsStream(Path.of(resource).toString());


Assuming that actually works, I think a little comment is needed like "normalize path separator"

But I think it doesn't work; not on Windows. I thought I commented elsewhere in that lengthy review that all Path.of(resource).toString() that you are adding is probably flawed

solr/core/src/java/org/apache/solr/core/CoreDescriptor.java

dsmiley · 2025-01-10T14:16:40Z

solr/core/src/java/org/apache/solr/core/CoreDescriptor.java

-          CORE_DATADIR, "data" + File.separator,
+          CORE_DATADIR, Path.of("data/").toString(),


The trailing slash should ideally not be necessary. I'd prefer to just drop it and we deal with the consequences. If needed, the previous code was clearer IMO so I'd rather see something similarly clear.

solr/core/src/java/org/apache/solr/core/DirectoryFactory.java

dsmiley · 2025-01-10T14:54:37Z

solr/core/src/java/org/apache/solr/core/SolrCore.java

+      // initialize core metrics
+      initializeMetrics(solrMetricsContext, null);


why did you move this?

This was a mistake. I forgot to revert. This has to do with metrics being pre-computed with File disk usage and was trying to get the data directory initialized before the metrics registered. I eventually stopped and forgot to move it back

dsmiley · 2025-01-10T16:05:20Z

solr/core/src/java/org/apache/solr/filestore/DistribFileStore.java

    if (isMetaDataFile(simpleName)) {
-      try (InputStream is = new FileInputStream(file)) {
+      try (InputStream is = new FileInputStream(file.toString())) {


Yes Eric is right but may want to do that universally in another PR to avoid scope creep.

solr/core/src/java/org/apache/solr/handler/IndexFetcher.java

dsmiley · 2025-01-10T17:15:44Z

solr/core/src/java/org/apache/solr/handler/admin/CoreAdminOperation.java

-            info.add("dataDir", normalizePath(core.getDataDir()));
+            info.add("dataDir", Path.of(core.getDataDir()).toString());


I'm suspicious of this technique. I'd prefer we have a utility method to make certain normalizations when they are needed.

I completely removed that normalizePath because I thought Path would do this for us already, so the utility wasn't needed. Happy to bring it back though then I guess keep the code as it was?

I like normalizePath(...) because it communicates an intention that your one-liner certainly doesn't. I guess you could edit the method to have this line of code that you think is equivalent, + comments indicating that it (not so obviously) changes path separators. I wish I had a Windows machine handy to tinker with Path to verify this.

can you bring the method back please? In a file utility place, and documenting what sort of normalization it does (otherwise is ambiguous). Like; normalizeToOsPathSeparator(...)

Found a place in FileUtils and brought it back. Also just switched to FileSystems.getDefault().getSeparator() and brought all the logic to be careful of regressions since it seems neither of us can confirm fully on a windows machine.

solr/core/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java

dsmiley · 2025-01-10T17:21:19Z

solr/core/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java

      NamedList<SimpleOrderedMap<Object>> files = new SimpleOrderedMap<>();
-      for (File f : adminFile.listFiles()) {
-        String path = f.getAbsolutePath().substring(basePath);
-        path = path.replace('\\', '/'); // normalize slashes


don't lose this. I feel like we need a toForwardSlashPathString(Path) utility method.

For this method itself, I don't think it should need it, but you just want the method itself in Solr for other use-cases?
I created a static toForwardSlashPathString method in this class. Maybe it belongs or we could put it in FileUtils.java?

What are scenarios are does Solr need this method?

Okay, I agree that the ShowFileRequestHandler ought not to be receiving backslashes.

mlbiscoc

Went through all the comments and changed them as best I could. Had some questions on a few which I replied back, but overall wasn't too bad. Tests pass locally again but ready for another round of review.

mlbiscoc · 2025-01-16T13:24:49Z

solr/api/src/java/org/apache/solr/client/api/endpoint/NodeFileStoreApis.java

@@ -63,5 +64,6 @@ SolrJerseyResponse getFile(
          String getFrom,
      @Parameter(description = "Indicates that (only) file metadata should be fetched")
          @QueryParam("meta")
-          Boolean meta);
+          Boolean meta)
+      throws IOException;


Actually no it isn't needed. It was due to my changes on List<FileDetails> list() method under DistribFileStore so I threw a SolrException instead which seems correct.

mlbiscoc · 2025-01-16T13:28:24Z

solr/core/src/java/org/apache/solr/cloud/ZkSolrResourceLoader.java

@@ -121,7 +120,7 @@ public InputStream openResource(String resource) throws IOException {

    try {
      // delegate to the class loader (looking into $INSTANCE_DIR/lib jars)
-      is = classLoader.getResourceAsStream(resource.replace(File.separatorChar, '/'));
+      is = classLoader.getResourceAsStream(Path.of(resource).toString());


solr/core/src/java/org/apache/solr/core/CoreDescriptor.java

mlbiscoc · 2025-01-16T13:31:40Z

solr/core/src/java/org/apache/solr/core/CoreDescriptor.java

-          CORE_DATADIR, "data" + File.separator,
+          CORE_DATADIR, Path.of("data/").toString(),


mlbiscoc · 2025-01-16T13:35:50Z

solr/core/src/java/org/apache/solr/core/SolrCore.java

+      // initialize core metrics
+      initializeMetrics(solrMetricsContext, null);


This was a mistake. I forgot to revert. This has to do with metrics being pre-computed with File disk usage and was trying to get the data directory initialized before the metrics registered. I eventually stopped and forgot to move it back

mlbiscoc · 2025-01-16T15:51:39Z

solr/core/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java

+              if (Files.isDirectory(f)) {
+                fileInfo.add("directory", true);
+              } else {
+                // TODO? content type


Got it. Removed it. Mostly trying to just untouch code unless needed so was just porting over anything including TODO's. Let me know if there is more that should be removed.

mlbiscoc · 2025-01-16T16:07:41Z

solr/core/src/java/org/apache/solr/spelling/AbstractLuceneSpellChecker.java

@@ -84,7 +83,7 @@ public String init(NamedList<?> config, SolrCore core) {
    // If indexDir is relative then create index inside core.getDataDir()
    if (indexDir != null) {
      if (!Path.of(indexDir).isAbsolute()) {
-        indexDir = core.getDataDir() + File.separator + indexDir;
+        indexDir = Path.of(core.getDataDir(), indexDir).toString();


Yes! Changed it as Path.

mlbiscoc · 2025-01-16T16:11:23Z

solr/core/src/java/org/apache/solr/spelling/suggest/fst/AnalyzingInfixLookupFactory.java

@@ -89,7 +88,7 @@ public Lookup create(NamedList<?> params, SolrCore core) {
    String indexPath =
        params.get(INDEX_PATH) != null ? params.get(INDEX_PATH).toString() : DEFAULT_INDEX_PATH;
    if (!Path.of(indexPath).isAbsolute()) {
-      indexPath = core.getDataDir() + File.separator + indexPath;
+      indexPath = Path.of(core.getDataDir(), indexPath).toString();


Yes good catch. Much better than calling Path.of everywhere.

mlbiscoc · 2025-01-16T16:13:35Z

solr/core/src/java/org/apache/solr/util/VersionedFile.java

          }
        }

-        is = new FileInputStream(f);
+        is = new FileInputStream(f.toString());


Added TODO. Might either make another story or just PR to move them all. I see about 34 instances of this used including inside of tests (which is a whole different monster 😵‍💫) but at least after this PR, there should be no uses of File in Solr itself.

mlbiscoc · 2025-01-16T16:13:46Z

solr/core/src/java/org/apache/solr/util/VersionedFile.java

      } catch (Exception e) {
        // swallow exception for now
      }
    }

    // allow exception to be thrown from the final try.
    if (is == null) {
-      is = new FileInputStream(f);
+      is = new FileInputStream(f.toString());


See comment above

epugh

LGTM pending the tests... I just kicked precommit and solr tests off on github.

I do hope you have the energy to do this on tests too!

dsmiley · 2025-01-16T20:59:44Z

As a general comment, I want to ensure we're careful converting some Strings to Paths. It's only safe if we're certain that it's exactly a file system path. Paths resolved inside a DirectoryFactory/Directory are not necessarily literally on the file system (it's an abstraction to data that could be in HDFS or S3 or...). It'd be nice to use a Path for this anyway but shouldn't be without a custom FileSystem impl (very out of scope here). Same for ZK paths. Also some of our HTTP APIs are file-system inspired (ConfigSet, FileStore, ...) with paths in which '/' is the separator no matter what the underlying file system is Solr is running on (after all; don't want the client to care about the OS Solr is running on). These are not directly convertible to a Path either, or at least take some work to do separator translation if the end location is on-disk (file store & file system ConfigSetService).

solr/core/src/test/org/apache/solr/core/ResourceLoaderTest.java

solr/core/src/java/org/apache/solr/util/VersionedFile.java

dsmiley · 2025-01-19T03:16:39Z

solr/core/src/java/org/apache/solr/util/VersionedFile.java

+                SolrException.ErrorCode.SERVER_ERROR, "Unable to list files in " + dir, e);
+          }
+
+          f = Path.of(dir.toString(), fileList.getLast().getFileName().toString());


Don't use Path.of when you already have Path instances to work with. Path.of is for when you have Strings (not Paths).
I think this line of code should simply be dir.resolve(fileList.getLast())

solr/core/src/java/org/apache/solr/util/VersionedFile.java

dsmiley · 2025-01-19T03:24:39Z

solr/core/src/java/org/apache/solr/util/VersionedFile.java

          }
        }

-        is = new FileInputStream(f);
+        is = new FileInputStream(f.toString());


I sympathize with wanting to keep the scope of this PR in-check. But here, we are talking about how to go from Path to an InputStream _for the very lines you are editing) (since lines like this previously didn't have a Path but now do). So I think it's in scope here. We're not talking about a full search of every case where we could use Files.newInputStream but didn't yet. It's just for the lines you are already editing. No new lines of code; no complexity.

solr/core/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java

solr/core/src/java/org/apache/solr/handler/IndexFetcher.java

solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java

solr/core/src/java/org/apache/solr/filestore/DistribFileStore.java

dsmiley

I reviewed the whole thing again.

solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java

solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java

solr/core/src/java/org/apache/solr/core/DirectoryFactory.java

dsmiley · 2025-01-31T05:45:52Z

solr/core/src/java/org/apache/solr/core/SolrCore.java

-        () -> dataDirFile.getTotalSpace(), true, "totalSpace", Category.CORE.toString(), "fs");
-    parentContext.gauge(
-        () -> dataDirFile.getUsableSpace(), true, "usableSpace", Category.CORE.toString(), "fs");
+    Path dataDirFile = Paths.get(dataDir);


really minor but I think dataDirPath is a better name

solr/core/src/java/org/apache/solr/core/SolrCore.java

dsmiley · 2025-01-31T05:53:48Z

solr/core/src/java/org/apache/solr/core/SolrPaths.java

@@ -94,7 +94,7 @@ public static void assertNoPathTraversal(Path pathToAssert) {

  /** Asserts that a path is not a Windows UNC path */
  public static void assertNotUnc(Path pathToAssert) {
-    if (OS.isFamilyWindows() && pathToAssert.toString().startsWith("\\\\")) {
+    if (OS.isFamilyWindows() || pathToAssert.toString().startsWith("\\\\")) {


but OR means that this would consistently fail on Windows even if the path isn't UNC

solr/core/src/java/org/apache/solr/filestore/DistribFileStore.java

dsmiley · 2025-01-31T06:07:16Z

solr/core/src/java/org/apache/solr/handler/admin/CoreAdminOperation.java

-            info.add("dataDir", normalizePath(core.getDataDir()));
+            info.add("dataDir", Path.of(core.getDataDir()).toString());


can you bring the method back please? In a file utility place, and documenting what sort of normalization it does (otherwise is ambiguous). Like; normalizeToOsPathSeparator(...)

dsmiley · 2025-01-31T06:12:20Z

solr/core/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java

      NamedList<SimpleOrderedMap<Object>> files = new SimpleOrderedMap<>();
-      for (File f : adminFile.listFiles()) {
-        String path = f.getAbsolutePath().substring(basePath);
-        path = path.replace('\\', '/'); // normalize slashes


Okay, I agree that the ShowFileRequestHandler ought not to be receiving backslashes.

epugh · 2025-01-31T13:51:26Z

Thank you @dsmiley for digging through things. Your comments and eyes is probably saving us a lot of test failures down the road ;-).

dsmiley

Great! You can update CHANGES.txt for the existing SOLR-16903 to combine it. I think as other PRs happen, it'll ultimately be a broad File -> Path with a list of contributors.

solr/core/src/java/org/apache/solr/core/DirectoryFactory.java

mlbiscoc added 5 commits December 22, 2024 01:24

Inital core File to Path commit

6cc27d7

Move initialize metrics until after data dir was created

bc2db00

Compile failure

4c01109

Fix to bad conversions

f17b809

Sort list in getLatestFile

36d0b92

github-actions bot added tests cat:search cat:cloud cat:api cat:schema cat:packagemanager labels Dec 23, 2024

epugh reviewed Dec 23, 2024

View reviewed changes

Refactor

374a4a1

mlbiscoc marked this pull request as ready for review December 24, 2024 17:48

mlbiscoc commented Dec 24, 2024

View reviewed changes

epugh requested changes Jan 10, 2025

View reviewed changes

dsmiley reviewed Jan 10, 2025

View reviewed changes

First round addressing PR comments

63fb99d

github-actions bot removed the cat:api label Jan 16, 2025

mlbiscoc commented Jan 16, 2025

View reviewed changes

epugh approved these changes Jan 16, 2025

View reviewed changes

dsmiley reviewed Jan 19, 2025

View reviewed changes

Second round of PR comments

fb4daf3

dsmiley mentioned this pull request Jan 30, 2025

SOLR-XXXXX: Support different filesystem implementations with EmbeddedSolrServer #3146

Draft

7 tasks

dsmiley reviewed Jan 31, 2025

View reviewed changes

Small refactoring and fix with metrics

5f8abae

dsmiley approved these changes Jan 31, 2025

View reviewed changes

solr/core/src/java/org/apache/solr/core/DirectoryFactory.java Show resolved Hide resolved

Update CHANGES.txt

679fb29

dsmiley merged commit b32b675 into apache:main Feb 1, 2025
2 of 3 checks passed

		CORE_DATADIR, "data" + File.separator,
		CORE_DATADIR, Path.of("data/").toString(),

		// initialize core metrics
		initializeMetrics(solrMetricsContext, null);

		info.add("dataDir", normalizePath(core.getDataDir()));
		info.add("dataDir", Path.of(core.getDataDir()).toString());

SOLR-16903: Migrate off java.io.File to java.nio.file.Path from core files #2924

SOLR-16903: Migrate off java.io.File to java.nio.file.Path from core files #2924

Conversation

mlbiscoc commented Dec 23, 2024

Description

Solution

Tests

Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mlbiscoc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

epugh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dsmiley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mlbiscoc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

epugh left a comment

Choose a reason for hiding this comment

dsmiley commented Jan 16, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dsmiley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

epugh commented Jan 31, 2025

dsmiley left a comment

Choose a reason for hiding this comment