Java5 migration

[Earwin Burrfoot <ea...@gmail.com>]

I intend to fire up IDEA, run java5-specific code inspections and fix
whatever it finds, something automatically (with manual review
afterwards), something by hand.

1. Replace for/while loops that go through arrays/lists by index, or
through collections by iterators with for-each loops.
This just looks cleaner, no matter the case.

2. Remove explicit boxing-unboxing.
Autoboxing looks cleaner and has identical behaviour/performance (eg
autoboxing calls the very same Number.valueOf methods we just migrated
to).

3. Parameterized classes without type parameters.
Some stuff was already converted, but I'd like the sources to be consistent.
I do not intend to add type parameters to the classes that don't have
them, only fix usage for those that already do (collections,
threadlocals I guess)

4. API migrations IDEA can detect for us, eg - Collections.EMPTY_* ->
Collections.empty*(), .indexOf(...) >= 0 -> .contains(...)

Can I merge some of these into single patch? If after this, there's
more than one patch, what is their preferred order?
And most important - is this needed right now? Are there any big
pending commits that will inevitably clash?

-- 
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

RE: Java5 migration

[Uwe Schindler <uw...@thetaphi.de>]

> I intend to fire up IDEA, run java5-specific code inspections and fix
> whatever it finds, something automatically (with manual review
> afterwards), something by hand.
>
> 1. Replace for/while loops that go through arrays/lists by index, or
> through collections by iterators with for-each loops.
> This just looks cleaner, no matter the case.


We had this discussion some time ago. The integrated for-each loop in Java
uses always iterators (for collections, not for arrays). This is often
slower than iterating via ArrayList.get(). These parts in Lucene are very
sensitive to speed. But whenever you see an iterator, you can safely replace
them.
And often you cannot use for-each loops, when you modify the iterator
(iterator.remove()). This is often done in the recently updated Document
(done by me) or AttributeSource. These two are already converted.

> 2. Remove explicit boxing-unboxing.
> Autoboxing looks cleaner and has identical behaviour/performance (eg
> autoboxing calls the very same Number.valueOf methods we just migrated
> to).

I for myself are strongly against these autoboxing. I use Java 5 code all
the time, but I *always* use Type.valueOf(). This is especially important,
if you have not yet typed collections. I want to be sure, that the untyped
collection contains the correct type. With generics (e.g. List<Integer>) it
is no problem, but not at the moment. So please: First use generics, then
autoboxing.

> 3. Parameterized classes without type parameters.
> Some stuff was already converted, but I'd like the sources to be
> consistent.
> I do not intend to add type parameters to the classes that don't have
> them, only fix usage for those that already do (collections,
> threadlocals I guess)

The CloseableThreadLocal have to be updated to generics before. But after
that I have no problem. I prefer doing it by hand. IDEA is good on the API
usage sige, but never use it for designing APIs generics. It often does not
use correct upper bounds, super and so on in generics. In API design it is
not useable. After doing this, the most important thing is to check, if the
backwards 2.9 branch not using generics still runs against the generified
stuff.

> 4. API migrations IDEA can detect for us, eg - Collections.EMPTY_* ->
> Collections.empty*(), .indexOf(...) >= 0 -> .contains(...)

+1, for generics it is needed, because these constants are not type-safe
(List<?>,...). For AttributeSource I also did a lot of generics stuff of
this kind for Class<?> (things like asSubclass(...), cast(...)). This must
be done at other code parts doing reflection, too.

> Can I merge some of these into single patch? If after this, there's
> more than one patch, what is their preferred order?
> And most important - is this needed right now? Are there any big
> pending commits that will inevitably clash?

I have no preference.

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org