[
https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839224#action_12839224
]
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: https://issues.apache.org/jira/browse/LUCENE-2285
> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
