lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Date Tue, 20 Jun 2006 16:33:39 GMT
Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for
my lines.

----- Original Message ----
From: Dan Armbrust <daniel.armbrust.list@gmail.com>
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.

OG: I think you are missing or misinterpreting things here.  Lucene contributors tend to be
people who write nice extensions to Lucene, and want to give them back to Lucene.  Typically
those extensions come out of their day jobs, or at least that is my impression.  When they
use 1.5 there, their contribution will be 1.5.  External contributors already spend extra
time and effort to do this.  Requiring them to modify their code not to use 1.5 would mean
they will be less likely to contribute.  I wouldn't bother, if I had to take extra time and
effort to contribute, and even "go backwards" with my code, when what I really want is for
my piece of code to become a part of Lucene, so I can just use that code instead of maintaining
my own variation of it.

OG: My main concern is losing those contributions.  We already have a TON of good patches
in JIRA that we didn't integrate, and lots of them are lost, because patches no longer apply.
 I hate treating kind contributors like that.  I feel ungrateful.

OG: So, instead of only thinking how if Lucene 2.1 goes the 1.5 route you won't be able to
use the latest and greatest, one can also think about losing the latest and greatest contributions
because they are written with 1.5 in mind.  And this is not a loss only to those who are already
on 1.5.  This is a loss for _everyone_ in the long run.  Those running 1.4 now, will be running
1.5 one day, but they won't be getting Lucene with contributions that were rejected, because
in the second half of 2006 we were forced to reject all 1.5 contributions.

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. 

OG: Exactly.  There will ALWAYS be people who have to stay with 1.4 or older Java.  At some
point you have to decide not support the older versions, just like at some point we decided
to stop supporting 1.3.

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.

OG: Again, exactly.  If this is an environment where upgrades are very carefully planned and
thus probably rare, why does this environment care SO much to have the cutting edge Lucene,
when at the same time they are ok with a old version of Java?

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?

OG: It is NOT syntactic sugar only.  This is FUD! :)  Really.  I just found a bug in my code
that was hidden for several weeks because I was using a List instead of List<String>,
for instance!  Also, this "entire ecosystem of potential users" seems a bit exaggerated. :)
 They certainly didn't seem to take part in that survey.  I think J2ME on mobile devices might
even be 1.2 Java, not sure.

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).  

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.

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

OG: That is always going to be the case.  I _think_ the question is how many people.
 
going to be leaving a fairly significant number of people behind. 

OG: "fairly significant number" is quite subjective.  The ratio of 1.5 vs. 1.4 users is currently
a little over 2:1.  My guess is that in 2-3 months it will be closer to 3:1.  Lucene 2.1 won't
be released for another 6 months (2007), I am willing to bet, and yet we are considering rejecting
1.5 contributions now, in June 2006.

Lucene has great policy on not breaking backwards compatibility in their 
API - why should this be looked at any differently?

OG: Lucene 2.0 API is not compatible with 1.4.3 API.  It is the same situation.  We deprecated
some API calls and then we removed them.  Those who want Lucene 2.0.0 had to update their
code to use the new API, otherwise their code would not compile.

 > 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.

OG: Please read what I wrote all the way up.  In my mind, it is not so much about core Lucene
developers, as it is about external contributions.  Core developer will know what we agreed
on and will write the code to suit our agreement.  External contributor will contribute code
she/he wrote for work.  As the poll shows, more people use 1.5 at work, thus...

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 

OG: Again, it's not about syntactic sugar.  This is FUD.

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 

OG: The poll was about "what do you use", and not "what version of Java should Lucene support".
 I hope this wasn't misinterpreted by those who took the poll.

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?

OG: I don't think the checkbox will remove 1.5-style for loops or generics and other stuff
if that is already in the code.

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.

OG: Thanks Dan, and please don't take my email(s) wrong.  I'm quite clear-headed in this issue,
and am trying to be objective.  I personally wouldn't get hurt if we stayed with 1.4, I'd
just be feeling bad and guilty if we had to reject contributions that have 1.5 bits in it.

OG: How about this.  I noticed th "significant number of people left behind" statement in
a few people's arguments.  How small of a percentage of 1.4 users do you think we should look
for before we can ove to 1.5?  What does the 1.5:1.4 ration need to be?
This is not a question for Dan only. I would really be interested what others think about
this.  How small does the percentage of 1.4 users need to be, before we can have 1.5 in Lucene?

Thanks,
Otis





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


Mime
View raw message