反向索引：

说明见Similarity.java的javadoc信息：


算法请参考javadoc的，它使用的是Vector Space Model (VSM) of Information Retrieval。

       ------------------------------------
        Store.COMPRESS  Store the original field value in the index in a compressed form. This is useful for long documents and for binary valued fields.压缩存储；
        Store.YES Store the original field value in the index. This is useful for short texts like a document's title which should be displayed with the results. The value is stored in its original form, i.e. no analyzer is used before it is stored. 索引文件本来只存储索引数据, 此设计将原文内容直接也存储在索引文件中，如文档的标题。
        Store.NO  Do not store the field value in the index. 原文不存储在索引文件中，搜索结果命中后，再根据其他附加属性如文件的Path，数据库的主键等，重新连接打开原文，适合原文内容较大的情况。
        决定了Field对象的 this.isStored 和        this.isCompressed
     ------------------------------------
        Index.NO Do not index the field value. This field can thus not be searched, but one can still access its contents provided it is Field.Store stored. 不进行索引，存放不能被搜索的内容如文档的一些附加属性如文档类型, URL等。
        Index.TOKENIZED Index the field's value so it can be searched. An Analyzer will be used to tokenize and possibly further normalize the text before its terms will be stored in the index. This is useful for common text. 分词索引
        Index.UN_TOKENIZED  Index the field's value without using an Analyzer, so it can be searched. As no analyzer is used the value will be stored as a single term. This is useful for unique Ids like product numbers. 不分词进行索引，如作者名，日期等，Rod Johnson本身为一单词，不再需要分词。

        Index.NO_NORMS 不分词，建索引。norms是什么???字段值???。但是Field的值不像通常那样被保存，而是只取一个byte，这样节约存储空间???? Index the field's value without an Analyzer, and disable the storing of norms.  No norms means that index-time boosting and field length normalization will be disabled.  The benefit is less memory usage as norms take up one byte per indexed field for every document in the index.Note that once you index a given field <i>with</i> norms enabled, disabling norms will have no effect.  In other words, for NO_NORMS to have the above described effect on a field, all instances of that field must be indexed with NO_NORMS from the beginning.
        决定了Field对象的 this.isIndexed  this.isTokenized  this.omitNorms
     ------------------------------------
        Lucene 1.4.3新增的：
        TermVector.NO Do not store term vectors.  不保存term vectors
        TermVector.YES Store the term vectors of each document. A term vector is a list of the document's terms and their number of occurences in that document. 保存term vectors。
        TermVector.WITH_POSITIONS Store the term vector + token position information 保存term vectors。（保存值和token位置信息）
        TermVector.WITH_OFFSETS Store the term vector + Token offset information
        TermVector.WITH_POSITIONS_OFFSETS Store the term vector + Token position and offset information 保存term vectors。（保存值和Token的offset）
        决定了Field对象的this.storeTermVector this.storePositionWithTermVector this.storeOffsetWithTermVector

Closure: http://en.wikipedia.org/wiki/Closure_%28computer_science%29
我还比较喜欢Microsoft的一段说明，位于链接http://msdn.microsoft.com/msdnmag/issues/07/09/BasicInstincts/Default.aspx?loc=zh中，查找“Lambda 表达式和变量提升”

最早接触Closure是在学javascript, 前年还写了篇关于Closure对javascript内存泄露的文章http://www.blogjava.net/tim-wu/archive/2006/05/29/48729.html
一直以为这就是函数式语言的特性，顶多就是.net的委托和它有几分相识，
没想到现在Java7也要支持了，有兴趣的朋友可以去读读：
http://www.javac.info/
没细读，不知道Lambda在Java这种强类型检查的语言中表现的如何。

作为函数语言，Ruby中一直都有closure的用法，http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby有个简单例子。

def foo
  f = Proc.new { return "return from foo from inside proc" }
  f.call # control leaves foo here
  return "return from foo" 
end

def bar
  f = lambda { return "return from lambda" }
  f.call # control does not leave bar here
  return "return from bar" 
end

puts foo # prints "return from foo from inside proc" 
puts bar # prints "return from bar"

 最近，ruby 1.9又提供了新的定义lambda

x = ->{puts "Hello Lambda"} 

