为什么 Query、TermQuery 等不再在 Lucene 4.0 中实现 Serializable?

2022-01-15 00:00:00 serialization lucene java

我需要使用 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.

相关文章