RFR: 8345286: Remove use of SecurityManager API from misc areas [v8]

Jaikiran Pai jpai at openjdk.org
Tue Dec 3 06:17:41 UTC 2024


On Mon, 2 Dec 2024 17:47:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - merge latest from master branch
>>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>>  - remove unused import
>>  - replace remaining Paths.get() with Path.of() in the updated files
>>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>>  - remove unnecessary space
>>  - Path.of() instead of Paths.get()
>>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/30b8bbe2...9baa279b
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 68:
> 
>> 66:         try (Stream<String> lines = Files.lines(filePath)) {
>> 67:             Optional<String> firstLine = lines.findFirst();
>> 68:             return firstLine.orElse(null);
> 
> you could probably just:
> 
> 
>             return lines.findFirst().orElse(null);
> 
> 
> unless the local variable is needed or type inference?

Hello Daniel, no syntactical reason behind this. Severin proposed this style in his review and I noticed that this area of the code has been using this style of local variable assigment and immediate return in one or two other places, so I decided to stick with it. I don't have a strong preference but am willing to update it if you or others think we should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1867112305


More information about the serviceability-dev mailing list