[
https://issues.apache.org/jira/browse/LUCENE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470551#comment-17470551
]
Uwe Schindler commented on LUCENE-10364:
----------------------------------------
PR: https://github.com/apache/lucene/pull/590
> Prepare and update errorprone plugin for Java 17
> ------------------------------------------------
>
> Key: LUCENE-10364
> URL: https://issues.apache.org/jira/browse/LUCENE-10364
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
> Reporter: Uwe Schindler
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When working on LUCENE-10283 and also SOLR-15876, we figured out that
> errorprone is now also able to run with Java 17, if we update it and if it
> runs inside Gradle's JVM. This was caused by the add-opens we did for
> Spotless previously.
> There is only one case where it does not work: If you run spotless in a
> forked compiler, because the Gradle options are not applied then. The new
> Spotless plugin can handle this, but it won't work with our customized build
> for some reason. So I changed the if clause a bit, so it wont run errorprone
> if you use a JDK-18 preview build with RUNTIME_JAVA_HOME.
> When updating the rules it also found new bugs, some of them were real
> problems:
> - some tests were comparing Longs as Floats. The resason for this was when
> Suggesters changed to use Longs instead of Floats. In a similar way sometimes
> we assign a long to a float score. The first on was easy to fix by removing
> the epssilon from the assertEquals, the latter was mostly adding an explicit
> cast (to make it clear in our scorers)
> - There were also some concurrent modification exceptions possible, i fixed
> this in test by making a clone before modifying. For those using a TreeMap it
> was fine.
> - It was complaining about Character#getNumericValue(): This is a good hint,
> but in our case we were only using DECIMAL digits. For DecimalDigitFilter
> this is fine. Maybe [~rmuir] should have a look at the unicode rules
> processing in GenerateUTR30DataFiles. Please don't see this as "Robert does
> not know Unicode", I just want to verify that the SuppressWarnings is fine,
> because I did not understand the code there. The problem is that
> UCharacter.getNumericValue() returns values outside 0..9 for roman numbers
> like 50. So adding it to the character '0' (0x30) to generate ASCII digit is
> not a good idea. DecimalDigitFilter does not do this, but for
> GenerateUTR30DataFiles I am unsure. So this should be verified!
> - Some equals() methods were comparing primitives with Objects.equals(). This
> causes boxing and should be avoided (although Hotspot removes this after
> enough iterations)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