以下内容均为转载,url见具体链接:

最常见的四个Analyzer,说明:  http://windshowzbf.bokee.com/3016397.html 
WhitespaceAnalyzer  仅仅是去除空格，对字符没有lowcase化,不支持中文
SimpleAnalyzer :功能强于WhitespaceAnalyzer,将除去letter之外的符号全部过滤掉,并且将所有的字符lowcase化,不支持中文
StopAnalyzer: StopAnalyzer的功能超越了SimpleAnalyzer，在SimpleAnalyzer的基础上.增加了去除StopWords的功能,不支持中文.类中使用一个static数组保存了ENGLISH_STOP_WORDS, 太常见不index的words
StandardAnalyzer: 用Javacc定义的一套EBNF，严禁的语法。有人说英文的处理能力同于StopAnalyzer.支持中文采用的方法为单字切分。未仔细比较，不敢确定。

其他的扩展:
ChineseAnalyzer:来自于Lucene的sand box.性能类似于StandardAnalyzer,缺点是不支持中英文混和分词.
CJKAnalyzer:chedong写的CJKAnalyzer的功能在英文处理上的功能和StandardAnalyzer相同.但是在汉语的分词上，不能过滤掉标点符号，即使用二元切分
TjuChineseAnalyzer: http://windshowzbf.bokee.com/3016397.html写的,功能最为强大.TjuChineseAnlyzer的功能相当强大,在中文分词方面由于其调用的为ICTCLAS的java接口.所以其在中文方面性能上同与ICTCLAS.其在英文分词上采用了Lucene的StopAnalyzer,可以去除 stopWords,而且可以不区分大小写,过滤掉各类标点符号.

例子:
http://www.langtech.org.cn/index.php/uid-5080-action-viewspace-itemid-68, 还有简单的代码分析

Analyzing "The quick brown fox jumped over the lazy dogs"

WhitespaceAnalyzer:

[The] [quick] [brown] [fox] [jumped] [over] [the] [lazy] [dogs]

SimpleAnalyzer:

[the] [quick] [brown] [fox] [jumped] [over] [the] [lazy] [dogs]

StopAnalyzer:

[quick] [brown] [fox] [jumped] [over] [lazy] [dogs]

StandardAnalyzer:

[quick] [brown] [fox] [jumped] [over] [lazy] [dogs]

Analyzing "XY&Z Corporation - xyz@example.com"

WhitespaceAnalyzer:

[XY&Z] [Corporation] [-] [xyz@example.com]

SimpleAnalyzer:

[xy] [z] [corporation] [xyz] [example] [com]

StopAnalyzer:

[xy] [z] [corporation] [xyz] [example] [com]

StandardAnalyzer:

[xy&z] [corporation] [xyz@example.com]

参考连接:
http://macrochen.blogdriver.com/macrochen/1167942.html
http://macrochen.blogdriver.com/macrochen/1153507.html

http://my.dmresearch.net/bbs/viewthread.php?tid=8318
http://windshowzbf.bokee.com/3016397.html

推荐
http://gceclub.sun.com.cn/developer/technicalArticles/Intl/Supplementary/index_zh_CN.html
http://www.linuxpk.com/3821.html
=======================================
BMP的解释：
http://zh.wikipedia.org/w/index.php?title=%E5%9F%BA%E6%9C%AC%E5%A4%9A%E6%96%87%E7%A8%AE%E5%B9%B3%E9%9D%A2&variant=zh-cn
http://zh.wikipedia.org/w/index.php?title=%E8%BE%85%E5%8A%A9%E5%B9%B3%E9%9D%A2&variant=zh-cn#.E7.AC.AC.E4.B8.80.E8.BC.94.E5.8A.A9.E5.B9.B3.E9.9D.A2
1个BMP和16个辅助plane，需要21个bits.

======================================
ISO-10646与Unicode关系
http://zh.wikipedia.org/wiki/%E9%80%9A%E7%94%A8%E5%AD%97%E7%AC%A6%E9%9B%86

ISO-10646术语	Unicode术语
UCS-2	BMP UTF-16
UCS-4	UTF-32

