[
https://issues.apache.org/jira/browse/LUCENE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-10364:
-----------------------------------
Description:
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)
was:
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!
> 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
>
> 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
