[
https://issues.apache.org/jira/browse/LUCENE-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425698#comment-13425698
]
Shai Erera commented on LUCENE-4276:
------------------------------------
I didn't follow the email thread closely, but I don't want to see my JVM
version on the list, if there's some use case that may lead to index
corruption. What if I never step on that use case?
I'm just worried that such change would mean in the future preventing to run
Lucene and a JVM that e.g. fails to properly detect the Codecs to use (i.e.
ServiceLoader bug in IBM J9, which was fixed recently).
So as long as this is a list of specific JVM versions, that are known to cause
index corruption, and not other runtime bugs (locale issues, ServiceLoader and
such), and as long as this list is controlled by a file that can be edited by
the app, I'm ok.
But if we're making all this trouble (file etc.), why fail to run? we can print
a message to System.err -- let the app choose.
Preventing Lucene from running on certain JVMs is too extreme IMO.
In general, I wish we'd be less extreme in our changes in Lucene code, but
that's a matter for a separate discussion.
> refuse to execute on broken corrupting jvms
> -------------------------------------------
>
> Key: LUCENE-4276
> URL: https://issues.apache.org/jira/browse/LUCENE-4276
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Robert Muir
>
> There are some jvms where we know lucene does not work at all and will just
> produce things like corrupt indexes.
> We should detect this in a static block of Constants.java and refuse to run
> at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
