lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings
Date Sat, 27 Feb 2010 10:44:05 GMT


Uwe Schindler commented on LUCENE-2285:

bq. When a method declares it returns an int, there no reason to cast a char to an int. The
compiler will do it for you. 

I aggree with that, those casts were left in the patch, no problem at all. For me it is a
problem esp. in some file handling methods that use longs, but sometimes also use ints (e.g.
when reading a block of data). One example: MMapDirectory had a lot of problems with integer
overflows in the past. The problems occurred because some formulas were simply not using casts
at all, so the compiler did what was in the specs, but which is not always easy to see. So
if you explicitely add a cast to (long) in your formula you are fine and really nobody gets
hurt. An everybody understands whats happening. The Sun Code formatting guidelines explicitely
says that, that you should use integer casts, if it is for more clarity. And if you dont like
the warnings, then switch them off for only lucene in eclipse (you dont need to do that globally).

I dont agree with using char inside a method when calling other functions without casting
to int. E.g. we have some backwards compatibility layer for Unicode 4 that uses Character.toUpperCase(int)
and Character.toUpperCase(char) in parallel. And these two methods differ, so i explicitely
cast to be sure, which method is called (that was especially important (for Lucene 2.9) in
Java 1.4 when compiled with Java 5 - because the javac could use the wrong method without
casting to char (even with -source 1.4 -target 1.4) etc. For easy merging to 2.9 (as it is
still supported), I want to keep the casts. Thats all. If you like, add some @SuppressWarnings("foobar")
to it if you would be happy.

bq. More than that, if the method will declare it returns a long in the future, the cast will
generate a compile error. 

Changing return values of public methods will never happen. And if somebody would do this
by accident, the cast helps to find the error :-) -- thats only a funny addition.

> Code cleanup from all sorts of (trivial) warnings
> -------------------------------------------------
>                 Key: LUCENE-2285
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Shai Erera
>            Assignee: Uwe Schindler
>            Priority: Minor
>             Fix For: 3.1
>         Attachments: LUCENE-2285.patch, LUCENE-2285.patch, LUCENE-2285.patch
> 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.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message