lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Java5 migration
Date Thu, 08 Oct 2009 06:29:28 GMT
> 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
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

> 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

> 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.


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

View raw message