Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 35064 invoked from network); 14 Dec 2008 13:26:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Dec 2008 13:26:33 -0000 Received: (qmail 61603 invoked by uid 500); 14 Dec 2008 13:26:39 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 61557 invoked by uid 500); 14 Dec 2008 13:26:39 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 61548 invoked by uid 99); 14 Dec 2008 13:26:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Dec 2008 05:26:39 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.190.230.99] (HELO mail.troja.net) (80.190.230.99) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Dec 2008 13:26:24 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.troja.net (Postfix) with ESMTP id 1AA6C4E34F for ; Sun, 14 Dec 2008 14:26:04 +0100 (CET) Received: from mail.troja.net ([127.0.0.1]) by localhost (cyca.troja.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20572-09 for ; Sun, 14 Dec 2008 14:26:02 +0100 (CET) Received: from VEGA (port-83-236-62-11.dynamic.qsc.de [83.236.62.11]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.troja.net (Postfix) with ESMTP id 27C514E2F6 for ; Sun, 14 Dec 2008 14:26:02 +0100 (CET) From: "Uwe Schindler" To: References: <9ac0c6aa0812120218u42f5ffd1we938a1b4d04fb9fc@mail.gmail.com> <062E06CE-641C-413C-A0AC-8DCBAD70B160@apache.org> <6EBAAAFB-019C-4098-AA7E-AB87BE948A0D@mikemccandless.com>

<59b3eb370812140449i144d9a07l45334d4fb025a89d@mail.gmail.com> Subject: RE: 2.9/3.0 plan & Java 1.5 Date: Sun, 14 Dec 2008 14:26:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <59b3eb370812140449i144d9a07l45334d4fb025a89d@mail.gmail.com> Thread-Index: Acld6oh2edee99i5TJ2fb59G5RPq5gAAhyDg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Checked: Checked by ClamAV on apache.org 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 or List or List> or whatever. The correct answer is as far as I know List. 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, 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. > 2. Generics' utility is not limited to collections, we use it for > type-safe index fields storage/querying for example. > Define field: > FieldInfo 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