You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Simon Willnauer <si...@googlemail.com> on 2009/06/12 09:50:59 UTC
3.0, back-compat, Java 1.5 etc
hey there,
I see a lot of emails going on about 3.0, getting ready for Java 1.5 (
I guess enums, generics etc) and discussions about back-compat policy.
I'm curious if there is a kind of a roadmap or a document where I can
get up-to-date with all those targets and especially what we want to
achieve in 3.0.
I also saw a comment on LUCENE-1407 "...Searcher extend the RMI class,
but that will leave RMI in core. Or I can have Searchable implement
new methods, but that won't take us in the ultimate direction we want
- getting rid of interfaces."
I'm curious about why lucene wants to get rid of interfaces though?
I would be happy if somebody could point me out to a mailing-list
thread or whatever yields the information I asked for.
Thanks,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 3.0, back-compat, Java 1.5 etc
Posted by Simon Willnauer <si...@googlemail.com>.
Thanks guys!
On Fri, Jun 12, 2009 at 2:10 PM, Grant Ingersoll<gs...@apache.org> wrote:
>
> On Jun 12, 2009, at 3:50 AM, Simon Willnauer wrote:
>
>> hey there,
>> I see a lot of emails going on about 3.0, getting ready for Java 1.5 (
>> I guess enums, generics etc) and discussions about back-compat policy.
>> I'm curious if there is a kind of a roadmap or a document where I can
>> get up-to-date with all those targets and especially what we want to
>> achieve in 3.0.
>
> http://wiki.apache.org/lucene-java/Java%201.5%20Migration
>
>
>> I also saw a comment on LUCENE-1407 "...Searcher extend the RMI class,
>> but that will leave RMI in core. Or I can have Searchable implement
>> new methods, but that won't take us in the ultimate direction we want
>> - getting rid of interfaces."
>> I'm curious about why lucene wants to get rid of interfaces though?
>> I would be happy if somebody could point me out to a mailing-list
>> thread or whatever yields the information I asked for.
>
>
>
> ---------------------------------------------------------------------
> 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: 3.0, back-compat, Java 1.5 etc
Posted by Grant Ingersoll <gs...@apache.org>.
On Jun 12, 2009, at 3:50 AM, Simon Willnauer wrote:
> hey there,
> I see a lot of emails going on about 3.0, getting ready for Java 1.5 (
> I guess enums, generics etc) and discussions about back-compat policy.
> I'm curious if there is a kind of a roadmap or a document where I can
> get up-to-date with all those targets and especially what we want to
> achieve in 3.0.
http://wiki.apache.org/lucene-java/Java%201.5%20Migration
> I also saw a comment on LUCENE-1407 "...Searcher extend the RMI class,
> but that will leave RMI in core. Or I can have Searchable implement
> new methods, but that won't take us in the ultimate direction we want
> - getting rid of interfaces."
> I'm curious about why lucene wants to get rid of interfaces though?
> I would be happy if somebody could point me out to a mailing-list
> thread or whatever yields the information I asked for.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: 3.0, back-compat, Java 1.5 etc
Posted by Uwe Schindler <uw...@thetaphi.de>.
I think we should also insert the generics to at least the public APIs
before 3.0. This is not a real change to backwards compatibility or
anything, it is just adding the "annotations" which data types are used in
java collections and so on. But it should be done before 3.0, because after
3.0 it would a break to change the return value of a functions from List<?>
(which it is by default) to List<Field> or similar. As 3.0 is the first 1.5
release it should be done before!
I wanted to do this directly after the 2.9 release, there are tools, that
can do this half-automatically in e.g. Eclipse.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Friday, June 12, 2009 12:33 PM
> To: java-dev@lucene.apache.org; simon.willnauer@gmail.com
> Subject: Re: 3.0, back-compat, Java 1.5 etc
>
> On Fri, Jun 12, 2009 at 3:50 AM, Simon
> Willnauer<si...@googlemail.com> wrote:
>
> > I'm curious if there is a kind of a roadmap or a document where I can
> > get up-to-date with all those targets and especially what we want to
> > achieve in 3.0.
>
> I don't think we have such a doc...
>
> I think "the plan" at this point is quite straightforward: we are
> trying to wind down 2.9, and release it. We have 36 issues still open
> now...
>
> 3.0 will then be a mechanical release: "simply" remove all deprecated
> APIs, fix all core, contrib, tests to not use those APIs, release, and
> immediately begin accepting 1.5 patches.
>
> > I also saw a comment on LUCENE-1407 "...Searcher extend the RMI class,
> > but that will leave RMI in core. Or I can have Searchable implement
> > new methods, but that won't take us in the ultimate direction we want
> > - getting rid of interfaces."
> > I'm curious about why lucene wants to get rid of interfaces though?
>
> Because you can't add a new method to an interface w/o breaking
> back-compat. Vs an abstract class, where you can add the method w/ a
> default impl. We are trying to move away from interfaces for all but
> the most trivial situations now...
>
> 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: 3.0, back-compat, Java 1.5 etc
Posted by Robert Muir <rc...@gmail.com>.
here is a great link for this topic:
http://www.icu-project.org/docs/papers/supplementaries_iuc21.ppt
so you see it wouldn't be that invasive, and of course you can still
use char[], with some minor modifications to how you process text in
certain places.
its the parameters that take single char, etc that would potentially
be a compat issue.
On Fri, Jun 12, 2009 at 12:52 PM, Robert Muir<rc...@gmail.com> wrote:
> in general most stuff will be ok (code just doesnt mess with the
> surrogate pairs)
>
> simple example: things like lowercase filter are not, and
> lowercasetokenizer, well, can't fix that since its super
> chartokenizer, works on char.
>
> i hope this doesnt sound bad, but in general the transition is simple
> for most apps, because they work with String. Lucene works with char a
> lot, so its a bigger challenge, but I appreciate the good performance
> :)
>
>
> On Fri, Jun 12, 2009 at 12:45 PM, Michael
> McCandless<lu...@mikemccandless.com> wrote:
>> On Fri, Jun 12, 2009 at 9:09 AM, Robert Muir<rc...@gmail.com> wrote:
>>>>
>>>> 3.0 will then be a mechanical release: "simply" remove all deprecated
>>>> APIs, fix all core, contrib, tests to not use those APIs, release, and
>>>> immediately begin accepting 1.5 patches.
>>>>
>>>
>>> personally, I wonder if anyone but me is interested in correcting the
>>> issue that unicode character no longer fits in java 'char' in java 1.5
>>> :)
>>>
>>> maybe I am the only one, but i still think its correctness issue...,
>>> and will require changing some apis, even if its just char->int
>>
>> I think this is important.
>>
>> But it's a big change right? EG would we need to change tokens to be
>> int not char based?
>>
>> Also, can't this happen after 3.0?
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
>
>
> --
> Robert Muir
> rcmuir@gmail.com
>
--
Robert Muir
rcmuir@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 3.0, back-compat, Java 1.5 etc
Posted by Robert Muir <rc...@gmail.com>.
in general most stuff will be ok (code just doesnt mess with the
surrogate pairs)
simple example: things like lowercase filter are not, and
lowercasetokenizer, well, can't fix that since its super
chartokenizer, works on char.
i hope this doesnt sound bad, but in general the transition is simple
for most apps, because they work with String. Lucene works with char a
lot, so its a bigger challenge, but I appreciate the good performance
:)
On Fri, Jun 12, 2009 at 12:45 PM, Michael
McCandless<lu...@mikemccandless.com> wrote:
> On Fri, Jun 12, 2009 at 9:09 AM, Robert Muir<rc...@gmail.com> wrote:
>>>
>>> 3.0 will then be a mechanical release: "simply" remove all deprecated
>>> APIs, fix all core, contrib, tests to not use those APIs, release, and
>>> immediately begin accepting 1.5 patches.
>>>
>>
>> personally, I wonder if anyone but me is interested in correcting the
>> issue that unicode character no longer fits in java 'char' in java 1.5
>> :)
>>
>> maybe I am the only one, but i still think its correctness issue...,
>> and will require changing some apis, even if its just char->int
>
> I think this is important.
>
> But it's a big change right? EG would we need to change tokens to be
> int not char based?
>
> Also, can't this happen after 3.0?
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--
Robert Muir
rcmuir@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 3.0, back-compat, Java 1.5 etc
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Fri, Jun 12, 2009 at 9:09 AM, Robert Muir<rc...@gmail.com> wrote:
>>
>> 3.0 will then be a mechanical release: "simply" remove all deprecated
>> APIs, fix all core, contrib, tests to not use those APIs, release, and
>> immediately begin accepting 1.5 patches.
>>
>
> personally, I wonder if anyone but me is interested in correcting the
> issue that unicode character no longer fits in java 'char' in java 1.5
> :)
>
> maybe I am the only one, but i still think its correctness issue...,
> and will require changing some apis, even if its just char->int
I think this is important.
But it's a big change right? EG would we need to change tokens to be
int not char based?
Also, can't this happen after 3.0?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 3.0, back-compat, Java 1.5 etc
Posted by Robert Muir <rc...@gmail.com>.
>
> 3.0 will then be a mechanical release: "simply" remove all deprecated
> APIs, fix all core, contrib, tests to not use those APIs, release, and
> immediately begin accepting 1.5 patches.
>
personally, I wonder if anyone but me is interested in correcting the
issue that unicode character no longer fits in java 'char' in java 1.5
:)
maybe I am the only one, but i still think its correctness issue...,
and will require changing some apis, even if its just char->int
--
Robert Muir
rcmuir@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 3.0, back-compat, Java 1.5 etc
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Fri, Jun 12, 2009 at 3:50 AM, Simon
Willnauer<si...@googlemail.com> wrote:
> I'm curious if there is a kind of a roadmap or a document where I can
> get up-to-date with all those targets and especially what we want to
> achieve in 3.0.
I don't think we have such a doc...
I think "the plan" at this point is quite straightforward: we are
trying to wind down 2.9, and release it. We have 36 issues still open
now...
3.0 will then be a mechanical release: "simply" remove all deprecated
APIs, fix all core, contrib, tests to not use those APIs, release, and
immediately begin accepting 1.5 patches.
> I also saw a comment on LUCENE-1407 "...Searcher extend the RMI class,
> but that will leave RMI in core. Or I can have Searchable implement
> new methods, but that won't take us in the ultimate direction we want
> - getting rid of interfaces."
> I'm curious about why lucene wants to get rid of interfaces though?
Because you can't add a new method to an interface w/o breaking
back-compat. Vs an abstract class, where you can add the method w/ a
default impl. We are trying to move away from interfaces for all but
the most trivial situations now...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org