Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: domain of dmsmith555@gmail.com designates
 64.233.162.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=bBXW8uQObMwLt8C7FPiuAle480N6Y28GXuuWrPrpCcFd+8B6efVWK95DIuaoJW+zX2tdRsdSgD58GJKZT3oUqFCVs9JtZtlLlEPz5HyrP4iEItHT+w5c6MBfS9IwxKGCRYUEv7W2bkuDCkLt7odTA/syvQRTnxChNCT8R+bLUoY=
Message-ID: <3670ca6c0606211148s42c3130dy16db62bb5f22861a@mail.gmail.com>
Date: Wed, 21 Jun 2006 14:48:43 -0400
From: "DM Smith" <dmsmith555@gmail.com>
To: java-dev@lucene.apache.org
Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
In-Reply-To: <20060621154907.73301.qmail@web50301.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_6435_19772283.1150915723781"
References: <9E37C977-5FE0-4E15-8283-478E5D28A551@gmail.com>
	 <20060621154907.73301.qmail@web50301.mail.yahoo.com>

------=_Part_6435_19772283.1150915723781
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/21/06, Otis Gospodnetic <otis_gospodnetic@yahoo.com> wrote:
>
> Hi,
>
> ----- Original Message ----
> From: DM Smith <dmsmith555@gmail.com>
>
> On Jun 21, 2006, at 7:52 AM, Grant Ingersoll wrote:
>
> > This sounds reasonable to me...
>
> OG: It sounded reasonable to me, too.  I don't quite understand why that's
> SO hard to accept.  Btw., I run Lucene 1.4.3 on Java 1.4.2 as well, so I'm
> not trying to push 1.5 because of my personal interests.
>
> OG: To be perfectly honest, and that may turn out to be a mistake, this
> argument is starting to sound kind of selfish - a handful of people want the
> latest Lucene, but won't let it advance with 1.5 contributions because 1.5wouldn't work for them.  At the same time they are not thinking of the
> majority that would benefit from new contributions.


I'm not trying to be selfish. I guess that part of the problem is that I am
not a contributor, but a user. Perhaps I need to "put money where my mouth
is" I'd be happy to maintain the core code as 1.4, if that would be
acceptable. That is, when a patch is provided that is Java 5, I'd supply one
that is 1.4.

Again, we still run Lucene 1.4.3 on Java 1.4.2 on technorati.com , for
> example, and I'm purely arguing this case because I don't want to reject the
> nice people who contribute 1.5 code.


It has already been agreed upon that Java 5 is appropriate for contrib.

Generally open source projects have a policy to change as little of the file
as possible, only changing what is necessary. I have not heard it stated
here, but it appears that this is followed here too. If that is the case, I
expect that most of what is currently Lucene will continue to be binary
compatible with Java 1.4. (All of it is still binary compatible with 1.2,
but requires a 1.4 jre to run. Under Java 1.3 I get about 65 errors and most
of those are cascading, errors because of errors of classes not found).

IMHO, changes to a file should not look out of place. That is they should
follow the same style as the rest of the file. So, i would argue, if a file
uses old fashioned iteration for all of its loops then a new loop should not
use the enhanced for loop. If collections are not parameterized then a new
collection added to a file should not be paramaterized. If the api does not
currently expose parameterized collections then a new method should not.
Unless the whole file is changed to be consistent.

What I have noticed is that these changes frequently have a ripple effect if
they hit the api.

So I think that some guidelines should be provided before any Java 5 code is
allowed.

If the guidelines become that existing code's api is retained as much as
possible, that existing code changes as little as possible, that each file
needs to maintain an internal consistency of style, that packages need to
maintain a consistent style of the api, ... then I don't see the existing
core of Lucene changing much from an external perspective.

Where I see it changing is when there is a new feature to be added to core
that adds a new class and it takes advantage of Java 5 in such a way that it
does not make sense to do it in Java 1.4. In the first thread on this
subject, it was suggested (not by me) that this would be the point at which
Java 5 would be seriously considered. IMHO, at that point it should not be a
discussion about Java 5 but whether the feature and its implementation are
appropriate at that point in time. And I think that prior to that the debate
concerning Java 5 vs Java 1.4 generates lots of heat and little light.

Anyway, I think I have said all the more that I will say on this thread.

But it is not at all reasonable for us. Our application is designed
> with a write one, run anywhere mentality for the hardware/OS base
> that our users currently have. Again many of our users use old,
>
> OG: Not to be mean or anything like that, but it sounds like that's a
> problem with the design of this particular application.  It has to run on
> customers' computers that you are not in control of, yet designed in a
> monolithic write one, run anywhere fashion.  Isn't this always going to be a
> problem for you?


I meant "write once" not "write one". Not that it changes anything :)

The applicaiton is not monolithic, but plugin based. We hope that the core
libraries that we provide could be used in other contexts by providing a
different UI, e.g. web, pda, phone, ....

I think that before you comment on its design, it would be worth taking a
look at first. And because of that I don't take your comment as mean.


If your users are already users of hand-me-down computers and are very used
> to running old software and hardware, do they really need the latest and
> greatest Lucene?  Why?


The biggest reason is for performance enhancements. They have had the
greatest effect on these older machines. As I have said in another post, I
am very impressed with Lucene's performance on older hardware!

