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.
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 On Sun, Dec 14, 2008 at 15:07, Michael McCandless <luc...@mikemccandless.com> wrote: > > I like that approach. So we just need a volunteer to do at least step 1, > for 3.0, which should be reasonably straightforward. > > Another big effort for 3.0 will be fixing all places internal to Lucene > (including contrib, tests) that still use deprecated APIs. > > Mike > > Uwe Schindler wrote: > >> A good idea would be to do the transformation to generics like the >> following: >> >> - write a patch that replaces all *public* API declarations with generics >> (especially Document, Fieldable and so on where a lot of List/Sets occur). >> The Lucene code behind these declarations will compile without any >> problem, >> it will only print out warnings (e.g. a method takes an argument >> List<Fieldable> but the internal member variable is just List, the >> assignment will generate the warning. By adding <compilerarg >> line="-Xlint:unchecked" /> to the build.xml scripts, the compiler will >> print >> the warnings more detailed with line numbers etc., can be much output). At >> return values you sometimes have to place a cast (assign not-generics to a >> generics type does not work with 1.5). This cast also generates an unsafe >> warning. >> >> - start to fix all places in Lucene where the compiler produces warnings. >> You start with the parts directly behind the public API, when finished the >> compiler gives warnings for the next and so on. >> >> The first could be one patch available in Lucene starting with 3.0 (so the >> public API is generics, without much hassle). The other patches can be >> done >> step by step to remove the compiler warnings. >> >> ----- >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> >>> -----Original Message----- >>> From: Michael McCandless [mailto:luc...@mikemccandless.com] >>> Sent: Sunday, December 14, 2008 12:31 PM >>> To: java-dev@lucene.apache.org >>> Subject: Re: 2.9/3.0 plan & Java 1.5 >>> >>> >>> Uwe Schindler wrote: >>> >>>>> EG I haven't yet tested for JAR drop-in compatibility, eg if in 3.1 >>>>> we >>>>> wanted to swap in more generics, would a 3.0 app be able to drop in >>>>> the 3.1 Lucene jar w/o problems? >>>> >>>> It should, because in the compiled JVM code, generics do simply not >>>> appear. >>> >>> Ahhhh, right. So I think this means we can safely, over time, swap in >>> generics for these APIs w/o going through our normal back >>> compatibility steps (deprecate old, rename to new, etc.). Even say in >>> the 3.1 release (a minor release) we can swap in generics for APIs. >>> Great! >>> >>> Mike >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785
