Re: Version 1.9
i'm willing to help out On 9/13/05, Scott Ganyo <[EMAIL PROTECTED]> wrote: > What is required to make the release? > > On Sep 12, 2005, at 3:39 PM, Erik Hatcher wrote: > > > > > On Sep 12, 2005, at 1:55 PM, Doug Cutting wrote: > > > >> Erik Hatcher wrote: > >> > >> > >>> I'm using the trunk of Subversion (pretty much what 1.9 will be) > >>> on all my projects and it is quite stable. I defer to the > >>> others on when we release it as 1.9 officially, though. > >>> > >>> > >> > >> I think the 1.9 release should be made soon. What is required is > >> a motivated committer with time to lead the process. I won't have > >> time until at least next month. Would someone else like to > >> volunteer to make this release happen? > >> > > > > Among several other things, I'm currently taking a demanding > > University course (every weekday, a couple of hours homework / > > night). I could volunteer to work on a release over Thanksgiving > > or Xmas breaks :) > > > > Erik > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Fwd: Lucene 1.9 release date?
-- Forwarded message -- From: Ray Tsang <[EMAIL PROTECTED]> Date: Oct 15, 2005 11:06 AM Subject: Re: Lucene 1.9 release date? To: java-user@lucene.apache.org Can we add a 1.9 release to the roadmap? or start a 1.9 release tracker issue? ray, On 10/15/05, Erik Hatcher <[EMAIL PROTECTED]> wrote: > Olivier, > > Your best bet it to discuss this on the java-dev list. At this > point, we haven't a firm volunteer for pushing out a release. I'd be > thrilled for someone to step up to the plate. The first thing would > be to go through JIRA and see what issues are open. There are a > number of great contributions that have not been applied. I'd > personally be willing to apply some patches that have been blessed by > Doug or others. > > There is no date set. I realize that some companies become fixated > on having "1.9 FINAL", but there is not really a good reason for such > concern... the only difference, if we built the release now, between > 1.9-dev-rc and 1.9 FINAL is _nothing_. Build what is in > Subversion and run with it :) Report issues if you encounter any. > > Erik > > On Oct 14, 2005, at 10:48 AM, Olivier Jaquemet wrote: > > > Hi all, > > > > Some features we would like to use for our next software revision > > are part of lucene 1.9, in order to know if we can plan to use this > > version, could you tell me when do you think lucene 1.9 stable will > > be released? > > I could not find any roadmap on the lucene site or wiki. > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
Re: Lucene 1.9 release date?
Ah I see it. Should we start assigning and voting for issues that should make it into the 1.9 release? Maybe set a due date for submitting these 1.9-bound issues, a week for voting and review, and then allocate time for applying the patches. I can't wait to see an officially released 1.9! Also, I think Jira can make a distinction between released and unreleased versions? ray, On 10/15/05, Erik Hatcher <[EMAIL PROTECTED]> wrote: > On Oct 14, 2005, at 11:06 PM, Ray Tsang wrote: > > Can we add a 1.9 release to the roadmap? or start a 1.9 release > > tracker issue? > > If you mean the ability to log issues on JIRA for 1.9, I created that > several weeks ago. Let me know if something still isn't right. > > Erik > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
Re: Lucene 1.9 release date?
How about setting some preliminary due dates, so that things don't just hang there. ray, On 10/15/05, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > Re Votes - yes, please use that feature to help prioritize. > > Otis > > --- Ray Tsang <[EMAIL PROTECTED]> wrote: > > > Ah I see it. Should we start assigning and voting for issues that > > should make it into the 1.9 release? Maybe set a due date for > > submitting these 1.9-bound issues, a week for voting and review, and > > then allocate time for applying the patches. I can't wait to see an > > officially released 1.9! > > > > Also, I think Jira can make a distinction between released and > > unreleased versions? > > > > ray, > > > > On 10/15/05, Erik Hatcher <[EMAIL PROTECTED]> wrote: > > > On Oct 14, 2005, at 11:06 PM, Ray Tsang wrote: > > > > Can we add a 1.9 release to the roadmap? or start a 1.9 release > > > > tracker issue? > > > > > > If you mean the ability to log issues on JIRA for 1.9, I created > > that > > > several weeks ago. Let me know if something still isn't right. > > > > > > Erik > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
Re: Lucene 1.9 release date?
Hi All, I think this release issue died out again. I noticed an increase in commit activities recently! I've also noticed the release plan for 2.0 on the wiki. Does current 1.9 already meet the criterias for 2.0? At least API-wise? If so, is it possible to make ways for a release? at least marking the API stable, setting a feature freeze, and make release candidates? Also, I mentioned before about a Tracker bug regarding the 1.9 release. In JIRA, we should mark all other versions as 'released', and move 1.9 up to the front of version list. This way, JIRA will collapse all the other versions and only show open issues related to 1.9 release. Ray, On 10/16/05, Ray Tsang <[EMAIL PROTECTED]> wrote: > How about setting some preliminary due dates, so that things don't > just hang there. > > ray, > > On 10/15/05, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > > Re Votes - yes, please use that feature to help prioritize. > > > > Otis > > > > --- Ray Tsang <[EMAIL PROTECTED]> wrote: > > > > > Ah I see it. Should we start assigning and voting for issues that > > > should make it into the 1.9 release? Maybe set a due date for > > > submitting these 1.9-bound issues, a week for voting and review, and > > > then allocate time for applying the patches. I can't wait to see an > > > officially released 1.9! > > > > > > Also, I think Jira can make a distinction between released and > > > unreleased versions? > > > > > > ray, > > > > > > On 10/15/05, Erik Hatcher <[EMAIL PROTECTED]> wrote: > > > > On Oct 14, 2005, at 11:06 PM, Ray Tsang wrote: > > > > > Can we add a 1.9 release to the roadmap? or start a 1.9 release > > > > > tracker issue? > > > > > > > > If you mean the ability to log issues on JIRA for 1.9, I created > > > that > > > > several weeks ago. Let me know if something still isn't right. > > > > > > > > Erik > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > >
Re: Lucene and Java 1.5
i haven't gone into this thread in detail, but i simply don't see real needs for the source to use 1.5 features anytime soon, or if it's needed at all? as far as i'm concerned is that the existing core is proven to be fast and stable. will changing the source to using 1.5 language features make any difference in that regard? how about making a contrib module that layers on top of the existing core to make low level lucene api's more accessible w/ java 1.5 features? ray, On 5/28/06, karl wettin <[EMAIL PROTECTED]> wrote: On Sat, 2006-05-27 at 16:35 -0700, Andi Vajda wrote: > >>> How about a binary 1.4-target distribution? > >> > > This would preclude use of the 1.5 class library, which contains many > > important new facilities. Repeating my earlier question, why should a > > platform that is 2 years behind for java expect to be at the latest and > > greatest level for lucene? I'd propose 2.0 (+ branched patches) be the > > 1.4 release distribution, with 2.1 free to move up to 1.5. > > I'm not too concerned with the 1.5 class libraries not yet supported by gcj > because, were the Java Lucene core to depend on them, I could patch those in > from other class libraries written in C/C++ or python. > > What worries me the most is the use of new 1.5 language features for which > there are no workarounds other than widespread patches bending APIs (as > opposed to point patches to plug a runtime library hole). I don't know about that argument. It would be to play defect in a prisoner's dilemma that put you in a catch 22 where no new bugs are found since nobody upgrade. In the end there would never be any new JVM. JVM development need their users to move forward just as much as Lucene. I think Hoss got the best suggestion so far. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp
sometimes there is a 2.0.x branch that's like the trunk 2.0 fixes, while 2.1 or future releases are being worked on in the real trunk. that is if older releases are being maintained while new releases are being worked on. ray, On 6/1/06, Doug Cutting <[EMAIL PROTECTED]> wrote: Otis Gospodnetic wrote: > How should 2.0 fixes be handled? Should we fix things in branches/lucene_2_0 and then manually apply the same change to trunk immediately, or are people using svn merge a la http://svnbook.red-bean.com/en/1.0/re16.html ? Generally we should not change things in the branch, but rather continue to develop primarily in trunk, then sync applicable patches to the release branch with 'svn merge' when we're preparing to make a point release, including the revision range merged in the commit message. This makes it much easier to determine which patches have been sync'd to the release branch and which have not. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think the problem right now isn't whether we are going to have 1.5 code or not. We will eventually have to have 1.5 code anyways. But we need a sound plan that will make the transition easy. I believe the transition from 1.4 to 1.5 is not an over night thing. Secondly can we specifically find places where some people _will_ contribute code immediately if it's 1.5 is accepted? Like what I have suggested before, why not have contribution modules that act as a transition into 1.5 code? Much like what other framework has a "tiger" module. This module may have say, a 1.5 compatible layer on top of 1.4 core, or other components of lucene that was made to be extensible, e.g. 1.5 version of QueryParser, Directory, etc. ray, On 6/17/06, Paul Elschot <[EMAIL PROTECTED]> wrote: On Saturday 17 June 2006 01:33, markharw00d wrote: > > That's a long-winded way of saying "-1" unless I hear of any arguments > which are based on something much more substantial than "1.5 makes > coding easier". As for coding convenience from 1.4: last time I had a look there was not a single assert statement in the core code, so I don't think coding convenience is a good argument to move to 1.5 already now. Regards, Paul Elschot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/17/06, Chuck Williams <[EMAIL PROTECTED]> wrote: Ray Tsang wrote on 06/17/2006 06:29 AM: > I think the problem right now isn't whether we are going to have 1.5 > code or not. We will eventually have to have 1.5 code anyways. But > we need a sound plan that will make the transition easy. I believe > the transition from 1.4 to 1.5 is not an over night thing. I disagree. 1.5 was specifically designed to make transition easy, including the inclusion of "non-features" that ensure smooth interoperability (e.g., raw types and no runtime presence whatsoever of generics -- quite different from how it was done in .Net 2.0 for example). But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? > > Secondly can we specifically find places where some people _will_ > contribute code immediately if it's 1.5 is accepted? I already have. That's what started this second round of debate. What is it? Who else? How many? Do we have statistics? We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization), but how about actual numbers potential of contributions between the 2? > > Like what I have suggested before, why not have contribution modules > that act as a transition into 1.5 code? Much like what other > framework has a "tiger" module. This module may have say, a 1.5 > compatible layer on top of 1.4 core, or other components of lucene > that was made to be extensible, e.g. 1.5 version of QueryParser, > Directory, etc. I think this would make it unnecessarily complex. How is it unnecessary or complex? If it only means layering, extending classes, adding implementations, it should be relatively easy with the existing design. It's something we do everyday regardless what lucene's direction takes. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Lastly, how did the commercial application people who use Lucene in their product respond? ray, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/19/06, Steven Rowe <[EMAIL PROTECTED]> wrote: Ray Tsang wrote: > We have statistics of number of users between 1.4 vs. 1.5 (which btw > didn't present a significant polarization) Does 63% for 1.5, a nearly 2:1 ratio, really represent an insignificant polarization? (As of this writing, 88/140 reported using 1.5). What about the rest of the 52 ppl? it's not like thare are only 10 people are going to be left behind. > but how about actual numbers potential of contributions between the 2? Good point -- the survey was announced on the java-user list. Is it not safe to assume that all contributors are subscribed to the java-dev list? The contribution guide <http://wiki.apache.org/jakarta-lucene/HowToContribute> says to subscribe to java-dev as the first step after getting the source. uhm? Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/19/06, Chuck Williams <[EMAIL PROTECTED]> wrote: Ray Tsang wrote on 06/19/2006 09:06 AM: > On 6/17/06, Chuck Williams <[EMAIL PROTECTED]> wrote: >> >> Ray Tsang wrote on 06/17/2006 06:29 AM: >> > I think the problem right now isn't whether we are going to have 1.5 >> > code or not. We will eventually have to have 1.5 code anyways. But >> > we need a sound plan that will make the transition easy. I believe >> > the transition from 1.4 to 1.5 is not an over night thing. >> >> I disagree. 1.5 was specifically designed to make transition easy, >> including the inclusion of "non-features" that ensure smooth >> interoperability (e.g., raw types and no runtime presence whatsoever of >> generics -- quite different from how it was done in .Net 2.0 for >> example). > > But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? If 1.5 features are fully embraced, no. > >> >> > >> > Secondly can we specifically find places where some people _will_ >> > contribute code immediately if it's 1.5 is accepted? >> >> I already have. That's what started this second round of debate. > > What is it? ParallelWriter (see LUCENE-600). I have quite a few more behind that. Whether or not various people will find them useful is tbd, but they are all working well for me and essential to meet my requirements, and some are for things often requested on the various lists (e.g., a general purpose fast bulk index updater that supports arbitrary transformations on the values of fields). That sounds great actually! Would you say it does not necessarily need to go into the core? I would use something like that though. > Who else? How many? Do we have statistics? We have > statistics of number of users between 1.4 vs. 1.5 (which btw didn't > present a significant polarization), but how about actual numbers > potential of contributions between the 2? There has been a proposal to poll java-dev for this. Wagers on the outcome? > >> >> > >> > Like what I have suggested before, why not have contribution modules >> > that act as a transition into 1.5 code? Much like what other >> > framework has a "tiger" module. This module may have say, a 1.5 >> > compatible layer on top of 1.4 core, or other components of lucene >> > that was made to be extensible, e.g. 1.5 version of QueryParser, >> > Directory, etc. >> >> I think this would make it unnecessarily complex. > > How is it unnecessary or complex? If it only means layering, > extending classes, adding implementations, it should be relatively > easy with the existing design. It's something we do everyday > regardless what lucene's direction takes. Contributing to Lucene is a volunteer effort. The more difficult you make it, the fewer people will do it. That's what this is all about. Accept 1.5 contributions and I believe you will get more high quality contributions. Of course, this comes at a high cost for those who cannot transition to 1.5, since they would need to stick with Lucene 2.0.x. Don't get me wrong. My point is _not_ not to accept 1.5 code. By all means we should accept it. But it'll be better if there is a simple way to accept it while at least majority of lucene-core.jar is compatible w/ 1.4 at bytecode level, while, say, lucene-tiger.jar are add ons for full 1.5 specific code that will not be bytecode compatible with 1.4? If I had a vote on this, honestly I'm not sure how I would vote. It's a tough call either way. Do you support a significant minority of users and contributors who are stuck on an old java platform, or do you strike forward with a more robust contributing community from the majority at the cost of cutting out the minority from the latest and greatest? My first comment on this topic was something like, "why would somebody who is on an old java platform expect to have the latest and greatest lucene?". I think if I was stuck on 1.4, I wouldn't be happy about a 1.5 decision for lucene 2.1+, but I would understand it, accept it, and do whatever I could to speed my transition to 1.5. I would agree, but i'm sure there can be compromises. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/19/06, Robert Engels <[EMAIL PROTECTED]> wrote: Why not just make 2.1 use 1.5, and if there are enough 1.4 people they can back-port the changes into 2.0 using JDK 1.4 only code? If they decide it is too much work, they can move forward to JDK 1.5, stick with Lucene 2.0 release X, or find another search project. I like this idea also. However it will introduce a new branch (think Linux). But it can definiltey work. And I assume that eventually when the 1.4 supporters move on to 1.5, the 1.4 branch will die off naturally. Although I agree with Doug that Lucene is a "library" and there are different factors that control the dependencies, JDK 1.5 is also no where near bleeding edge, with several years of stable deployment on many platforms, and no one is stating that Lucene will not work on those platforms, just not Lucene 2.1. It is like trying to support COM on MS-DOS - it just didn't happen (as far as I know). It was possible, but just wasn't worth the effort. If Lucene 2.1 encourages other companies that provide JREs to move to support 1.5 that is even better. -Original Message- From: Ray Tsang [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 11:06 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On 6/17/06, Chuck Williams <[EMAIL PROTECTED]> wrote: > > Ray Tsang wrote on 06/17/2006 06:29 AM: > > I think the problem right now isn't whether we are going to have 1.5 > > code or not. We will eventually have to have 1.5 code anyways. But > > we need a sound plan that will make the transition easy. I believe > > the transition from 1.4 to 1.5 is not an over night thing. > > I disagree. 1.5 was specifically designed to make transition easy, > including the inclusion of "non-features" that ensure smooth > interoperability (e.g., raw types and no runtime presence whatsoever > of generics -- quite different from how it was done in .Net 2.0 for example). But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? > > > > > Secondly can we specifically find places where some people _will_ > > contribute code immediately if it's 1.5 is accepted? > > I already have. That's what started this second round of debate. What is it? Who else? How many? Do we have statistics? We have statistics of number of users between 1.4 vs. 1.5 (which btw didn't present a significant polarization), but how about actual numbers potential of contributions between the 2? > > > > > Like what I have suggested before, why not have contribution modules > > that act as a transition into 1.5 code? Much like what other > > framework has a "tiger" module. This module may have say, a 1.5 > > compatible layer on top of 1.4 core, or other components of lucene > > that was made to be extensible, e.g. 1.5 version of QueryParser, > > Directory, etc. > > I think this would make it unnecessarily complex. How is it unnecessary or complex? If it only means layering, extending classes, adding implementations, it should be relatively easy with the existing design. It's something we do everyday regardless what lucene's direction takes. > > Chuck > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Lastly, how did the commercial application people who use Lucene in their product respond? ray, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think retrotranslator only work on the syntax, but not on the 1.5 specific libraries (for obvious reasons). A real use case was written up by a Java 5 web mvc framework at http://stripes.mc4j.org/confluence/display/stripes/Java+1.4+and+Stripes Once again, so long we stay away from non-1.4 compatible language features of 1.5, we can always compile to 1.4 code anyways. I don't know exactly what everyone is saying that makes it convinient for them to develop in 1.5. But I believe majority of it are in basic syntax improvements of 1.5 which are (should) fully compatible to be compiled into 1.4 bytecode (although i could see a use of the concurrent package?) Looking at hibernate and spring, do we see them rushing into 1.5? They do have great support for users using both 1.4 and 1.5. Surely it's on a different scale, different user base, and different type of libraries. But the point is they have a good compromise between the 2, and there is no branching, but incremental versions that adds 1.5 extensions on top of what they already have. I think to avoid branching, it can come down to what 1.5 language features are we willing to accept in the core, and anything-goes in the contributions. We do realize that not every feature needs to be in the core, right? ray, On 6/20/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: On 6/20/06, Steven Rowe <[EMAIL PROTECTED]> wrote: > Could not tools like Retrotranslator[2] or Retroweaver[3] be used to > satisfy both camps? That's an interesting option Steven... Retrotranslator certainly looks like they handle almost everything! If we ended up taking that route, we have enough 1.4 users that I think it would be nice to have - a 1.4 compatible jar included in the distributions along with the 1.5 jar - an easy way to run all the unit tests against the 1.4 compatible jar -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I agree. This is probably the first compelling argument that I would agree with the use of 1.5. IIRC, Concurrent utils were available for the 1.4 available at http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html before it was accepted into official 1.5 util package. It is continuing to be maintained right now. I'm also supportive about Doug's base-guideline. As far as annotation goes, I really don't see future uses of annotations within the internal code. It would most likley end up being used by the user to annotate a POJO for as a document maybe. ray, On 6/22/06, Simon Willnauer <[EMAIL PROTECTED]> wrote: On 6/22/06, DM Smith <[EMAIL PROTECTED]> wrote: > On 6/22/06, Doug Cutting <[EMAIL PROTECTED]> wrote: > > > > DM Smith wrote: > > > In an earlier note, I suggested that there needs to be guidance as to > > how > > > Java 5 constructs are to be incorporated into code, contrib and core. > > > (Sooner or later, core will change to Java 5) Or does anything go? > > > > Once we decide to accept Java 5 code, we should of course encourage new > > contributions to use new language features that improve, e.g., type > > safety and maintainability. If someone wishes to upgrade existing code > > to use new language features, these should be done as separate > > contributions. > > > > We could state a goal of upgrading all existing code, but that won't > > make it happen. I prefer not to make ambitious roadmaps, but rather > > have things driven bottom-up, by contributors. So my bottom-up-oriented > > guideline is that I would not reject contributions that do nothing but > > upgrade existing code to use new language features. > > > > Is that the sort of guidance you seek, or do you think we need something > > more specific, with feature-by-feature guidelines? Developing such > > guidelines collaboratively might be difficult. > > > > > One of the things I liked about 2.0 was that 1.9 was a bridge to it from > 1.4.3 via deprecations. It made migration fairly straightforward. I would > like to see this going forward to 2.1. If so there needs to be some thought > to how and whether the existing API will be deprecated in the same fashion > as Java 5 is introduced. > > I was thinking more specific, feature-by-feature guidelines. There are not > that many new language features, so I don't think that it would be too > onerous. Since the committers are ultimately the ones to accept or reject a > contribution, I think they can decide. > > For example (my opinions), > > Static Import > Try to avoid. It tends to make code unreadable. > > Autoboxing/unboxing > Use sparingly, and if used, provide test cases showing that performance > sensitive code is not adversely affected. > > Varargs > Don't use as a substitute for overloading. > Use as a replacement for an array of objects. e.g. void f(T[] t) becomes > void f(T... t). > > Enhanced for loops: > Use whenever possible. > When modifying existing code to add one, change all others, if possible. > > Typesafe Enum > Use wherever possible, internally. > Associate behavior with the enumerations when it makes sense. > Replace existing enumerations that are exposed via the API cautiously, > maintaining compatibility with 2.0 as was done with 1.9's deprecations. > > Generics > Use for all internal collections. > When changing a class, ensure that the class is self consistent in its > usage of generics. > Enhance existing collections that are exposed via the API cautiously, > maintaining compatibility with 2.0 as was done with 1.9's deprecations. > > Annotations: > ?? > > I assume that many people realize these features as new features in Java 5.0. In my opinion there is at least one more feature beside the improvements inside the jvm and the garbage collection and build in Java Management Extension. The feature I'm pointing to is rather a new library than a feature to be honest but it can improve concurrent application in performance and stability matters. The Concurrent Utils in the j2se 5.0 give you much more control of concurrent parts of you application and I guess the lucene project can gain from these new classes to synchronize writing and parallel reading where possible. I think a great deal of adding build in JMX support to the lucene core or rather as a contrib project to enable modification of configurable components like merge factors or similar things. Extensions like this should have some guidelines as Doug said feature-by-feature. Java 1.5 is much more than type save collection and a lot of "features" are quiet hidden sometimes. Replacing the use of StringBuffer with StringBuilder can also gain some performance improvements, this just as an example that improved parts of the api are quiet important and should be considered first before moving in all the "nice" compile time code sharing generics. regards Simon - To