注意：UTF-16可看成是UCS-2的父集。在沒有辅助平面字符前，UTF-16與UCS-2所指的是同一的意思。但當引入辅助平面字符後，就只稱為UTF-16了，因为我们会使用2个UTF-16，也就似乎4bytes保存一个辅助平面字符。現在若有軟件聲稱自己支援UCS-2編碼，那其實是暗指它不能支援辅助平面字符的委婉語。
======================================
UTF-8要完整表达unicode需要4bytes，表达BMP需要3bytes，见http://en.wikipedia.org/wiki/UTF-8，注意“The range D800-DFFF is disallowed by Unicode. The encoding scheme reliably transforms values in that range, but they are not valid scalar values in Unicode. See Table 3-7 in the Unicode 5.0 standard. ”

另：
Java 1.0 supports Unicode version 1.1.
Java 1.1 onwards supports Unicode version 2.0.
J2SE 1.4中的字符处理是基于Unicode 3.0标准的。
J2SE v 1.5 supports Unicode 4.0 character set.

而：
Unicode 3.0：1999年九月；涵蓋了來自ISO 10646-1的十六位元通用字元集（UCS）基本多文種平面（Basic Multilingual Plane）

Unicode 3.1：2001年三月；新增從ISO 10646-2定義的輔助平面（Supplementary Planes)

在大约 1993 年之后开发的大多数现代编程语言都有一个特别的数据类型, 叫做 Unicode/ISO 10646-1 字符. 在 Ada95 中叫 Wide_Character, 在 Java 中叫 char.

ISO C 也详细说明了处理多字节编码和宽字符 (wide characters) 的机制, 1994 年 9 月 Amendment 1 to ISO C 发表时又加入了更多. 这些机制主要是为各类东亚编码而设计的, 它们比处理 UCS 所需的要健壮得多. UTF-8 是 ISO C 标准调用多字节字符串的编码的一个例子, wchar_t 类型可以用来存放 Unicode 字符.

代码为QueryParser.jj，语法为JavaCC实现的LL()：
完整文档：http://lucene.apache.org/java/2_0_0/queryparsersyntax.html

和正则一样：
?表示0个或1个
+表示一个或多个
*表示0个或多个


以下是Token部分：

以下为解析部分

btw: 猜测: javacc中,如果使用[],则允许出现0次或1次

今天读了lucent中的PriorityQueue.java, 一个很巧妙的复杂度为log(n)的排序堆栈.

始终确保数组A[1...n]中:
A[i]<A[2*i]  & A[i] < A[2*i +1]
很容易推论出A[1]一定是最小数值, 并且每次put()和pop()至多移动log(n)个数值

真是好久没接触算法了:)

http://www.cse.iitb.ac.in/~soumen/doc/www1999f/html/

http://www.cindoc.csic.es /cybermetrics/pdf/68.pdf

今天翻了util包，发现自己对float的匮乏知识，好在有伟大的wiki百科：
http://en.wikipedia.org/wiki/IEEE_754
很清楚得解释了IEEE 754规范

