The ZIP filesystem provider in JDK7 Xueming Shens Oracle Blog

The ZIP filesystem provider in JDK7 Xueming Shens Oracle Blog.

Java will get some friendly file API, finally, after 10 years.

try (FileSystem fs = FileSystems.newFileSystem(Paths.get("my.zip"), null)) {
Files.copy(fs.getPath("/file.in.zip"), Paths.get("dropbox/unzipped.file");
}

近况和 Hadoop

很久沒有寫 blog 了，不過沒差．反正原本就該沒有人會看．ＸＤ

差不多都是忙工作，和 mysql 戰鬥也在和 Hadoop 戰鬥．

不容易，卻很有挑戰性

最近 Hadoop 的名聲開始高而且使用這個 open source project 的人也越來越多

感覺上好像有很多人有在用，但試用或小玩一下的人比較多．真的大量投入 production 的人還比較少；所以發現問題時很大機會都要自己去解決而不是從其他人的錯誤中學習．看它 source code 多了，也大聲罵它的次數多了．

我必需說．．．它的 coding implementation 很有問題；而且我還只是說最基本的 HDFS 的部份．差不多沒有文檔，也經常更改Client-Server API protocol 的情況下，最快了了解它的運作方式我都是去直接去看它的 source code

它用它自己類 IPC/RPC 的 Proxy 連去 namedode.... stafeful ; 我不明白為何不用 stateless 而且可以加入不同版本支持的做法 (如果我自己沒看錯,  application 和 cloud 的版本必需一樣,   也就是說應該不能一個 client 連到不同 version 的 hadoop; 至少 0.20 和 0.21 不能)

用 NIO 卻沒有用上 thread-pool；簡單的一個寫入一個 file 的動作原來需要大約三條 threads，同時寫入十個文件則是三十條 threads..) 而且都是 non-pooled-thread ；也不支持 Channel 和 ByteBuffer 寫入

大部份使用的 API都是停留在 1.4 年代的，直接 extend Thread 沒有用 Executor，用 NIO 的部份現在只是為了 read/write timeout；在 Filesystem 可以找到大量 global synchronize 的 method，也奇怪也難以理解的 helper proxy 去實現 RETRY

最大的問題是．．．．它居然真的能跑
所以大家看到有問題都不能不想也不敢去嘗試修正

 

lambdaj - Project Hosting on Google Code

lambdaj - Project Hosting on Google Code.

看過好幾個 LINQ like closure solution on Java 的 syntax

用 lambdaj 的實現的 "Hello World" 也可以說是最簡單和和 Programmer Friendly

Java 相比 C# 係實現 LINQ / closure 最大問題係原自 Language Syntax

