RFR: 8303755: Clean up around JavacElements.getAllMembers [v2]

Pavel Rappo prappo at openjdk.org
Tue Mar 7 16:41:14 UTC 2023


On Tue, 7 Mar 2023 15:44:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into 8303755
>>    
>>    # Conflicts:
>>    #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>>  - Improve CompoundIterator
>>    
>>    - it could be improved even further, but kept as is to retain its
>>      laziness
>>    - `remove` is deleted as it now is a default Iterator method
>>  - Improve Iterators.createFilterIterator
>>    
>>    Assert that the mechanics relies on iterator being filtered never
>>    to return null.
>>  - Fix typos and improve consistency
>>  - Avoid unnecessary recomputation
>>  - Fix typos and {@inheritDoc} that stands out
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 89:
> 
>> 87:                 while (input.hasNext()) {
>> 88:                     E sym = input.next();
>> 89:                     assert sym != null; // otherwise, false positive EOF
> 
> javac coding style is to use the `Assert` class, not `assert` statement

If you are considering an unconditional null check here, then you might want to consider a dedicated EOF flag instead. Alternatively, I can remove the `assert`, but leave the comment; for the next reader.

It's probably the case that iteration elements are never `null`. If they were `null`, we would either notice false positive EOF or see NPEs thrown from predicates.

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

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


More information about the compiler-dev mailing list