Paths.get vs Path.of

지금까지 내가 말할, 수 Paths.get및 Path.of에 하나 명 이상의 문자열을 돌려 정확히 같은 일을 할 것 같다 Path개체; https://docs.oracle.com/javase/8/docs/api/java/nio/file/Paths.html#get-java.lang.String-java.lang.String...- 및 https 설명서 : //docs.oracle.com/en/java/javase/13/docs/api/java.base/java/nio/file/Path.html#of(java.lang.String,java.lang.String ... ) 같은 문구를 사용하십시오. 그들은 실제로 동일합니까?

Path.of나중에 소개되었습니다. 추측 : 일관성있는 Foo.of스타일을 위해 도입되었습니다 . 이 경우 일관성 / 미적 측면에서 선호되는 것으로 간주됩니까?

실제로 Path.of나중에 소개되었습니다.

추측 : 일관성있는 Foo.of스타일을 위해 도입되었습니다 .

메일 링리스트 아카이브에서이 메소드를 한 번 호출했습니다Path.get .

주요 변경 사항은 java.nio.file의 경로 및 경로입니다.

이 패치는 Paths.get () 메소드를 Path.get ()의 정적 메소드에 복사하고 후자를 각각의 메소드를 호출하도록 수정합니다. 경로 사양은 경로 자체를 나타내지 않도록 약간 정리되어 있습니다 (예 : "(경로 참조)". @implSpec 어노테이션이 Path에 추가되어 메소드가 단순히 Path에서 해당 메소드를 호출 함을 나타냅니다.
...

Brian Goetz가Foo.of 다음 과 일치하도록 제안 했을 때 이것은 나중에 변경되었습니다 .

이와 별도로 Brian Goetz는 이러한 팩토리 메소드의 이름이 "of"인 경우 일관성이 높아질 것이라고 오프리스트에 제안했습니다.

이제 마지막 질문 : "이 경우 일관성 / 미적 측면에서 선호되는 것으로 간주됩니까?"
에서 초기 메일 브라이언 Burkhalter 그는 새로운 방법에 대한 모든 참조를 업데이트했다 Path:

java.base의 모든 소스 파일은 Paths.get ()을 Path.get ()으로 변경하고 경로 가져 오기를 제거하도록 수정되었습니다. ...

따라서 나는 그것이 Path.of실제로 바람직 하다고 결론 내릴 것 입니다 Paths.get.
실제로 Java 용 Javadoc Paths13을 보면이 참고 사항을 찾을 수 있습니다.

API 참고 : 이 클래스는 향후 릴리스에서 더 이상 사용되지 않을 수 있으므로이 클래스에 정의 된 메서드 대신 via 메서드
를 얻는 것이 좋습니다 .PathPath.ofget