Sanne, I would recommend you building a Factory pattern around you Analyzers / TokenStreams similar to what solr does. That way you can load you own "default ctor" interface via reflection and obtain you analyzers from those factories. That makes more sense anyway as you only load the factory via reflection an not the analyzers.
@Robert: I don't know if removing LUCENE_CURRENT is the way to go. On the one hand it would make our live easier over time but would make it harder for our users to upgrade. I would totally agree that for upgrade safety it would be much better to enforce an explicit version number so upgrading can be done step by step. Yet, if we deprecate LUCENE_CURRENT people will use it for at least the next 3 to 5 years (until 4.0) anyway :) simon On Sun, Feb 7, 2010 at 8:17 PM, Sanne Grinovero <sanne.grinov...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
