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 daniel.armbrust.list@gmail.com
 designates 64.233.166.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=WBXjMTSZNA5j7vfIhKqeoobBeAR7YPvmBFy39T6IGrwsipR5M3Aqfb6BupuW9Cd2Bym+lcbPNqGLz8tLuq3rdNc2Gxtxa7/FdDQwx3asfvJIaaPtRVnberQUnQmK+wTnk5ErZpsi9DAx9+3D13qY8lh5ExdlyBFa1KlSrT54+Tg=
Message-ID: <4497FB3C.5090207@gmail.com>
Date: Tue, 20 Jun 2006 08:42:20 -0500
From: Dan Armbrust <daniel.armbrust.list@gmail.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
References: <E1FsUPS-0004YI-Bn@elasmtp-junco.atl.sa.earthlink.net>
In-Reply-To: <E1FsUPS-0004YI-Bn@elasmtp-junco.atl.sa.earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Robert Engels wrote:

> 
> People making these arguments against 1.5 sound really ill-informed, or
> lazy. Neither of which is good for open-source development.
> 

Preface - I'm not a lucene developer - just an interested user.

I don't know - it seems to me that it is the 1.5 crowd that is making 
the lazy argument.  You are in effect, saying, that the highly skilled 
developers who would be making lucene contributions are unable or 
unwilling to write 1.4 java code?  Come on... it really not that hard. 
Which set is being lazy?  I'll stop the name calling now, and try to 
make a better point.

I have some applications that I have written in 1.5 - and yes - it is 
nice.  But I also have other applications (that use Lucene) that are 
written to be 1.4 compatible.  And they need to stay that way for quite 
some time to come.  Why?  Many reasons.  The first - because they 
implement an official HL7 specification - and the specification says 
that the implementation needs to support Java 1.4.

Also, at my place of employment we have about 40,000 desktop computers 
that are all centrally managed - down to every point release of every 
single piece of software.  There are multiple applications using java 
that are installed on these machines.  Each application has to be 
certified and fully tested with a newer version of java before a newer 
version of java can be installed.  As you can imagine, that severely 
hampers the pace of java updates.  We are just getting 1.4 installed on 
these machines now.  When you are managing that many machines in a 
clinical environment - you have to play it safe.  There are no upgrades 
for an upgrades sake, or for syntactic sugar.  There has to be a real 
problem to even get the process started.  I'm sure many other people 
have similar situations.

Also - I don't know much about the Java mobile platform - but I thought 
I had read before that they are limited to the 1.3 or 1.4 feature set? 
If this is true, do we really want to remove an entire ecosystem of 
potential users?  Over syntactic sugar?

While I'm not completely opposed to the argument that I should just have 
to stay with the Lucene 2.0.x release with applications that need to run 
in 1.4 environments - Lucene is an integral part of that code.  If 
performance improvements are made to the core, I want those in my code. 
  If bugs are found and fixed - I want those fixes too.  As a matter of 
fact - until the 2.0 release, I was using a build from the trunk because 
of a bug that I found in Lucene, (and someone else was gracious enough 
to fix for me).  Lucene is a low level library that is used to build 
many great applications.  If you make the jump to 1.5 today - you are 
going to be leaving people behind.  And judging by the poll, you are 
going to be leaving a fairly significant number of people behind. 
Lucene has great policy on not breaking backwards compatibility in their 
API - why should this be looked at any differently?

 > Rather than having the 1.5 developers having to waste their time
 > "thinking" in 1.4 when their work is predominately being performed
 > using 1.5 features/compilers/tools.


I don't think that the caliber of developers that are working on the 
Lucene core are going to be slowed down any by using 1.4 syntax over 
1.5.  (It actually takes longer to type in all of those generics :)  All 
of my tools - Eclipse and Java 1.5 - have a check box that will cause 
them to generate 1.4 compatible code.  Its really _not_ a big deal to 
write 1.4 code even if you are used to 1.5.  This particular argument 
just isn't compelling to me.


My personal opinion for the path that Lucene should take:

Core bugs fixes must be 1.4 compatible.
Core improvements must be 1.4 compatible.
Contrib / sandbox can be 1.5 or 1.6.

Of course, at some point - Lucene Core does need to advance.  But I 
don't just don't feel that syntactic sugar in 1.5 is enough of a reason 
to break backwards compatibility.  I haven't followed 1.6 - I don't know 
what the new features are there.  Assuming that there are great new 
features in 1.6 - that would improve the lucene core if they were used - 
  I think that that is when this issue gets revisited.

This isn't the type of question that should be decided by a poll.  This 
should be decided by thoughtfully looking at the consequences of each 
choice.  For me - the negative consequences of choosing 1.5 - leaving 
behind a lot of users - is much worse than the negative consequences of 
staying at 1.4 - making a couple dozen highly skilled developers check 
an extra box in their lucene development environments?

If any developers have actually read this far (sorry - it got kind of 
long) - thanks again for all of your great work - Lucene is a great tool 
- and a great community.

Dan

-- 
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/

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