lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot" <>
Subject Re: 2.9/3.0 plan & Java 1.5
Date Sun, 14 Dec 2008 14:05:56 GMT
>> 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.
I'm simply suggesting it, like for 2010 :)
Vigorously preserving back-compatibility really takes the momentum out
of Lucene development effort, in my opinion. I'd be much happier to
rewrite half of my code each major release than limp along with some
ugly stuff just for the sake of someone dropping in a new lucene jar
into their mess and exclaiming - "Wow! It still works!"
But excuse me, I wasn't going to stir up old arguments.

> 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 :)
You can't extend Enum in any way other from writing "public enum
Parameter .. blah-blah" without resorting to really dirty tricks.

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