> 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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