A secondary reason is to provide additional search features to the
application. We would like to add the ability for leading wild card search.
(I'm not wanting to reopen that discussion.) One of the things that we do
not do right now is searching stems. Our primary domain for that would be
Biblical Greek and Hebrew.  Related to this is the ability to search for
Biblical concepts/topics such as grace. Another feature we want to add is
the ability to search accented text without regard to accents. And another
is to search via transliteration, that is, the user types in a
transliteration of Greek or Hebrew to search Greek and Hebrew. I really have
not looked into it to see what Lucene provides or what is available
otherwise. I imagine that some of these will be layered on top of Lucene and
may change how we build the index.

For all of these things, I don't see that we need to abandon the older
machines.

It may be that Lucene 2.0.x will provide everything that we might want to
add. Or that we can downgrade Java 1.5 contributions and use that.

Otis
>
> > Robert Engels wrote:
> >> I don't follow...
> >>
> >> If a user came to you and said I want to run BibleDesktop, and
> >> they have
> >> MS-DOS, you would tell them you can't (or you might have to run
> >> the very old
> >> BibleDesktop 1.0).
> >>
> >> If they told you they have Windows 98 with Java 1.4 and 256mb or
> >> memory, you
> >> would say you can run BibleDesktop 2.0 (which includes Lucene 2.0).
> >>
> >> If they told you they have Windows XP with Java 1.5, you would say
> >> you can
> >> run BibleDesktop 3.0 (which includes Lucene 2.1).
> >>
> >> Certainly seems like a packaging/marketing issue for you. Your
> >> users would
> >> not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor
> >> would they
> >> care.
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: DM Smith [mailto:dmsmith555@gmail.com ] Sent: Tuesday, June
> >> 20, 2006 5:17 PM
> >> To: java-dev@lucene.apache.org
> >> Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
> >>
> >>
> >> On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote:
> >>
> >>
> >>>  ----- Original Message ----
> >>> From: DM Smith
> >>>
> >>>
> >>> On 6/20/06, Otis Gospodnetic  wrote: Sorry, for some reason my
> >>> Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for
> >>> my lines.
> >>>
> >>> In my situation, I am constantly working on improving an open
> >>> source application. Our use of Lucene is very trivial (from a
> >>> lucene perspective) but critical to the application. If there are
> >>> bug fixes, enhancements and performance improvements, I want to
> >>> use them to improve my user's experience. So, each time there is
> >>> a release of Lucene, I get it, test it and if it in itself offers
> >>> an improvement, I release our application just upgrading the
> >>> lucene jar.
> >>>
> >>> OG: Again, there have been a LOT of JVM and JDK improvements
> >>> since 1.4, too, but you are still using 1.4.
> >>>
> >>
> >>
> >> I am using the Java 5 compiler to build a 1.4 compatible binary.
> >> So I  get the compiler improvements for all my users.
> >>
> >>
> >>
> >>> OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago.  1.5 is
> >>> _substantially_ faster.  If you want performance improvements,
> >>> why  not also upgrade Java then?  Ths really bugs me.  People
> >>> want the  latest and greatest Lucene, but are okay with the old
> >>> Java, yet  they claim they want performance, bug fixes, etc.
> >>>
> >>
> >>
> >> It's not up to me. Each user of BibleDesktop has to decide for
> >> themselves. Users of MacOS 10.3 and earlier are stuck using Java
> >> 1.4.  Users that have upgraded to Java 5 get the advantages of
> >> that  runtime. As for me I am running Java 5.
> >>
> >>
> >>
> >>> One can get the performance gains just by using the Java 5 jre.
> >>>
> >>> OG: Correct.  But one can also not get a performance improvement
> >>> or  a bug fix if it comes as part of an external contribution
> >>> that  happens to use 1.5 because the contributor uses 1.5 in his/
> >>> her work  and doesn't have time to "downgrade" the code, just so
> >>> it can be  accepted in Lucene.
> >>>
> >>
> >>
> >> That's the core argument that you are making and it is a good one.
> >> If  it could be designated in Jira whether the attachment were
> >> Java 5  then others (perhaps myself) could take the patch,
> >> downgrade it and  attach it to the same issue. It sure would beat
> >> forking the project.
> >>
> >>
> >>
> >>
> >>> How many external contributions are to the "core" Lucene?
> >>> If the "core" Lucene contribution can be applied and then
> >>> "downgraded" to Java 1.4 easily, what harm is in that?
> >>>
> >>>   OG: I don't know the number, but JIRA would be the place to
> >>> look.  My guess is about a dozen or more people.
> >>> Steve Rowe found something that can "downgrade" 1.5 code to 1.4
> >>> and  looks promising.
> >>>
> >>
> >> If so then perhaps the committers could run the code through it
> >> after  applying the patch. Then the contributers would not be
> >> adversely  affected.
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >>
> >>
> >>
> >
> > --
> >
> > Grant Ingersoll Sr. Software Engineer Center for Natural Language
> > Processing Syracuse University School of Information Studies 335
> > Hinds Hall Syracuse, NY 13244
> > http://www.cnlp.org Voice:  315-443-5484 Fax: 315-443-6886
> >
> > ---------------------------------------------------------------------
> > 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
>
>

------=_Part_6435_19772283.1150915723781--