为什么 Query、TermQuery 等不再在 Lucene 4.0 中实现 Serializable?
我需要使用 EJB 通过网络发送一个包含诸如 Query 之类的 Lucene 元素的类，当然这个类需要被序列化.我将我的课程标记为 Serializable 但似乎还不够:
I need to send a class containing Lucene elements such as Query over the network using EJB and of course this class need to be serialized. I marked my class as Serializable but it does not seems to be enough:
org.apache.lucene.search.TermQuery is not Serializable
确实，当我阅读 Lucene (4.0) 的最后一个稳定版本的 javadoc 时，我可以看到 TermQuery 没有实现 Serializable，Query 也没有.我不明白的是为什么这些类在上一个版本(3.6.1)中用于实现 Serializable ，为什么现在不再这样了?
Indeed, when i read the javadoc of the last stable release of Lucene (4.0), i can see that TermQuery does not implement Serializable, Query neither. What i don't understand is why those classes used to implement Serializable in the last release (3.6.1), and why it's no longer the case?
推荐答案
Mike McCandless，Lucene 贡献者之一 以及 Lucene 4 变更日志说:
Mike McCandless, one of Lucene contributors as well as Lucene 4 changelog say:
所有序列化代码已从 Lucene 的类中删除；你必须在您的应用程序中处理更高级别的序列化.
All serialization code has been removed from Lucene's classes; you must handle serialization at a higher level in your application.
实际提交是针对 JIRA 问题 LUCENE-2908 和 LUCENE-4037.前一期的描述说:
The actual commits were done against JIRA issues LUCENE-2908 and LUCENE-4037. The description of the former issue says:
我们删除了 contrib/remote，但忘记清理序列化地狱到处.这不再需要，从未真正起作用(例如跨越版本)，并减慢开发速度(例如，我浪费了很长时间的调试尝试制作时的 Similarity.idfExplain 的愚蠢序列化评分系统的补丁).
We removed contrib/remote, but forgot to cleanup serialization hell everywhere. this is no longer needed, never really worked (e.g. across versions), and slows development (e.g. i wasted a long time debugging stupid serialization of Similarity.idfExplain when trying to make a patch for the scoring system).
Lucene 并不是唯一一个考虑放弃序列化的人.例如，guava 也考虑过这一点.
Lucene is not alone thinking about throwing away serialization. For example, guava considered this, too.
谈到您的问题 - 您应该能够始终将您的查询转换为字符串表示形式(使用 .toString())并返回.除非您每秒执行这一百万次，否则开销应该可以忽略不计.
Speaking about your problem - you should be able to always convert your query to a String representation (using .toString()) and back. Unless you do this million times a second, the overhead should be negligible.
相关文章