可惜看不懂lucene对small float的结构定义。
如果按我的理解，似乎类SmallFloat的函数byteToFloat()和byte315ToFloat()有bug，通过编写测试代码：
SmallFloat.byte315ToFloat(Byte.parseByte("01111000", 2)得到的float值为0.5f，

但按照byte315ToFloat()函数的说明，"01111000"的mantissaBits尾数长度为3, zeroExponent为15，无负数，
而01111按IEEE 754规范，应该理解为1，所以01111000表达的数值应该为1.0×2^0=1，而不是0.5f
非常之tricky。

通过读byte315ToFloat()函数实现，发现"01111000"转换为32位值0,01111110,00000000000000000000000,
该值按IEEE 754规范的确为0.5f， 其中正负位为1位，指数(exponent)位为8位，尾数(mantissa)位为23位。

而在byteToFloat()和byte315ToFloat()的实现中，我们可以常看到作者将尾数位偏移24-mantissa位，
也就是说，他理解的IEEE 754规范中尾数位不是23位而是24位。

以上仅为我的猜测，因为还没有看到byteToFloat()的具体使用环境。

而且通过测试代码，发现byte和float对应关系：
10000,000==2.0f= 1*2^1
10001,000==8.0f=1*2^3
10010,000==32.0f=1*2^5
01111,000 = 0.5f = 1*2^-1
01110,000==0.125f= 1* 2^-3
完全看不出合理的small float的结构，tricky!!!

swt中，默认只有用户线程被允许访问UI图形控件和一些图形API，其他非用户线程如果直接访问这类资源时，SWTException直接被抛出。
如果真有这种需求，必须使用*.widget.Display类中的两个线程同步方法：syncExec(Runnable)和asyncExec(Runnable)。方法syncExec()和asyncExec()的区别在于前者要在指定的线程执行结束后才返回，而后者则无论指定的线程是否执行都会立即返回到当前线程。

例子:
Display.getCurrent().asyncExec(new Runnable() {
　public void run() {
　　butt.setText("Push");
　}
});

以下载自某论坛（sorry,忘记了出处），关于内存释放：

Rule 1: If you created it, you dispose it.
Rule 2: Disposing the parent disposes the children.
(from http://www.eclipse.org/articles/swt-design-2/swt-design-2.html)

当使用构造函数来创建小窗口或图形对象时，使用完时必须用手工来除掉它。
如果没有使用构造函数就获取小窗口或图形对象，则一定不能用手工来除掉它，因为您未分配它。
如果将对小窗口或图形对象的引用传送至另一个对象，则一定要小心，仍在使用它时一定不要除掉它。与在使用图像的插件模式中所描述的规则相似。）
当用户关闭Shell时，将递归地销毁 shell 及其所有子代小窗口。在此情况下，不需要除掉小窗口本身。然而，必须释放与那些小窗口一起分配的所有图形资源。
如果创建图形对象以便在其中一个小窗口的生命周期内使用它，则在除掉小窗口时必须除掉图形对象。这可以通过向小窗口注册销毁侦听器，并在接收到销毁事件时释放图形对象来实现。

这些规则有一个例外。简单的数据对象（例如，矩形和点）不使用操作系统资源。它们没有 dispose() 方法，您也不需要释放它们。如果有疑问，则检查特定类的 javadoc。

第一种方式，zkjbeyond的文章中有很详细的说明http://www.blogjava.net/zkjbeyond/archive/2006/05/05/44676.html
简单说，就是利用Ajax读取包的.js文件后，直接使用eval()运行代码。

除此外，dojo还有另一种加载方式，用在调试阶段（例如使用firebug活Venkman调试dojo时都需要用到，不过我没试过使用MSE7或Visual Studio时是否需要使用这种加载方式）。

你在加载包前，将djConfig.debugAtAllCosts设置为true，那么包的加载方式会有所变化，采用第二种方式。例如：

   djConfig.debugAtAllCosts=true;
    dojo.require("dojo.widget.TimBar");
    dojo.hostenv.writeIncludes();

此时，dojo会使用加载brower_debug.js文件，
brower_debug.js重载了函数dojo.hostenv.loadUri，这儿，不再直接使用eval()运行，而只是把需要的包push到dojo.hostenv.loadedUris数组中。实现代码：

                var text = this.getText(uri, null, true);
		var requires = dojo.hostenv.getRequiresAndProvides(text);
		eval(requires.join(";"));
		dojo.hostenv.loadedUris.push(uri);  //push要加载的包到loadedUris数组中
		dojo.hostenv.loadedUris[uri] = true;
		var delayRequires = dojo.hostenv.getDelayRequiresAndProvides(text);
		eval(delayRequires.join(";"));

从代码可以看出，dojo为了保证加载的顺序，使用dojo.hostenv.getRequiresAndProvides函数将提前依赖的包抠出来，用递归提前push到dojo.hostenv.loadedUris中。
而后，在代码最后，我们只要主动使用dojo.hostenv.writeIncludes();函数，就可一次性将被依赖的包利用document.write包含进来。

btw:
当然，这种方法有不少缺陷：
1、使用document.write方式加载包，会有延迟效应，会等待本页面中代码都执行完才执行包中的代码，自己编码时有点绕，影响可读性；
2、从上面代码中看出，dojo会有更多的IO操作，第一dojo已经完整读取了包代码，但是不马上执行，只是用来分析依赖关系；之后，浏览器又要加载一次包代码。
3、包绝对不允许循环引用。当然，从OO角度，不循环引用是好的方式

所以，这种方式只能用在调试期间