RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v14]

[Brian Burkhalter]

On Tue, 26 Jul 2022 19:28:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
>> 
>>  - 8057113: Revert return type back to a nullable-String; update test
>>  - Merge
>>  - 8057113: Remove extensions() test method; add threthree new test cases
>>  - 8057113: Revert excision of wild cards from imports
>>  - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension()
>>  - Merge
>>  - 8057113: Change @since annotation to 20
>>  - Merge
>>  - 8057113: Remove superfluous new Object[] statements from test
>>  - 8057113: Fix getExtension() commcents; improve hasExtension() implementation
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/6f0aa05d...23ca3f10
>
> src/java.base/share/classes/java/nio/file/Path.java line 102:
> 
>> 100:  * Otherwise stated, the internal representation might not be recoverable
>> 101:  * from the derived path string. This applies to the {@code Path} as a whole
>> 102:  * as well as to its components.
> 
> This comment doesn't seem specific to the enhancement proposed.
> And its a bit vague, if/when included it might benefit from an example or mentioning the character set encoding of file names, if that's the context.

I am wondering now whether this note would just add unnecessary confusion.

-------------

PR: https://git.openjdk.org/jdk/pull/8066