Thanks for all the quick answers; finding the ctor having only a Version parameter is fine for me, I had noticed this "frequent pattern" but didn't understand that was a general rule. So can I assume this is an implicit contract for all Analyzers, to have either an empty ctor or a single-parameter of type Version?
I know about the dangers of using LUCENE_CURRENT, but rebuilding the index is not always something you need to avoid. Having LUCENE_CURRENT is for example useful for me to test Hibernate Search towards the current Lucene on classpath, without having to rebuild the code. thanks for all help, Sanne 2010/2/7 Robert Muir <rcm...@gmail.com>: > I propose we remove LUCENE_CURRENT completely, as soon as TEST_VERSION is > done. > > On Sun, Feb 7, 2010 at 12:53 PM, Uwe Schindler <u...@thetaphi.de> wrote: >> >> Hi Sanne, >> >> Exactly that usage we want to prevent. Using Version.LUCENE_CURRENT is the >> badest thing you can do if you want to later update your Lucene version and >> do not want to reindex all your indexes (see javadocs). >> >> It is easy to modify your application to create analyzers even from config >> files using the reflection way. Just find a constructor taking Version and >> call newInstance() on it, not directly on the Class. It's just one line of >> code more. >> >> Uwe >> >> ----- >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> > -----Original Message----- >> > From: Sanne Grinovero [mailto:sanne.grinov...@gmail.com] >> > Sent: Sunday, February 07, 2010 6:33 PM >> > To: java-dev@lucene.apache.org >> > Subject: Having a default constructor in Analyzers >> > >> > Hello, >> > I've seen that some core Analyzers are now missing a default >> > constructor; this is preventing many applications to configure/load >> > Analyzers by reflection, which is a common use case to have Analyzers >> > chosen in configuration files. >> > >> > Would it be possible to add, for example, a constructor like >> > >> > public StandardAnalyzer() { >> > this(Version.LUCENE_CURRENT); >> > } >> > >> > ? >> > >> > Of course more advanced use cases would need to pass parameters but >> > please make the advanced usage optional; I have now seen more than a >> > single project break because of this (and revert to older Lucene). >> > >> > Regards, >> > Sanne >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> > > > > -- > Robert Muir > rcm...@gmail.com > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
