Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of markrmiller@gmail.com
 designates 74.125.92.25 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=YA739Fns6+kE+UY5XzCecpt7TYw3yXVgk/LrEMa8uiYKzVawAdz6CA/0l4BykmsyKm
         3A3jGThrqAS2GWw0qE233xpC7M8wFw4vhAIlStuWPcknqc5dl/IvUB7jWXFpXQEzC26W
         fBj3Keazbi2RDYWPWyMSLGw2sNtNcChhmVV3w=
Message-ID: <4A8DFFB7.2080001@gmail.com>
Date: Thu, 20 Aug 2009 22:00:23 -0400
From: Mark Miller <markrmiller@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090804)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Finishing Lucene 2.9
References: <4A89DF01.8060204@gmail.com>
 <023747052468446192CBC180E340FB74@VEGA> <4A8B0053.4030104@gmail.com>
 <9ac0c6aa0908181228o2c1cda63l2f77a09959c34a69@mail.gmail.com>
 <4A8C10FB.4030108@gmail.com> <596D2C98A44141778B23462582A1BE6E@VEGA>
 <4A8C7AE5.5040409@gmail.com>
 <9ac0c6aa0908200308o27e6a63atcf57188d5e6bc4af@mail.gmail.com>
 <4A8D485A.2010106@gmail.com>
 <786fde50908200605t527f56d5tf79f4e6b32f03ea8@mail.gmail.com>
 <648D9A4E4F1F418DB23BF94D14F1EA11@VEGA>
 <3AA449F0-5957-4DFA-B050-923D92424206@apache.org>
In-Reply-To: <3AA449F0-5957-4DFA-B050-923D92424206@apache.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

bq.  While technically it breaks back compatibility,

How does it break back compatibility? Generics are only compile time -
they simply don't exist in the binary. Java itself is extremely back
compat, so you can still use StringBuffer and the rest. I didn't find
anything in the archives or the wiki that talks about a back compat
break - that I can find anyway ...


Grant Ingersoll wrote:
> Please read the archives on the 1.5 move.  We have discussed it many
> times.  There is also a Wiki page on it under the committers section.
>  While technically it breaks back compatibility, we are going forward
> with it and we decided to allow generics, etc. right from the start.
>  We also didn't feel like we had to convert everything in one fell
> swoop, either, as that will break many existing patches.  
>
>
> On Aug 20, 2009, at 4:29 PM, Uwe Schindler wrote:
>
>> It would **not** break apps without generics, if the �upper� type is
>> the same (which is easily fulfilled by my example with the
>> AttributeSource). The whole 1.5 Java Collection API uses generics and
>> 1.4 programs still run.
>>  
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
>>
>> ------------------------------------------------------------------------
>> *From:* Shai Erera [mailto:serera@gmail.com] 
>> *Sent:* Thursday, August 20, 2009 3:05 PM
>> *To:* java-dev@lucene.apache.org <mailto:java-dev@lucene.apache.org>
>> *Subject:* Re: Finishing Lucene 2.9
>>  
>>
>> What will be w/ generics? Won't they break cack-compat as soon as we
>> add them (e.g., if we move to accepting parameters as generics - it
>> may break an application which does not use generics yet). I think
>> that the move to 1.5 needs to include the generics as well, unless
>> we're willing to break back-compat later on.
>>
>> Shai
>>
>> On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <markrmiller@gmail.com
>> <mailto:markrmiller@gmail.com>> wrote:
>>
>> Michael McCandless wrote:
>> > On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<markrmiller@gmail.com
>> <mailto:markrmiller@gmail.com>> wrote:
>> >
>> >
>> >> I forgot about this oddity. Its so weird. Its like we are doing two
>> >> releases on top of each other - it just seems confusing.
>> >>
>> >
>> > I'm also not wed to the "fast turnaround" (remove deprecations, switch
>> > to generics) 3.0 release.
>> >
>> > We could, instead, take out time doing the 3.0 release, ie let it
>> > include new features too.
>> >
>> > I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
>> > but I can't remember it nor find it now...
>> >
>> > Mike
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> <mailto:java-dev-unsubscribe@lucene.apache.org>
>> > For additional commands, e-mail: java-dev-help@lucene.apache.org
>> <mailto:java-dev-help@lucene.apache.org>
>> >
>> >
>> I thought the motivation was to provide a clean upgrade path with the
>> deprecations - you move to 2.9 and move from all the deprecated methods
>> - then you move to 3.0 and your good with no deprecations. I'd guess the
>> worry is that new features in 3.0 would add new deprecations and its not
>> quite so clean?
>>
>> Personally, I think thats fine though. New deprecations will come in 3.1
>> anyway. You can still move everything in 2.9, and then move to 3.0 - so
>> what if something else is now deprecated? You can move again or wait for
>> 3.9 to move ...
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> <mailto:java-dev-unsubscribe@lucene.apache.org>
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>> <mailto:java-dev-help@lucene.apache.org>
>>
>>  
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)
> using Solr/Lucene:
> http://www.lucidimagination.com/search
>


-- 
- Mark

http://www.lucidimagination.com


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org