You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael McCandless <lu...@mikemccandless.com> on 2008/12/12 11:18:56 UTC
2.9/3.0 plan & Java 1.5
Taking this to java-dev (off Jira)...
Mark Miller (Jira) wrote:
> I thought there were some that wanted to change some of the API to java
> 5 for the 3.0 release, cause I thought back compat was less restricted
> 2-3. I guess mabye that won't end up happening, if it was going to, it
> seems we'd want to deprecate what will be changed in 2.9.
I could easily be confused on this... but I thought 3.0 is the first
release that's allowed to include Java 1.5 only APIs (eg generics).
Meaning, we could in theory intro APIs with generics with 3.0,
deprecating the non-generics versions, and then 4.0 (sounds insanely
far away!) would be the first release that could remove the deprecated
non-generics versions?
That said, I think the "plan" is to release 2.9 soonish (early next
year?), and then fairly quickly turnaround a 3.0 that doesn't have too
many changes except the removal of the deprecated (in 2.9) APIs. Ie
in practice it won't be until 3.1 when we would intro new
(generics-based) APIs.
Mike
RE: 2.9/3.0 plan & Java 1.5
Posted by Uwe Schindler <uw...@thetaphi.de>.
Parameterization of input parameters is also compile-compatible, you only
get warnings. You are still able to compile old java programs without
generics using new Java versions (this is how Java itself solves the
compatibility problem) The whole Java collection API uses generics, and you
can simply use it completely without generics.
You only have problems, if somebody uses generics is his own code around
Lucene and the new Lucene API uses other parameterization than this user
(e.g. closer types etc.). But most time this code would not work before,
too.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Yonik Seeley [mailto:yseeley@gmail.com]
> Sent: Saturday, December 13, 2008 11:16 PM
> To: java-dev@lucene.apache.org
> Subject: Re: 2.9/3.0 plan & Java 1.5
>
> Parametrization of return types should be fully back compatible.
> Parameterization of input parameters would be run-time compatible (due
> to type erasure), but not compile-time compatible.
>
> -Yonik
>
> On Sat, Dec 13, 2008 at 5:07 PM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
> >
> > Grant Ingersoll wrote:
> >
> >> IIRC, we also agreed that we didn't feel any compelling reason to make
> a
> >> sweeping change to generics, but would likely just add them as we see
> 'em,
> >> unless of course someone wants to do a wholesale patch.
> >
> > I like that approach.
> >
> >> In the case of generics, I see no reason why we can't intro them over
> >> time, people using the non-generic forms will still work.
> >
> > I don't fully understand the back compatibility of generics, but I did
> try
> > changing Document.getFields to return List<Fieldable> and even
> List<Integer>
> > (hmm), as well as separately changing a caller of that API to assign to
> a
> > List<Fieldable> type, and things compile & test fine.
> >
> > Does anyone know of any gotchyas that'd happen if in fact we slowly over
> > time changed existing APIs to use generics?
>
>
> > 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?
> >
> > Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Yonik Seeley <ys...@gmail.com>.
Parametrization of return types should be fully back compatible.
Parameterization of input parameters would be run-time compatible (due
to type erasure), but not compile-time compatible.
-Yonik
On Sat, Dec 13, 2008 at 5:07 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
>
> Grant Ingersoll wrote:
>
>> IIRC, we also agreed that we didn't feel any compelling reason to make a
>> sweeping change to generics, but would likely just add them as we see 'em,
>> unless of course someone wants to do a wholesale patch.
>
> I like that approach.
>
>> In the case of generics, I see no reason why we can't intro them over
>> time, people using the non-generic forms will still work.
>
> I don't fully understand the back compatibility of generics, but I did try
> changing Document.getFields to return List<Fieldable> and even List<Integer>
> (hmm), as well as separately changing a caller of that API to assign to a
> List<Fieldable> type, and things compile & test fine.
>
> Does anyone know of any gotchyas that'd happen if in fact we slowly over
> time changed existing APIs to use generics?
> 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?
>
> Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Earwin Burrfoot <ea...@gmail.com>.
> For return parameters, I think you should return the most specific interface
> you can give to the user (without fixing to something you may change in
> future versions). Maybe a user wants to use the return value of getFields()
> as List? If it's only Iterable, he cannot e.g. access the list directly.
> This is important, because the stored fields are an *ordered* list and maybe
> he wants the third entry in this list?
I second this.
Most specific interface available for return types, and least specific
required for parameter types.
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
RE: 2.9/3.0 plan & Java 1.5
Posted by Uwe Schindler <uw...@thetaphi.de>.
> >> 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!"
:-)
> > 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.
I meant it this way, but you are right, to keep backwards compatibility, you
have to do some dirty tricks :)
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Earwin Burrfoot <ea...@gmail.com>.
>> 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/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
RE: 2.9/3.0 plan & Java 1.5
Posted by Uwe Schindler <uw...@thetaphi.de>.
> > 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.
>
> Or even Iterable, which is new to Java 1.5 and usually makes more sense in
> a read-only context.
> Iterable could have also been used instead of List as a return value in
> method like Document.getFields() and so on, but again, this would not
> be backward compatible (although, for 3.0 we may decide that this is
> not absolutely necessary).
For input parameters Iterable or Collection would be good. Using deprecation
in 2.9 for the old constructors there and then use Collection (because
Iterable cannot be used as replacement in Java 1.4). But on the other hand,
the constructors there need a stop word set, not a list (each stop word
should only be there one time).
For return parameters, I think you should return the most specific interface
you can give to the user (without fixing to something you may change in
future versions). Maybe a user wants to use the return value of getFields()
as List? If it's only Iterable, he cannot e.g. access the list directly.
This is important, because the stored fields are an *ordered* list and maybe
he wants the third entry in this list?
If we want to keep backwards compatible, lets just replace the collection
interfaces by their generic'fied ones.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Nadav Har'El <ny...@math.technion.ac.il>.
On Sun, Dec 14, 2008, Uwe Schindler wrote about "RE: 2.9/3.0 plan & Java 1.5":
> 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.
Or even Iterable, which is new to Java 1.5 and usually makes more sense in
a read-only context.
Iterable could have also been used instead of List as a return value in
method like Document.getFields() and so on, but again, this would not
be backward compatible (although, for 3.0 we may decide that this is
not absolutely necessary).
--
Nadav Har'El | Sunday, Dec 14 2008, 18 Kislev 5769
IBM Haifa Research Lab |-----------------------------------------
|Hospital: Where they wake you up to give
http://nadav.harel.org.il |you a sleeping pill.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: 2.9/3.0 plan & Java 1.5
Posted by Uwe Schindler <uw...@thetaphi.de>.
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
Re: 2.9/3.0 plan & Java 1.5
Posted by Earwin Burrfoot <ea...@gmail.com>.
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
<lu...@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: uwe@thetaphi.de
>>
>>> -----Original Message-----
>>> From: Michael McCandless [mailto:lucene@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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
Re: 2.9/3.0 plan & Java 1.5
Posted by Michael McCandless <lu...@mikemccandless.com>.
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: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: 2.9/3.0 plan & Java 1.5
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Michael McCandless <lu...@mikemccandless.com>.
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: 2.9/3.0 plan & Java 1.5
Posted by Uwe Schindler <uw...@thetaphi.de>.
> 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.
This is why you can simply run a very old java class file using the
collection API with generics in Java 1.5 or 6. So you see, the best example
is Java itself.
Old programs e.g. link to ArrayList, but Java 1.5 has ArrayList<Something>.
The program will simply run, there changed nothing in the code semantics,
only in compile time semantics.
The only thing: Somebody compiling code with Java 1.5, that was written for
older Lucene, but using a new generics-enabled Lucene would get warnings
about unsafe use of generics APIs.
Sun states: "Generics are implemented by type erasure: generic type
information is present only at compile time, after which it is erased by the
compiler. The main advantage of this approach is that it provides total
interoperability between generic code and legacy code that uses
non-parameterized types (which are technically known as raw types). The main
disadvantages are that parameter type information is not available at run
time, and that automatically generated casts may fail when interoperating
with ill-behaved legacy code. There is, however, a way to achieve guaranteed
run-time type safety for generic collections even when interoperating with
ill-behaved legacy code."
(http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html)
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Michael McCandless <lu...@mikemccandless.com>.
Grant Ingersoll wrote:
> IIRC, we also agreed that we didn't feel any compelling reason to
> make a sweeping change to generics, but would likely just add them
> as we see 'em, unless of course someone wants to do a wholesale patch.
I like that approach.
> In the case of generics, I see no reason why we can't intro them
> over time, people using the non-generic forms will still work.
I don't fully understand the back compatibility of generics, but I did
try changing Document.getFields to return List<Fieldable> and even
List<Integer> (hmm), as well as separately changing a caller of that
API to assign to a List<Fieldable> type, and things compile & test fine.
Does anyone know of any gotchyas that'd happen if in fact we slowly
over time changed existing APIs to use generics?
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?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Grant Ingersoll <gs...@apache.org>.
Sounds good. I often wondered about using IntelliJ's "Generify"
refactor, too, but haven't tried it.
On Dec 17, 2008, at 3:35 AM, Paul Cowan wrote:
> Just for the record, to pick up this point of Grant's:
>
> Grant Ingersoll wrote:
>> IIRC, we also agreed that we didn't feel any compelling reason to
>> make a sweeping change to generics, but would likely just add them
>> as we see 'em, unless of course someone wants to do a wholesale
>> patch.
>
> I'll go on record as saying that if doing a 'wholesale patch' is the
> easiest way, I'm more than happy to do so. As an experiment I tried
> using a combination of Eclipse's "infer generic type
> arguments" (which is brilliant, but not perfect) and manual changes
> (where Eclipse doesn't quite manage to nail it) and managed to get
> ~2000 'use of raw types' warnings throughout the Lucene trunk
> codebase down to ~1000 in the space of an hour or so.
>
> There's a little bit of manual tidy-up involved but it's something
> I've done plenty of before (both internally and on external APIs,
> which obviously require more care) -- but if you want someone to do
> the gruntwork, well, just let me know when the 3.0-dev branch exists
> and is ready for commits and I'll set aside a day and give it a crack.
>
> Cheers,
>
> Paul
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Paul Cowan <co...@aconex.com>.
Just for the record, to pick up this point of Grant's:
Grant Ingersoll wrote:
> IIRC, we also agreed that we didn't feel any compelling reason to make a
> sweeping change to generics, but would likely just add them as we see
> 'em, unless of course someone wants to do a wholesale patch.
I'll go on record as saying that if doing a 'wholesale patch' is the
easiest way, I'm more than happy to do so. As an experiment I tried
using a combination of Eclipse's "infer generic type arguments" (which
is brilliant, but not perfect) and manual changes (where Eclipse doesn't
quite manage to nail it) and managed to get ~2000 'use of raw types'
warnings throughout the Lucene trunk codebase down to ~1000 in the space
of an hour or so.
There's a little bit of manual tidy-up involved but it's something I've
done plenty of before (both internally and on external APIs, which
obviously require more care) -- but if you want someone to do the
gruntwork, well, just let me know when the 3.0-dev branch exists and is
ready for commits and I'll set aside a day and give it a crack.
Cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Grant Ingersoll <gs...@apache.org>.
IIRC, we also agreed that we didn't feel any compelling reason to make
a sweeping change to generics, but would likely just add them as we
see 'em, unless of course someone wants to do a wholesale patch. In
the case of generics, I see no reason why we can't intro them over
time, people using the non-generic forms will still work.
On Dec 12, 2008, at 7:44 AM, Grant Ingersoll wrote:
> We agreed in the vote that we would allow generics, etc. in 3.0
> including the removal of non-generic versions of the same methods.
> In other words, we aren't strictly following the way we went from
> 1.9 to 2.0.
>
> I sent a thread on 2.9/3.0 planning a while ago, but got no
> responses...
>
>
> On Dec 12, 2008, at 5:18 AM, Michael McCandless wrote:
>
>>
>> Taking this to java-dev (off Jira)...
>>
>> Mark Miller (Jira) wrote:
>>
>> > I thought there were some that wanted to change some of the API
>> to java
>> > 5 for the 3.0 release, cause I thought back compat was less
>> restricted
>> > 2-3. I guess mabye that won't end up happening, if it was going
>> to, it
>> > seems we'd want to deprecate what will be changed in 2.9.
>>
>> I could easily be confused on this... but I thought 3.0 is the first
>> release that's allowed to include Java 1.5 only APIs (eg generics).
>>
>> Meaning, we could in theory intro APIs with generics with 3.0,
>> deprecating the non-generics versions, and then 4.0 (sounds insanely
>> far away!) would be the first release that could remove the
>> deprecated
>> non-generics versions?
>>
>> That said, I think the "plan" is to release 2.9 soonish (early next
>> year?), and then fairly quickly turnaround a 3.0 that doesn't have
>> too
>> many changes except the removal of the deprecated (in 2.9) APIs. Ie
>> in practice it won't be until 3.1 when we would intro new
>> (generics-based) APIs.
>>
>> Mike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Grant Ingersoll <gs...@apache.org>.
See also http://wiki.apache.org/lucene-java/Java_1.5_Migration
On Dec 12, 2008, at 7:44 AM, Grant Ingersoll wrote:
> We agreed in the vote that we would allow generics, etc. in 3.0
> including the removal of non-generic versions of the same methods.
> In other words, we aren't strictly following the way we went from
> 1.9 to 2.0.
>
> I sent a thread on 2.9/3.0 planning a while ago, but got no
> responses...
>
>
> On Dec 12, 2008, at 5:18 AM, Michael McCandless wrote:
>
>>
>> Taking this to java-dev (off Jira)...
>>
>> Mark Miller (Jira) wrote:
>>
>> > I thought there were some that wanted to change some of the API
>> to java
>> > 5 for the 3.0 release, cause I thought back compat was less
>> restricted
>> > 2-3. I guess mabye that won't end up happening, if it was going
>> to, it
>> > seems we'd want to deprecate what will be changed in 2.9.
>>
>> I could easily be confused on this... but I thought 3.0 is the first
>> release that's allowed to include Java 1.5 only APIs (eg generics).
>>
>> Meaning, we could in theory intro APIs with generics with 3.0,
>> deprecating the non-generics versions, and then 4.0 (sounds insanely
>> far away!) would be the first release that could remove the
>> deprecated
>> non-generics versions?
>>
>> That said, I think the "plan" is to release 2.9 soonish (early next
>> year?), and then fairly quickly turnaround a 3.0 that doesn't have
>> too
>> many changes except the removal of the deprecated (in 2.9) APIs. Ie
>> in practice it won't be until 3.1 when we would intro new
>> (generics-based) APIs.
>>
>> Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Doug Cutting <cu...@apache.org>.
Jason Rutherglen wrote:
> Decoupling IndexReader would for 3.0 would be great. This includes
> making public SegmentReader, MultiSegmentReader.
>
> A constructor like new SegmentReader(TermsDictionary termDictionary,
> TermPostings termPostings, ColumnStrideFields csd, DocIdBitSet deletedDocs);
>
> Where each class is abstract and can be implemented in an optional way.
>
> Decouple rollback, commit, IndexDeletionPolicy from DirectoryIndexReader
> into a class like SegmentsVersionSystem which could act as the
> controller for reopen types of methods. There could be a
> SegmentVersionSystem that manages the versioning of a single segment.
Can't this stuff be rolled out as new features in 3.0? The important
thing to do now is figure out what can be dropped when we go to 3.0, not
what might be added after.
> I'd rather figure out these things before worrying too much about
> generics which although nice for being able to read the code, doesn't
> matter if the code changes dramatically and is deprecated.
Folks are discussing whether generics are a special case for
back-compatibility. This is an important discussion, since major
releases are defined by their back-compatibility. This discussion thus
should have priority over the discussion of new 3.0 features.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Pluggable IndexReader (was 2.9/3.0 plan & Java 1.5)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Dec 15, 2008 at 07:04:08AM -0500, Michael McCandless wrote:
> These are good points: it may be exposing too much if we fully expose
> SegmentReader now, since some components (deletion tombstones) may
> want to skip that API and operate directly on lower level files.
After thinking things over, I no longer worry about this seeming
contradiction. Even if the tombstones deletions reader, the stored fields
reader, or some other component is reading files which were not written all in
one batch as part of the original collection of segment files, they still
relate to the same *logical* segment.
We wouldn't ever limit the set of files which a SegmentReader is allowed to
read from to the original segment files. Defining the collection of valid
files for a given point-in-time view of the index is the role of the Snapshot
in KS and the segments_NNN file in Lucene. It's up to the SegmentReader to
determine which files within the snapshot it should read from.
> >So, how about an IndexArchitecture or IndexPlan class?
> >
> > class MyArchitecture extends IndexArchitecture {
> > public PostingsWriter PostingsWriter() {
> > return new PForDeltaPostingsWriter();
> > }
> > public PostingsReader PostingsReader() {
> > return new PForDeltaPostingsReader();
> > }
> > public DeletionsWriter DeletionsWriter() {
> > return new TombstoneWriter();
> > }
> > public DeletionsReader DeletionsReader() {
> > return new TombstoneReader();
> > }
> > }
> > class MySchema extends Schema {
> > public MySchema() {
> > initField("title", "text");
> > initField("content", "text");
> > }
> > public IndexArchitecture indexArchitecture() {
> > return new MyArchitecture();
> > }
> > public Analyzer analyzer() {
> > return new PolyAnalyzer("en");
> > }
> > }
> >
> > IndexWriter writer = new IndexWriter(MySchema.open("/path/to/
> >index"));
>
> I think this is a reasonable approach. I might name it IndexCodec(s)
> though, and I agree conceptually it's orthogonal to a "schema".
FWIW, I've gone forward with "Architecture".
>>> Decouple rollback, commit, IndexDeletionPolicy from DirectoryIndexReader
>>> into a class like SegmentsVersionSystem which could act as the controller
>>> for reopen types of methods. There could be a SegmentVersionSystem that
>>> manages the versioning of a single segment.
>>
>> I like it. :)
>>
>> Sometimes you want to change up the merge policy for different writers
>> against the same index. How does that fit into your plan?
>>
>> My thought is that merge-policies would be application-specific
>> rather than index-specific.
>
> This one I'm a little hazy on. It would be nice to have a single
> source for IndexWriter & IndexReader-acting-as-writer to share this
> logic, but then we are [very, very slowly] migrating towards
> IndexWriter being the only thing that writes to an index so it seems
> like eventually it's OK if this logic is managed via the IndexWriter.
I'm thinking of calling this one "UpdatePolicy". It would collect together
MergePolicy, DeletionsPolicy, LockFactory, etc -- all the app-specific
behaviors related to interacting with existing data and files.
A Schema.makeUpdatePolicy() factory method can serve as the single, shared
source for this logic. However, the IndexWriter and IndexReader constructors
would allow the default UpdatePolicy to be overridden with an argument.
We end up with the following hierarchy:
* Architecture: Stuff that never changes for the life of the index.
Defining an Achitecture subclass is roughly analogous to choosing a
storage engine in MySQL (MyISAM vs. InnoDB, etc).
* Schema: Roughly analogous to an SQL table definition.
* UpdatePolicy: Stuff that can change up per-index-session.
Of those three classes, the only one that most users would encounter would be
Schema. Architecture and UpdatePolicy would isolate power-user functionality,
making it easier to grok and master basic indexing technique.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Pluggable IndexReader (was 2.9/3.0 plan & Java 1.5)
Posted by Michael McCandless <lu...@mikemccandless.com>.
Marvin Humphrey wrote:
> I have a bunch of file format changes to push through, and I'm
> hoping to
> implement them using pluggable modules. For instance, I'd like to
> be able to
> swap out bit-vector-based deletions for tombstone-based deletions,
> just by
> overriding a method or two.
I think Lucene should also aim for this (swappability of index codecs)
--
LUCENE-1458 is a step towards that specifically for postings. The
tombstone approach for deletions sounds compelling too, though first
we need to fix the API to switch to iterator only and stop calling
isDeleted
in document(docID).
PFOR, pulsing are other recent examples where if we had swappability,
people could more easily explore.
> Jason Rutherglen:
>
>> Decoupling IndexReader would for 3.0 would be great. This includes
>> making
>> public SegmentReader, MultiSegmentReader.
>
> I definitely think that IndexReader can and should be made more
> pluggable. Is
> exposing per-segment sub-readers a definite win, though? Does it
> make sense
> to leave open the door to index components which don't operate on
> segments?
> Or even to eliminate SegmentReader entirely and have sub-components of
> IndexReader manage collation?
>
> I've been thinking about this with regard to tombstone-based
> deletions, where
> you can't know everything about a segment unless you've opened up
> other
> segments.
These are good points: it may be exposing too much if we fully expose
SegmentReader now, since some components (deletion tombstones) may
want to skip that API and operate directly on lower level files.
Though, with LUCENE-1483 we are moving to excuting scoring &
collection per-segment.
>> A constructor like new SegmentReader(TermsDictionary termDictionary,
>> TermPostings termPostings, ColumnStrideFields csd, DocIdBitSet
>> deletedDocs);
>
> You end up with a proliferation of constructors that way. Term
> vectors?
> Arbitrary auxiliary components such as an R-tree component supporting
> geographic search?
>
> My original proposal to clean this up involved an "IndexComponent"
> class.
> However, when I started implementing it, I ended up with a slew of
> new classes
> with only two factory methods each.
>
> We could possibly move those factory methods up into Schema, but I'm
> reluctant to
> dirty it up, since it's a major public class in KS (as I anticipate
> it will be
> in Lucy) and major public classes should be as simple as possible.
>
> So, how about an IndexArchitecture or IndexPlan class?
>
> class MyArchitecture extends IndexArchitecture {
> public PostingsWriter PostingsWriter() {
> return new PForDeltaPostingsWriter();
> }
> public PostingsReader PostingsReader() {
> return new PForDeltaPostingsReader();
> }
> public DeletionsWriter DeletionsWriter() {
> return new TombstoneWriter();
> }
> public DeletionsReader DeletionsReader() {
> return new TombstoneReader();
> }
> }
>
> Lucene:
>
> IndexWriter writer = new IndexWriter("/path/to/index",
> new StandardAnalyzer(), new MyArchitecture());
>
> Lucy with Java bindings:
>
> class MySchema extends Schema {
> public MySchema() {
> initField("title", "text");
> initField("content", "text");
> }
> public IndexArchitecture indexArchitecture() {
> return new MyArchitecture();
> }
> public Analyzer analyzer() {
> return new PolyAnalyzer("en");
> }
> }
>
> IndexWriter writer = new IndexWriter(MySchema.open("/path/to/
> index"));
I think this is a reasonable approach. I might name it IndexCodec(s)
though, and I agree conceptually it's orthogonal to a "schema".
>> Decouple rollback, commit, IndexDeletionPolicy from
>> DirectoryIndexReader
>> into a class like SegmentsVersionSystem which could act as the
>> controller
>> for reopen types of methods. There could be a SegmentVersionSystem
>> that
>> manages the versioning of a single segment.
>
> I like it. :)
>
> Sometimes you want to change up the merge policy for different
> writers against
> the same index. How does that fit into your plan?
>
> My thought is that merge-policies would be application-specific
> rather than
> index-specific.
This one I'm a little hazy on. It would be nice to have a single
source for IndexWriter & IndexReader-acting-as-writer to share this
logic, but then we are [very, very slowly] migrating towards
IndexWriter being the only thing that writes to an index so it seems
like eventually it's OK if this logic is managed via the IndexWriter.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Pluggable IndexReader (was 2.9/3.0 plan & Java 1.5)
Posted by Marvin Humphrey <ma...@rectangular.com>.
Doug Cutting:
> Folks are discussing whether generics are a special case for
> back-compatibility. This is an important discussion, since major
> releases are defined by their back-compatibility. This discussion thus
> should have priority over the discussion of new 3.0 features.
Okeedoke. Since I'm working on this right now for KS, though, I'd like to
continue the conversation under a new thread heading.
I have a bunch of file format changes to push through, and I'm hoping to
implement them using pluggable modules. For instance, I'd like to be able to
swap out bit-vector-based deletions for tombstone-based deletions, just by
overriding a method or two.
Jason Rutherglen:
> Decoupling IndexReader would for 3.0 would be great. This includes making
> public SegmentReader, MultiSegmentReader.
I definitely think that IndexReader can and should be made more pluggable. Is
exposing per-segment sub-readers a definite win, though? Does it make sense
to leave open the door to index components which don't operate on segments?
Or even to eliminate SegmentReader entirely and have sub-components of
IndexReader manage collation?
I've been thinking about this with regard to tombstone-based deletions, where
you can't know everything about a segment unless you've opened up other
segments.
> A constructor like new SegmentReader(TermsDictionary termDictionary,
> TermPostings termPostings, ColumnStrideFields csd, DocIdBitSet deletedDocs);
You end up with a proliferation of constructors that way. Term vectors?
Arbitrary auxiliary components such as an R-tree component supporting
geographic search?
My original proposal to clean this up involved an "IndexComponent" class.
However, when I started implementing it, I ended up with a slew of new classes
with only two factory methods each.
We could possibly move those factory methods up into Schema, but I'm reluctant to
dirty it up, since it's a major public class in KS (as I anticipate it will be
in Lucy) and major public classes should be as simple as possible.
So, how about an IndexArchitecture or IndexPlan class?
class MyArchitecture extends IndexArchitecture {
public PostingsWriter PostingsWriter() {
return new PForDeltaPostingsWriter();
}
public PostingsReader PostingsReader() {
return new PForDeltaPostingsReader();
}
public DeletionsWriter DeletionsWriter() {
return new TombstoneWriter();
}
public DeletionsReader DeletionsReader() {
return new TombstoneReader();
}
}
Lucene:
IndexWriter writer = new IndexWriter("/path/to/index",
new StandardAnalyzer(), new MyArchitecture());
Lucy with Java bindings:
class MySchema extends Schema {
public MySchema() {
initField("title", "text");
initField("content", "text");
}
public IndexArchitecture indexArchitecture() {
return new MyArchitecture();
}
public Analyzer analyzer() {
return new PolyAnalyzer("en");
}
}
IndexWriter writer = new IndexWriter(MySchema.open("/path/to/index"));
> Decouple rollback, commit, IndexDeletionPolicy from DirectoryIndexReader
> into a class like SegmentsVersionSystem which could act as the controller
> for reopen types of methods. There could be a SegmentVersionSystem that
> manages the versioning of a single segment.
I like it. :)
Sometimes you want to change up the merge policy for different writers against
the same index. How does that fit into your plan?
My thought is that merge-policies would be application-specific rather than
index-specific.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Jason Rutherglen <ja...@gmail.com>.
Decoupling IndexReader would for 3.0 would be great. This includes making
public SegmentReader, MultiSegmentReader.
A constructor like new SegmentReader(TermsDictionary termDictionary,
TermPostings termPostings, ColumnStrideFields csd, DocIdBitSet deletedDocs);
Where each class is abstract and can be implemented in an optional way.
Decouple rollback, commit, IndexDeletionPolicy from DirectoryIndexReader
into a class like SegmentsVersionSystem which could act as the controller
for reopen types of methods. There could be a SegmentVersionSystem that
manages the versioning of a single segment.
I'd rather figure out these things before worrying too much about generics
which although nice for being able to read the code, doesn't matter if the
code changes dramatically and is deprecated.
> of the alternative "big bang" approach.
Is this the type of thing you mean by the "big bang" approach?
On Fri, Dec 12, 2008 at 4:44 AM, Grant Ingersoll <gs...@apache.org>wrote:
> We agreed in the vote that we would allow generics, etc. in 3.0 including
> the removal of non-generic versions of the same methods. In other words, we
> aren't strictly following the way we went from 1.9 to 2.0.
>
> I sent a thread on 2.9/3.0 planning a while ago, but got no responses...
>
>
> On Dec 12, 2008, at 5:18 AM, Michael McCandless wrote:
>
>
>> Taking this to java-dev (off Jira)...
>>
>> Mark Miller (Jira) wrote:
>>
>> > I thought there were some that wanted to change some of the API to java
>> > 5 for the 3.0 release, cause I thought back compat was less restricted
>> > 2-3. I guess mabye that won't end up happening, if it was going to, it
>> > seems we'd want to deprecate what will be changed in 2.9.
>>
>> I could easily be confused on this... but I thought 3.0 is the first
>> release that's allowed to include Java 1.5 only APIs (eg generics).
>>
>> Meaning, we could in theory intro APIs with generics with 3.0,
>> deprecating the non-generics versions, and then 4.0 (sounds insanely
>> far away!) would be the first release that could remove the deprecated
>> non-generics versions?
>>
>> That said, I think the "plan" is to release 2.9 soonish (early next
>> year?), and then fairly quickly turnaround a 3.0 that doesn't have too
>> many changes except the removal of the deprecated (in 2.9) APIs. Ie
>> in practice it won't be until 3.1 when we would intro new
>> (generics-based) APIs.
>>
>> Mike
>>
>
> --------------------------
> Grant Ingersoll
>
> Lucene Helpful Hints:
> http://wiki.apache.org/lucene-java/BasicsOfPerformance
> http://wiki.apache.org/lucene-java/LuceneFAQ
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: 2.9/3.0 plan & Java 1.5
Posted by Grant Ingersoll <gs...@apache.org>.
We agreed in the vote that we would allow generics, etc. in 3.0
including the removal of non-generic versions of the same methods. In
other words, we aren't strictly following the way we went from 1.9 to
2.0.
I sent a thread on 2.9/3.0 planning a while ago, but got no responses...
On Dec 12, 2008, at 5:18 AM, Michael McCandless wrote:
>
> Taking this to java-dev (off Jira)...
>
> Mark Miller (Jira) wrote:
>
> > I thought there were some that wanted to change some of the API to
> java
> > 5 for the 3.0 release, cause I thought back compat was less
> restricted
> > 2-3. I guess mabye that won't end up happening, if it was going
> to, it
> > seems we'd want to deprecate what will be changed in 2.9.
>
> I could easily be confused on this... but I thought 3.0 is the first
> release that's allowed to include Java 1.5 only APIs (eg generics).
>
> Meaning, we could in theory intro APIs with generics with 3.0,
> deprecating the non-generics versions, and then 4.0 (sounds insanely
> far away!) would be the first release that could remove the deprecated
> non-generics versions?
>
> That said, I think the "plan" is to release 2.9 soonish (early next
> year?), and then fairly quickly turnaround a 3.0 that doesn't have too
> many changes except the removal of the deprecated (in 2.9) APIs. Ie
> in practice it won't be until 3.1 when we would intro new
> (generics-based) APIs.
>
> Mike
--------------------------
Grant Ingersoll
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Michael McCandless <lu...@mikemccandless.com>.
I can certainly see the benefit/temptation of the alternative "big
bang" approach.
It's just not clear to me (yet) which way (big bang or not) we're
planning to go, with 3.x.
Mike
Shai Erera wrote:
> I wonder why do we even have to deprecate ...
> A method like public void function( List<Term> list ) changes
> nothing in terms of API. When people will move to 3.0, they'll have
> to change their JDK anyway to 5 (if they haven't already done so).
> Which means they had code like:
> function(List), and where List was not defined as generics. But
> they'll get a warning anyway by the compiler, when they define List,
> that it's not safe to create a list w/o defining its type.
>
> I think that when you move to 5 you have to change a lot of your
> code anyway, so simply changing the Lucene API will not create too
> much of a hassle for existing applications.
>
> Personally I'd hate to find out I have to change my entire
> application because method/classes names were changed.
>
> Shai
>
> On Fri, Dec 12, 2008 at 1:44 PM, Michael McCandless <lucene@mikemccandless.com
> > wrote:
>
> Ryan McKinley wrote:
>
>
> On Dec 12, 2008, at 5:18 AM, Michael McCandless wrote:
>
>
> Taking this to java-dev (off Jira)...
>
> Mark Miller (Jira) wrote:
>
> > I thought there were some that wanted to change some of the API to
> java
> > 5 for the 3.0 release, cause I thought back compat was less
> restricted
> > 2-3. I guess mabye that won't end up happening, if it was going
> to, it
> > seems we'd want to deprecate what will be changed in 2.9.
>
> I could easily be confused on this... but I thought 3.0 is the first
> release that's allowed to include Java 1.5 only APIs (eg generics).
>
> Meaning, we could in theory intro APIs with generics with 3.0,
> deprecating the non-generics versions, and then 4.0 (sounds insanely
> far away!) would be the first release that could remove the deprecated
> non-generics versions?
>
> That said, I think the "plan" is to release 2.9 soonish (early next
> year?), and then fairly quickly turnaround a 3.0 that doesn't have too
> many changes except the removal of the deprecated (in 2.9) APIs. Ie
> in practice it won't be until 3.1 when we would intro new
> (generics-based) APIs.
>
>
>
> What are examples of the deprecated non-generic APIs?
>
> My understanding would be that in 2.9 we have:
> public void function( List list );
> and in 3.0
> public void function( List<Term> list );
>
> How do you keep both functions around?
>
> We'd have to change the name? Or deprecate the whole class
> containing these methods (if there are lots of methods to
> deprecate)? Definitely something of a hassle.
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Shai Erera <se...@gmail.com>.
I wonder why do we even have to deprecate ...
A method like public void function( List<Term> list ) changes nothing in
terms of API. When people will move to 3.0, they'll have to change their JDK
anyway to 5 (if they haven't already done so). Which means they had code
like:
function(List), and where List was not defined as generics. But they'll get
a warning anyway by the compiler, when they define List, that it's not safe
to create a list w/o defining its type.
I think that when you move to 5 you have to change a lot of your code
anyway, so simply changing the Lucene API will not create too much of a
hassle for existing applications.
Personally I'd hate to find out I have to change my entire application
because method/classes names were changed.
Shai
On Fri, Dec 12, 2008 at 1:44 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:
>
> Ryan McKinley wrote:
>
>
>> On Dec 12, 2008, at 5:18 AM, Michael McCandless wrote:
>>
>>
>>> Taking this to java-dev (off Jira)...
>>>
>>> Mark Miller (Jira) wrote:
>>>
>>> > I thought there were some that wanted to change some of the API to java
>>> > 5 for the 3.0 release, cause I thought back compat was less restricted
>>> > 2-3. I guess mabye that won't end up happening, if it was going to, it
>>> > seems we'd want to deprecate what will be changed in 2.9.
>>>
>>> I could easily be confused on this... but I thought 3.0 is the first
>>> release that's allowed to include Java 1.5 only APIs (eg generics).
>>>
>>> Meaning, we could in theory intro APIs with generics with 3.0,
>>> deprecating the non-generics versions, and then 4.0 (sounds insanely
>>> far away!) would be the first release that could remove the deprecated
>>> non-generics versions?
>>>
>>> That said, I think the "plan" is to release 2.9 soonish (early next
>>> year?), and then fairly quickly turnaround a 3.0 that doesn't have too
>>> many changes except the removal of the deprecated (in 2.9) APIs. Ie
>>> in practice it won't be until 3.1 when we would intro new
>>> (generics-based) APIs.
>>>
>>>
>>
>> What are examples of the deprecated non-generic APIs?
>>
>> My understanding would be that in 2.9 we have:
>> public void function( List list );
>> and in 3.0
>> public void function( List<Term> list );
>>
>> How do you keep both functions around?
>>
>
> We'd have to change the name? Or deprecate the whole class containing
> these methods (if there are lots of methods to deprecate)? Definitely
> something of a hassle.
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: 2.9/3.0 plan & Java 1.5
Posted by Michael McCandless <lu...@mikemccandless.com>.
Ryan McKinley wrote:
>
> On Dec 12, 2008, at 5:18 AM, Michael McCandless wrote:
>
>>
>> Taking this to java-dev (off Jira)...
>>
>> Mark Miller (Jira) wrote:
>>
>> > I thought there were some that wanted to change some of the API
>> to java
>> > 5 for the 3.0 release, cause I thought back compat was less
>> restricted
>> > 2-3. I guess mabye that won't end up happening, if it was going
>> to, it
>> > seems we'd want to deprecate what will be changed in 2.9.
>>
>> I could easily be confused on this... but I thought 3.0 is the first
>> release that's allowed to include Java 1.5 only APIs (eg generics).
>>
>> Meaning, we could in theory intro APIs with generics with 3.0,
>> deprecating the non-generics versions, and then 4.0 (sounds insanely
>> far away!) would be the first release that could remove the
>> deprecated
>> non-generics versions?
>>
>> That said, I think the "plan" is to release 2.9 soonish (early next
>> year?), and then fairly quickly turnaround a 3.0 that doesn't have
>> too
>> many changes except the removal of the deprecated (in 2.9) APIs. Ie
>> in practice it won't be until 3.1 when we would intro new
>> (generics-based) APIs.
>>
>
>
> What are examples of the deprecated non-generic APIs?
>
> My understanding would be that in 2.9 we have:
> public void function( List list );
> and in 3.0
> public void function( List<Term> list );
>
> How do you keep both functions around?
We'd have to change the name? Or deprecate the whole class containing
these methods (if there are lots of methods to deprecate)? Definitely
something of a hassle.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Ryan McKinley <ry...@gmail.com>.
On Dec 12, 2008, at 5:18 AM, Michael McCandless wrote:
>
> Taking this to java-dev (off Jira)...
>
> Mark Miller (Jira) wrote:
>
> > I thought there were some that wanted to change some of the API to
> java
> > 5 for the 3.0 release, cause I thought back compat was less
> restricted
> > 2-3. I guess mabye that won't end up happening, if it was going
> to, it
> > seems we'd want to deprecate what will be changed in 2.9.
>
> I could easily be confused on this... but I thought 3.0 is the first
> release that's allowed to include Java 1.5 only APIs (eg generics).
>
> Meaning, we could in theory intro APIs with generics with 3.0,
> deprecating the non-generics versions, and then 4.0 (sounds insanely
> far away!) would be the first release that could remove the deprecated
> non-generics versions?
>
> That said, I think the "plan" is to release 2.9 soonish (early next
> year?), and then fairly quickly turnaround a 3.0 that doesn't have too
> many changes except the removal of the deprecated (in 2.9) APIs. Ie
> in practice it won't be until 3.1 when we would intro new
> (generics-based) APIs.
>
What are examples of the deprecated non-generic APIs?
My understanding would be that in 2.9 we have:
public void function( List list );
and in 3.0
public void function( List<Term> list );
How do you keep both functions around?
ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9/3.0 plan & Java 1.5
Posted by Mark Miller <ma...@gmail.com>.
Michael McCandless wrote:
>
> Taking this to java-dev (off Jira)...
>
> Mark Miller (Jira) wrote:
>
> > I thought there were some that wanted to change some of the API to java
> > 5 for the 3.0 release, cause I thought back compat was less restricted
> > 2-3. I guess mabye that won't end up happening, if it was going to, it
> > seems we'd want to deprecate what will be changed in 2.9.
>
> I could easily be confused on this... but I thought 3.0 is the first
> release that's allowed to include Java 1.5 only APIs (eg generics).
>
> Meaning, we could in theory intro APIs with generics with 3.0,
> deprecating the non-generics versions, and then 4.0 (sounds insanely
> far away!) would be the first release that could remove the deprecated
> non-generics versions?
>
> That said, I think the "plan" is to release 2.9 soonish (early next
> year?), and then fairly quickly turnaround a 3.0 that doesn't have too
> many changes except the removal of the deprecated (in 2.9) APIs. Ie
> in practice it won't be until 3.1 when we would intro new
> (generics-based) APIs.
>
> Mike
Okay, that makes sense. I guess we have to give something to move to if
we deprecate ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org