Code cleanup from all sorts of (trivial) warnings [LUCENE-2285]

[asfimport]

I would like to do some code cleanup and remove all sorts of trivial warnings, like unnecessary casts, problems w/ javadocs, unused variables, redundant null checks, unnecessary semicolon etc. These are all very trivial and should not pose any problem.

I'll create another issue for getting rid of deprecated code usage, like LuceneTestCase and all sorts of deprecated constructors. That's also trivial because it only affects Lucene code, but it's a different type of change.

Another issue I'd like to create is about introducing more generics in the code, where it's missing today - not changing existing API. There are many places in the code like that.

So, with you permission, I'll start with the trivial ones first, and then move on to the others.

---

Migrated from LUCENE-2285 by Shai Erera (@shaie), resolved Feb 27 2010 Attachments: LUCENE-2285.patch (versions: 3), LUCENE-2285-remaining.patch, LUCENE-2285-remaining+generated.patch Linked issues:

• 3327

[asfimport]

Shai Erera (@shaie) (migrated from JIRA)

Uwe, we are indeed deadlocked :).

I thought that it's not recommended to compile code w/ 1.5 and run it w/ 1.4, even if the source level is 1.4. I remember a couple of issues with that, especially using Java 5.0 methods such as Class.getSimpleName() (I remember because I introduced these problems :)). So I'm not sure that I buy this argument ...

And I don't think that:

int int32 = (int) str.charAt(i+1);

introduces any sorts of safety, or makes the code clearer/more readable. It's just a redundant cast, which has no effect because the compiler would cast to int even if you didn't put the cast explicitly there. Same as doing double res = (double) intval * 1.0 ...

I guess we need a tie breaker :).

[asfimport]

Robert Muir (@rmuir) (migrated from JIRA)

hi Shai, i will give some comment on your example here.

it doesnt really matter to me either way: BUT i think the cast helps here somewhat (this is the part of the code confirming a valid surrogate pair). Because if i see int32 = something.charAt() I immediately think bug, as the right-hand-side is a 16 bit code unit. The cast makes me think the person writing the code is aware they are not the same data type.

[asfimport]

Shai Erera (@shaie) (migrated from JIRA)

Thanks Robert. I understand the reasoning behind what you say. I'd still prefer a comment, which IMO would really show someone has given thought to this. But I'm fine (or maybe just tired) either way as well ..

I just hope no one else will take my side now, because we'll be tied again ;).

[asfimport]

Robert Muir (@rmuir) (migrated from JIRA)

Shai, its no big deal to me either way, and I agree a comment would better explain what is happening in this part of UnicodeUtil versus a cast, so replacing the cast with a comment to me is fine.

[asfimport]

Shai Erera (@shaie) (migrated from JIRA)

Funny how the word 'trivial' appears in the subject :). I once heard that if you'll try to pass two decisions among a group of people, (1) would be a better name for a department and (2) would be spending 1B $ on a super complicated science project, you'll have better luck w/ the second :).

Let's leave the cast ... I'm afraid if I'll add the comment we'll argue about the wording ;).

[asfimport]

Uwe Schindler (@uschindler) (migrated from JIRA)

I thought that it's not recommended to compile code w/ 1.5 and run it w/ 1.4, even if the source level is 1.4. I remember a couple of issues with that, especially using Java 5.0 methods such as Class.getSimpleName() (I remember because I introduced these problems ). So I'm not sure that I buy this argument ...

This affects code merged into the 2.9 branch. The release artifacts of Lucene 2.9 are compiled with Java 1.5, as else some contribs would not compile (need 1.5). So we had to take care, that we dont use methods from 1.5. This is tested by the release manager by a compile using JDK 1.4 (core only). – I did this.

The problem is now that in my above example without the cast when calling Character.toUpperCase using an non-casted int, the rt.jar of javac leads the compiler to using the int version of the method, even if it is not available in 1.4. By using a explicit cast we are fine here. I tested this during my 2.9 release builds: I used the artifacts from the bin-zip and was able to run the tests using JDK 1.4. When I remove some of the int -> char casts, it breaks. Thats all. This is one reason why i prefer to be explicit about the invoked method. A commented out cast would not help, so I am -1 on just adding casts as comment.

So please tell me a @SuppressWarnings that I can add to make your IDE happy.

[asfimport]

Shai Erera (@shaie) (migrated from JIRA)

The @SuppressWarnings is "unused". But I don't want to add it, as it will ignore any such warnings in the file. What you write about 1.4/1.5 makes perfect sense to me. I don't mind staying w/ the warnings if the code had a comment "we must do this cast, to avoid a 1.4/1.5 compatibility issue". So please don't add SuppressWarnings. To me, once the community has decided a certain warning is justified, it's enough. I don't need Eclipse to be happy (I'll talk to it privately afterwards, explaining the situation :)).

Thanks for the example and explanation.

[asfimport]

Uwe Schindler (@uschindler) (migrated from JIRA)

Of course it would not be needed for Lucene 3.1. But we still merge a lot of bugfix code back, so the casts ensure that it can be done easily. This one warning in one of the contrib queryparsers (i reverted even not generated code), will be added later. I think the biggest change in this issue was removal of Version.LUCENE_CURRENT in tests.

There are still some places, where LUCENE_CURRENT is used in core code. I will close the linked issue now.