Hi Earwin, > Two points here: > 1. "It should, because in the compiled JVM code, generics do simply > not appear." is not completely true. Types that have their type > parameters lower-bound, erase said parameters to this low bound and > not to Object. Google Guice uses this as a base to trick allowing > runtime generics reflection.
You are right, but erase means for the Collection API, that the lower bound is Object. The most important usage of generics in Lucene code is the already existing part that uses collections. In current code you often have to think about: "there is a method the receives a List, but what should this list contain? In javadocs there is no description about it" Best example is Document.getFields(): The method returns List, but you do not know without testing if its List<String> or List<Field> or List<List<String>> or whatever. The correct answer is as far as I know List<Fieldable>. This is realy hard to find out... For other things like ThreadLocal etc. we could simply map it, but there, the lower bound is also Object. When going through the current public API, you can check this for each part (if its collection api -> no problems, lower bound is Object, in other cases look twice). E.g. with collections it is simple: replace "List" in the method parameters by List<expected type according to javadoc>, for return types you may add a cast. A side note: there are some parts in Lucene's API that are not so good: very old constructors of Analyzer use e.g. Hashtable/HashMap/ArrayList/Vector/... as parameter etc. For clean code, it should be replaced by Map/Set/List interfaces. But this would not be backwards compatible. In this case I would try to first deprecate these constructors/methods in 1.9 and replace by more generic interfaces (using Map or Set). In 3.0 it is replaced by e.g. Set<String>. > 2. Generics' utility is not limited to collections, we use it for > type-safe index fields storage/querying for example. > Define field: > FieldInfo<EmployerCategory> EMPLOYER_CATEGORY = > field(ENUM(EmployerCategory.class), INDEX); > Store it: > add(vacancy.getEmployerCategory(), EMPLOYER_CATEGORY); > Query it: > return FilterTerm(EMPLOYER_CATEGORY, complementOf(EnumSet.of(AGENCY))); > > any field access is type-checked at compile time and happily > autocompletes in IDE You are right, too, but this change needs modifications in the Lucene API. I think this is a later step. Another step to Java 1.5 would be the use of Enum instead of Parameter, but this cannot be done easily without breaking backwards compatibility. A first approach would be to subclass "Parameter" to be instanceof "Enum". This can be done by deprecating the old methods, that map to Enum methods (but I think there are none). In short: replace the Parameter class by "Parameter extends Enum". In Lucene 4.0, the Parameter class disappears and we have nice clean enumeration types, which are also syntactical sugar :) Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
