lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: 2.9/3.0 plan & Java 1.5
Date Sun, 14 Dec 2008 13:26:02 GMT
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message