[
https://issues.apache.org/jira/browse/LUCENE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778875#action_12778875
]
Marvin Humphrey commented on LUCENE-2073:
-----------------------------------------
Which components are affected by this? I think just Analyzers and query
parsers, yes?
If that's true, my inclination would be to add a note to the javadocs for each
such class. In every case, it's theoretically possible to build alternative
implementations which are unaffected by upgrading the JVM.
This isn't a fundamental problem with the Lucene architecture; it's an
artifact of the way certain classes are implemented. Outside of the affected
components, Lucene doesn't get down and dirty with Unicode properties and
other fast-moving stuff -- it's just dealing in UTF-8 bytes, Java strings,
etc. Those things can change (Modified UTF-8, shudder), but they move on a
slower timescale.
Arguably, Analyzer subclasses shouldn't be in core for reasons like this.
Perhaps there could be an "ICUAnalysis" package which depends on ICU4J, so
that Unicode-related index incompatibilites occur when you upgrade your
Unicode library. Though most people would probably choose to use the
smaller-footprint, zero-dependency "JVMAnalysis" package, where reindexing
would be required after a JVM upgrade.
The software certifiers wouldn't like that, and I'm not seriously advocating
such a disruptive change (yet), but I just wanted to illustrate that this is a
contained problem.
> Document issues involved in building your index with one jdk version and then
> searching/updating with another
> -------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2073
> URL: https://issues.apache.org/jira/browse/LUCENE-2073
> Project: Lucene - Java
> Issue Type: Task
> Reporter: Mark Miller
>
> I think this needs to go in something of a permenant spot - this isn't a one
> time release type issues - its going to present over multiple release.
> {quote}
> If there is nothing we can do here, then we just have to do the best we can -
> such as a prominent notice alerting that if you transition JVM's between
> building and searching the index and you are using or doing X, things will
> break.
> We should put this in a spot that is always pretty visible - perhaps even a
> new readme file titlted something like IndexBackwardCompatibility or
> something, to which we can add other tips and gotchyas as they come up. Or
> MaintainingIndicesAcrossVersions, or
> FancyWhateverGetsYourAttentionAboutUpgradingStuff. Or a permanent
> entry/sticky entry at the top of Changes.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