在不改變 Java Language 本身嘅情況下, 最多都只係類似 lambdaj 那種 很多很多 (((會眼花) 好易打錯(的多層 static method lambdaj)) 寫法
而且大量利用 Proxy 和 static method 的情況下, 程式的可讀性會出現問題

C# 有 delegate (a.k.a function pointer), 而且 delegate 都是 strong typed 的, 有很多都可以利用它來簡化
C# 甚至加入近幾狂亂的 Expression 去簡化往日很多由  programmer 的好多手工作業 (雖然我唔知道除左 LINQ 重有咩地方會想去用 Expression....PF? WF?)
C# 加入了 Extension Method 去修正先後次序的可讀性問題

我最近在 C# 實作了動態 ExpressionTree Builder ........對把這種功能整合到 Syntax 和 Compiler 有很深的體會, 那真的簡單很多很多很多

C# 3.0 很美, 但 Visual Studio 卻.....唉~~~ 都是 Eclipse 的錯.........寫不到 C#

Java 7, 依目前我所知的, 是跟不上 C#

最近都在寫 C#

唔係好習慣, 特別係 naming 同 IDE 嘅用法。始終 Eclipse 實在太好用啦。

的確 C# 係 language 同 syntax 上面都比 Java 先進，不過個 VS 實在太大食，而且個 Internet 同部機實在太慢啦！！

I miss Eclipse, 我每日至少會講一次

好在我重未老，學習能力同上手能力都依然好高。但係個 Internet 同部機實在太慢啦 (x2)

Java 7 聽左咁耐，都唔知幾時先至有。但另一邊 C# 4.0 好快接近。我係唔係要改我自己嘅 major language 呢？

或者 Ruby?, Python?, JavaFX? 定係 Android? Java ME? 甚至 C++ 呢？

Eclipse VE 復活!?

Life’s Passion » Blog Archive » Eclipse VE gets revived!.

Welcome back of VE in Eclipse stream after more than two years’ sleeping

網摘: Yet Another Java Blog: Intro to Caching,Caching algorithms and caching frameworks part 1

Introduction:

A lot of us heard the word cache and when you ask them about caching they give you a perfect answer but they don’t know how it is built, or on which criteria I should favor this caching framework over that one and so on, in this article we are going to talk about Caching, Caching Algorithms and caching frameworks and which is better than the other.

Yet Another Java Blog: Intro to Caching,Caching algorithms and caching frameworks part 1.

Boss, you have misunderstand on GWT and Gears

It is good for "classic Web development" to "Web 2.0 development". It is not for moving from fat client/server  application to web based application.

It cannot not do persistent, share, or collaboration without a server. You always need (at least) one server unless a classic client/server fat application.

- "database" in Gears is a rich replacement of cookie, by using of sqlite
- GWT is "Java like syntax", it is not Java. You cannot migrate your swing application to GWT. You can only share these soruce code in very very extreem cases.

From my point of view, RIA / AJAX are hot because they can  provide Rich user interface and can save some development time on "supporting function".

AJAX Web application can help you that do a 3-tear application, rather a 4-tear application.

e.g.
old 4-tear :
Browser HTML <-> web app (control of GUI here)<-> web services <-> databases
AJAX 3-tear :
Browser AJAX/RIA <-> web services <-> databases

Programmers can spend less time on fighting with broad width, HTTP 1.1 specification, browser compatibility.

Sun Microsystems to cut up to 6,000 jobs - Nov. 14, 2008

Sun Microsystems to cut up to 6,000 jobs - Nov. 14, 2008.

NEW YORK (CNNMoney.com) -- Software and computer networking company Sun Microsystems, Inc. announced Friday it will cut up to 18%, or 6,000, of its staff in a cost-cutting move.

放一陣子看看另外幾大巨頭會不會也 cut jobs 吧

Google, Microsoft, IBM, Yahoo, ...etc

My comment on JavaFX

10 years before, Sun was too early to press RIA with Applet.
10 years after, Sun was too late to press RIA with JavaFX.

I don't think I'll use JavaFX. And I don't think it will not be a success RIA.
But I think that Sun can try. JavaFX will benefit feature improvement on Swing/JMF.

JavaFX will be useful, IF it is the widely used in Netbeans it self.
They will find what's the problem with it and fix it.

We will have a standard of describe the GUI in Java (even if another JSR to replace the JavaFX later).

---

JavaFX is "programming" the GUI. but not simply describe it statistically.

Personally, I prefer something like XUL even XAML over JavaFX.
I don't see how JavaFX can abstract the UI to "any implementation".

There is an implementation that can almost render XAML in Swing and SWT already.

---
Please correct me if I wrong.
Is JavaFX Script more like "the ActionScript in Flash", but it isJava rather then ECMAScript ?

Effective Java - 2nd Edition

Effective Java - 2nd Edition

很久以前好像看過一次 1st edition。上上周0從 HKPL 借來，放了一個多星期沒有碰，這兩天有空就很快的把這本書看完了（Because I have to return it this weekend）。其實內容很多都是我很早就知道的東西，所以沒仔細看，把大多細字都跳過，只讀 subject, bold statement 和 summery 其實已經很足夠。（不過應該只限本來就很熟的人才可以這樣做）

始終這本書都比較中階入門級，沒有很廣泛很深入的去說明其他不同的場合的應對方式。

........不知有沒有一本相對的書是說 C#？ Effective .NET？

LINQ and Hibernate 2

LINQ to SQL 有relation ga… (如果我無get錯你想講的野的話)….

晌IDE, 你可以right click on the class then add “association”…… 又或者, 你自己改佢個xml file加上去都得

至於transaction, 都有的, 你要自己initialize一個TransactionScope的object……….
http://msdn.microsoft.com/en-us/library/bb425822.aspx#linqtosql_topic20

而lazy loading…….. 某程度上都係有的
http://msdn.microsoft.com/en-us/library/bb425822.aspx#linqtosql_topic11 <— look for deferred loading

Commented by PakPak

我知 LINQ 有 Relation，但我比較係想講想法不同。

唔知 node.Child.Child.Parent.Parent 係做左四次 SQL query 定係識得 load 返去同一個 instance 呢?
又如果佢係 self-pointing relation 又點計呢？

我有問佢 LINQ 有無 handle 到比較 complex 的 transaction, row locking, timeout，佢答無。但讀了你的 link，原來係放左入去 LINQ to SQL 個 module 入面。睇落都可以應付到一般簡單要求。

lazy loading
幸好可惜 LINQ 唔係， deferred loading 應該算係 "query on demand" (每一次重新 IEnumerable 時行一次 SELECT)
我想講嘅 lazy loading，係 hibernate 那一種只讀 PK，到需要時再讀 full row。
或者 load 定某幾個 important field，再 on demand 去 query large column。

LINQ 做法係，寫 LINQ 時會正確完全知道自己將會想點用同埋會用邊一個 field，而用 anonymous class 去最少化 data transport 同 heap size。如果後來的 logic 要應用更多 field，你要改原本句 LINQ 或者再執行另一句 LINQ。

Hibernate 做法係，一係你寫 HQL 然後拿 Map；一係 lazy load 整個 proxy object，成個 object 可能傳去唔知去邊比度比邊個操作，再自己係 config file 修改來進行優化。

LINQ and Hibernate

LINQ 其實有好多野都可以做但都未做得到呢........ IQueryable Provider 未齊人
AD / FileSystem / WMI / LDAP / network / parallel /  WS / MQ .....etc

其實LINQ最方便係佢可以好簡單地convert data from sql to xml, or from sql to json, or from json to xml, or vice verse.

以前要寫好長好長的codes, 三兩句用LINQ就攪掂了……
做左programming咁耐, 有時真係lazy打咁多字.

同埋, 佢本身個類似ORM的tools, 感覺上, 比Hibernate果D好好多……. 我諗主要個原因係, VS managed 左XML generation果part, 而且有IDE 幫手可以好快咁define association between entities, 呢個我覺得令到佢比hibernate方便………

Commented by PakPak

試想想..... NTFS 之類又 hardlink, softlink 又 junction point.......
from x in C:
depth 5
where filename.endsWith(*.txt)
distinct file.FileRef
select new{file.FullPath, file.mimeType};
之類會好有用; 至少一定好過 Unix 個 `find` syntax

我都有走去問佢可唔可以做到 Runtime LINQ compiler...........可惜佢答你可以自己寫: 目前沒有
也就是不可放入 config file, 也不能做到互動式.....

其實 Hibernate 性質又有D唔同

Hibernate 真係 O/R Mapping
我咁睇: ORM 係令到你可以 Presistent 一個 Object 入 RDBMS 而唔係 Object-DB
如果你所有野都係由 object 出發, 唔無視 database design/how it works 就好有用
What you have is a object which presistented to database, and you decide what is an "Object"

而其他 mapping tools, 根本上能只算係
SQL builder / result mapping
如果你有 "query database" 或者 "update table" 之類想法, Hibernate 可以話係完全唔合適

LINQ to SQL 事實上係都係 SQL builder  + result mapping
無 relation, 無 lazy loading, 無 transaction,
What you have is a copy of the data, then you decide how to use "DATA", not "Object"

其實唔同文化理念造就出分別
例如 Java vs C# 咁,

Sun 一直都想 minimum 整套 JDK, bytecode, Java Syntax ;唔想包太多 utility /common class 入去
=> 結果差唔多個個 project 都走去用 apache-common; JRE 都慢慢被迫加入更多新功能而變得更大, 最後唯有放棄 minimum 想法而轉用 Consumer JRE 路線(居然還未放棄 Applet market...)
佢想保持自己 Stupid Simple; 因為原本無想過 Java 會是主力....I was only want to sell more hardware

而且 Java commutity 一直有反動力........sun 根本無咁多 resource 去 sell / press 同埋 bugfix
你見其實重有唔少 1.3 年代的 Feature/bugfix request 到重係 pending, won't fix, reconized, will fix in JDK7
MS 一直都不停咁 extends 個 IDE, 大量 template, toolkit, framework, 改善 C#; 總知有用就加入去
=> VS 巨大化, 怪物化; 精通使用 VS.NET 甚至比精通 Photoshop 或者寫 code 本身更難.

佢根本唔怕 installation package 太大, 或者太多野而更多 bugfix (因為根本無 Java 個 "cross-platform" 理念)
想做到嘅係吸引更多 developer, 做一樣野可以有三種選擇
佢想令到 Development Stupid Simple

也就是很多 Programmer 討厭的 VB 式 drag-n-drop 寫 code 方式.........
但事實上,手動改很多事情的空間不少(只要你知道)

你提是你能不能找得對的文件/問對人
和 Java 有點不同, 他們不是每一件事都 open to public.......

Sun 是想改變 stupid programmer (They should know what they are doing. It is powerful, but take are it yourself)
MS 則是接愛 stupid programmer (They can code in VS, even they should know. Whatever, it works),

網摘: Immutability in Java

很久沒 quote Java 的東東了

Part 1 on Immutability in Java:
http://jeremymanson.blogspot.com/2008/04/immutability-in-java.html

Part 2 on Immutability in Java:
http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html

Part 3 on Immutability in Java - Deserialization and Reflection:
http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html

 

 

重點是， final 是必需的。之前的 Javaspeciallist 的文章有有提到。final 的功用不但會限制寫入和方便 inner class 存取而已，它會影響 Just-In-Time compiler 的行為，和防止它作出過份優化而引起的錯誤。

該記著，JRE 不是一行一行執行你的 code(那只會在 debugger發生)，而且在 JIT 在 SMP 的情況下會令到 bytecode 執行次序更加難以估計。該加上 final / violate 地方不要偷懶。

網摘: Scaling Your Java EE Applications

Scaling Your Java EE Applications

Scaling Your Java EE Applications Part 2

 

SMP 和 Server Load balancing 要注意的地方

Eclipse 3.4 M7

Eclipse 3.4 M7 - download

Eclipse 3.4 M7 - New and Noteworthy

 

其中我覺得最有用嘅係

 

Java compiler on multi-CPU machines

You should see faster Java compile times when using machines with multiple CPUs. The Eclipse Compiler for Java (aka "ecj") is now taking advantage of the multi-threading capability of multi-CPU machines. The full build of a Java project also takes advantage of this support.

最近好像和新的 Java 技術脫節了

最近推出的 Framework, library 的新版本，雖然知道，看到新聞，也讀過簡介，也參考過 sample code。

可是就沒有真正拿上手試過，寫過，用過。

總有一種，殺雞焉用牛刀的感覺而沒有在 small application 中使用它們。大型 application 的也很少要重新開發修改其 framework。

也會開始問理性地自己，為何要用新版？和舊版比較有甚麼特點？想過，仔細選擇過才去做。

 

難度我開始老了嗎。。。。。

Finalize 和 JWindow, JFrame, JDialog

上次寫完 Java, Garbage Collection與 Memory management 當中提到 AWT 和 Finalize 的關係，仔細一想後覺得大有文章，要再寫多少少。

 

有一少部新手入門看的書當中介紹的做法，和一部份 WYSIWYG GUI Editor 的做法，都是以 JDialog / JWindow 來實作自己的的視窗。可是根據 Swing 正確的 MVC design pattern 和 finalize 的關係來說，這是完全錯誤，而且可笑的，荒謬的做法。
如果只是為了即省幾行 code 或即省介紹每一節的功能，那就比較合理，但卻會教壞新手。

 

javax.swing.JDialog, javax.swing.JFrame 和 javax.swing.JWindow 都是 extends 了 java.awt.Dialog, java.awt.Frame 和 java.awt.Window 。本質上它們依然是一個 AWT 元件，只係在其上再加建 Swing 的 API 去支持運作。它們，依然是擁有 finalize method 的重元件(須要兩次 GC 才能清理)。

也就是你在自己 extends 了它們的 object 都自動成了重元件，令到任何在其中的 members 都無可避免地減低 GC 效率和增加記憶體使用量。而且，這根本就會令到你的物件本身的可重用性減低。

但很可惜在官方的 Tutorial Using Top-Level Containers 沒有提到這一點和它的重要性。

比較合理的做法是以 javax.swing.JComponent 或 javax.swing.JPanel 為基礎，而另外自行寫一組簡單的 function 來實現

frame=new JFrame();
frame.getContentPane().add(xxx);

而且，也為了 GC 優化，在確定 Window 不會重用(不會再執行 show() 或 setVisible(true);) 的地方(例如 void windowClosed(){...} ) 加上

frame.getContentPane().remove(xxx);
// 別忘了還有 Menu 和其他

，令它們和重元件 window 分離。

這樣一來，在 GC 的時候，它就能把 Windows 和 載有大量 data 的部份分開辦理，在 JPanel 當中存在/連結的大量 memory 能一口氣在第一次 GC 就能被清掉，而不是等 finalize 執行後的第二次 (甚至第三次, 第四次) 的 GC 才能被移除。

當然這樣的 GC 優化這對只會冇單一 Window 的 application 沒有特別意義的，也對 EXIT_ON_CLOSE 的 window 沒有意義。但能算是比較正規的做法。

 

 

我不喜歡 Swing，它實在太易令人犯錯而不自知。特別是那不 Thread-safe，但又難以 debug 的設定。

知得越多，就發現自己懂得越少

無論是 Java，英文，朋友，人際關係甚至係金錢管理。

古人話：『苦海無邊‥』呀唔係『學海無崖，唯勤是岸』都沒有錯

無論是甚麼人，學習甚麼也好，每學一件事，就會生出更多的問題要去解答，去再學習。不是你覺得已經足夠而放棄了學習，就是持續一直學下去，而永遠沒有學完了而停止的。

勤力的人，會比較快學得到他所需要的足夠的知識。但如果他停了下來放棄了 勤，就會慢慢被無情的浪再卷入學海當中。

 

最近，學習的進度好像學了下來。發覺自己雖然經學了不少，卻好像看到很多的地方要去學習改善。

我很疲倦而停下了腳步，我根本不能集中精神去學習。我心思都被某個人填滿－－看吧，我原本沒有打算寫到她的，但還是這樣。

Java, Garbage Collection與 Memory management

很多新手都以為， Java 和相比 C++，JVM 內置了 Garbage Collection 的功能就相等於 "我不用管" / "我可以寫少幾行 code",這種想法，是要不得的。

其實這也難怪，太多書本和教學寫得都不清楚，甚至錯誤百出。
不是為了吸引新手使用 Java，就是把它定義為進階深入的知識，或根本連作者本身都錯誤理解了。

其實無論是 Java , .NET 或其他附有 GC 或其他聲稱有 GC 功能的語言，也要自己面對資源回收的理

為垃圾而設想

Garbage Collection (垃圾回收) 能有效率地運作的大前提是，它要知道甚麼是垃圾，甚麼不垃圾。
理所當然的，當你手上還捉緊著它們，還有 Object 之間千絲萬縷的連結，你又叫 GC Engine 如何替你進行回收呢？

其他的還有 GC 的時機，策略，優化(避免劣化) 也是要由寫程式的人來想。

別忘了它們的手足

GC 本來就只能替你回收記憶體，可是你不要忘了除了記憶體，你還有別的垃圾。IO Handle, native code 的 pointer 或其他向 OS / Hardware 要來的資源 。GC Engine 是不知道如何釋放／回收它們的，GC 能做到的只是告訴你：『我看到它上面有條便條，它要我在回收之前通知你，記得有其他的事情要做』－－－也就是 finalize method。

當 GC engine 看到將要回收的 Object 上有 finalize method，則會把它們放到一邊，經由獨立的 Finalizer Thread 執行。而你要做的，就是記得在 finalize 內把自己用到的 sub-process / native pointer / windows handle / file handle 經由 JNI 方法自己放掉。正如在 C 當中 delete pointer 之前要把子內容清掉一樣。

可幸地， JDK 內所有一般性會使用 native resource 的 Object 都已實作了 finalize，你在正常情況下都不必為它們底層的 File Handle, Socket, GUI Handle, pointer.... 等等太過粗心。不過你還是要注意和小心的！

你應該知道 SWT / Swing 和 AWT 吧！我以前讀 SWT 介紹的時候都不了解這一小句『SWT doesn't  use the Java garbage collector....』當時我看不懂，近年才有所覺悟。它所說的，不是指 Java 中Object 記憶體的回收，而是指不等待不使用 GC 的 Finallizer 來回收 GUI Handler。　先說一點歷史，當年 AWT 設計上最失敗的地方不是其 heavy-weight (這只是 Sun 用來騙人的術語)，也不是 GUI 的 cross-platform 問題。而是其而是其設計高估 GC 的能力 Finalizer Thread 的速度。　finalize 最大的多點是所有實現了它的 object 和它的子部件都至才要經過兩次 GC 才能被清掉，基本上所有使用了 AWT 的 Java Process 的 GC 都被劣化(使用 AWT 的大前提是你不應 extends 任何 AWT 元件)。而且 OS 能用的 GUI handle 數目是有限的，可是 AWT 就喜歡拿了一堆 Handle 不放手(還沒有 finalize 掉)，令到整個 OS out-of-resource 的機會大大提高。
Swing 就是應用了 light-weight (另一個騙人的術語) 的想法，減少向 OS 要求 resource，把 GUI 放入自己管理的部份。SWING 自行產生，管理，繪畫，事件，消除。(怎麼看都是把原本 OS 做的事搶來自己做，根本是更加重，更加 heavy-weight 才對) 來達到多重目的。 LookAndFeel 是其中最沒有用最浪費，郤又最多人掛在口邊的的。

而 SWT 的想法就是：『好吧，我知道它們是何時成為垃圾，就由我來把它回收吧。』
很簡單，很易了解，其實也只是要求 Progarmmer 去做他們本來就應該要做的工作。

GC 不只是 Garbage Collection

上文不是提到 GC 是回收記憶體中的垃圾和其他垃圾嗎？為甚麼又說它不是垃圾回收呢？

的確，原本的 GC 的用意 (包括 Java / .NET / C++ 和其他) 很可能根本只是垃圾回收。可是把它套用在近代的 JVM 上就有點太過小看 GC 了。GC 的另一樣重要的價值是自動化的記憶體管理。簡單來說，就是能否善用空間的能力。

記憶體管理大概可以被分為：配置，釋放，重置，定位等等。

根據支持者的研究文件指出(忘了出處)，老舊的 C/C++ 當中的 配置/釋放記憶體雖然每次都很快，但卻是 stop-the-world 的動作，效能算起來會和有 overhead 的 Java 差不多，甚至比 Java 差。

另外 GC 能避免 memory fragment 。fragment 的出現是因為程式每次向OS 要求 memory 都是以 page 為單位的，反復的配置/釋放會減低 page 真正需要使用的密度。JVM GC 在執行的時候，很多時候也會把 Object 的本體移來移去(e.g. Generational GC)。也是能把 2/5 + 2/5 + 1/5 整合為一個 5/5 的時機。VM 理論上和部份的實作上是做得到把常用的，連著使用的 object 放在一起，而把不太相關的，很有機會被垃圾掉了又放在另一個 page 內，而直接減少底層執行指令的負擔。例是說 String 本身和內在的 char[] 經常放在一起，減少要在多個不同的 page 讀寫的機會。

GC 它能做到的，它替你做到的，都比你想的多；但你也需要寫 GC friendly 的程式才行。

網摘: Lucene 2.3：大幅提升索引性能，新增機器學習項目

InfoQ: Lucene 2.3：大幅提升索引性能，新增機器學習項目

Ingersoll認為這次的版本中最大的變化是新的索引算法，它使用了新的in-memory模型來達到大幅的速度提升。據Ingersoll 說，單單是把Lucene 2.2 JAR換成Lucene 2.3 JAR就能在某些測試中把索引性能提速500%。其他改變還包括：

• 改進的索引管理——以前在索引過程中，當合併內部索引文件時偶爾會出現長時間的停頓，現在已經消滅了這種現象。另外現在也更容易實現其他途徑去管理索引過程。


• 對象池——Document、Field和Token的實例現在可在索引分析中重用，因此不但提升了分析的速度，還減少了索引過程中的內存分配次數。


• 重新打開IndexReader ——重新打開一個IndexReader去捕捉索引中最新的變化，這個操作的速度現在也更快了，新的reopen()方法只會加載那些變更過的索引片斷，而不是重新加載完整的索引。


• 更簡易的IndexWriter微調——setMaxBufferedDocs已被更直觀的setRAMBufferSizeMB所取代。

另外，2.3的目標是只需通過文件替換就能換下2.2，完全不需要重新編譯。這裡是完整的更新說明。