隨筆檔案

http://www-128.ibm.com/developerworks/cn/opensource/os-ecl-ajax/index.html?S_TACT=105AGX52&S_CMP=techcsdn http://www.sergiopereira.com/articles/prototype.js.html http://blog.csdn.net/calvinxiu/archive/2006/08/08/1036306.aspx http://java.csdn.net/n/20060807/93375.html http://java.csdn.net/n/20060808/93473.html https://compdoc2cn.dev.java.net/prototype/html/prototype.js.cn.html 定義：一個正則表達式，就是用某種模式去匹配一類字符串的一個公式。
正則表達式由一些普通字符和一些元字符（metacharacters）組成。普通字符包括大小寫的字母和數字，而元字符則具有特殊的含義，我們下面會給予解釋。

元字符	?	描述
.		匹配任何單個字符。例如正則表達式r.t匹配這些字符串：rat、rut、r t，但是不匹配root。?
$		匹配行結束符。例如正則表達式weasel$ 能夠匹配字符串"He's a weasel"的末尾，但是不能匹配字符串"They are a bunch of weasels."。?
^		匹配一行的開始。例如正則表達式^When in能夠匹配字符串"When in the course of human events"的開始，但是不能匹配"What and When in the"。
*		匹配0或多個正好在它之前的那個字符。例如正則表達式.*意味著能夠匹配任意數量的任何字符。
\		這是引用府，用來將這里列出的這些元字符當作普通的字符來進行匹配。例如正則表達式\$被用來匹配美元符號，而不是行尾，類似的，正則表達式\.用來匹配點字符，而不是任何字符的通配符。
[ ]? [c1-c2] [^c1-c2]		匹配括號中的任何一個字符。例如正則表達式r[aou]t匹配rat、rot和rut，但是不匹配ret。可以在括號中使用連字符-來指定字符的區間，例如正則表達式[0-9]可以匹配任何數字字符；還可以制定多個區間，例如正則表達式[A-Za-z]可以匹配任何大小寫字母。另一個重要的用法是“排除”，要想匹配除了指定區間之外的字符——也就是所謂的補集——在左邊的括號和第一個字符之間使用^字符，例如正則表達式[^269A-Z] 將匹配除了2、6、9和所有大寫字母之外的任何字符。
\< \>		匹配詞（word）的開始（\<）和結束（\>）。例如正則表達式\<the能夠匹配字符串"for the wise"中的"the"，但是不能匹配字符串"otherwise"中的"the"。注意：這個元字符不是所有的軟件都支持的。
\( \)		將 \( 和 \) 之間的表達式定義為“組”（group），并且將匹配這個表達式的字符保存到一個臨時區域（一個正則表達式中最多可以保存9個），它們可以用 \1 到\9 的符號來引用。
|		將兩個匹配條件進行邏輯“或”（Or）運算。例如正則表達式(him|her) 匹配"it belongs to him"和"it belongs to her"，但是不能匹配"it belongs to them."。注意：這個元字符不是所有的軟件都支持的。
+		匹配1或多個正好在它之前的那個字符。例如正則表達式9+匹配9、99、999等。注意：這個元字符不是所有的軟件都支持的。
?		匹配0或1個正好在它之前的那個字符。注意：這個元字符不是所有的軟件都支持的。
\{i\} \{i,j\}		匹配指定數目的字符，這些字符是在它之前的表達式定義的。例如正則表達式A[0-9]\{3\} 能夠匹配字符"A"后面跟著正好3個數字字符的串，例如A123、A348等，但是不匹配A1234。而正則表達式[0-9]\{4,6\} 匹配連續的任意4個、5個或者6個數字字符。注意：這個元字符不是所有的軟件都支持的。

---

public aspect TraceAspect{
   private Logger _logger = Logger.getLogger("trace");
   pointcut traceMethods(): execution(* *.*(..))&&!within(TraceAsptect);
   before() : traceMethods(){
      Signature sig = thisJoinPointStaticPart.getSignature();
      _logger.logp(Level.INFO, sig.getDeclaringType().getName(), sig.getName(), "Entering");
  }
}

What’s wrong with conventional logging ?

When a new module is added to the system, all of its methods that need logging must be instrumented. Such instrumentation is invasive, causing the tangling of the core concerns with the logging concern. Further, if you ever happen to change the logging toolkit to a different API, you need to revisit every logging statement and modify it.

Consistency is the single most important requirement of logging. It means that if the logging specification requires that certain kinds of operations be logged, then the implementation must log every invocation of those operations. When things go wrong in a system, doubting the logging consistency is probably the last thing you want to do. Missed logging calls can make output hard to understand and sometimes useless. Achieving consistency using conventional logging is a lofty goal, and while systems can attain it initially, it requires continuing vigilance to keep it so. For example, if you add new classes to the system or new methods in existing classes, you must ensure that they implement logging that matches the current logging strategy.

The beauty of AspectJ-based logging

The limitations are not a result of the logging APIs or their implementations; rather, they stem from the fundamental limitations of objectoriented programming, which require embedding the logging invocations in each module. AOP and AspectJ overcome those limitations. AspectJ easily implements the invocation of logging statements from all the log points. The beauty is that you do not need to actually instrument any log points; writing an aspect does it automatically. Further, since there is a central place to control logging operations, you achieve consistency easily.

The most fundamental difference between conventional logging and AspectJbased logging is modularization of the logging concern. Instead of writing modules that implement core concepts in addition to invoking logging operations, with AspectJ you write a few aspects that advise the execution of the operations in the core modules to perform the logging. That way, the core modules do not carry any logging-related code. By modularizing, you separate the logging concern
from the core concerns.

With AspectJ-based logging, the logger aspect separates the core modules and the logger object. Instead of the core modules’ embedding the log() method invocations in their source code, the logger aspect weaves the logging invocations into the core modules when they are needed. AspectJ-based logging reverses the dependency between the core modules and the logger; it is the aspect that encodes how the operations in the core modules are logged instead
of each core module deciding for itself.
 

泛型的引入使得 Java 語言中的類型系統更加復雜。以前，該語言具有兩種類型 —— 引用類型和基本類型。對于引用類型，類型 和類 的概念基本上可以互換，術語子類型 和子類 也可以互換。

隨著泛型的引入，類型和類之間的關系變得更加復雜。List<Integer> 和 List<Object> 是不同的類型，但是卻是相同的類。盡管 Integer 擴展 Object，但是 List<Integer> 不是 List<Object>，并且不能賦給 List<Object> 或者強制轉換成 List<Object>。

另一方面，現在有了一個新的古怪的類型叫做 List<?>，它是 List<Integer> 和 List<Object> 的父類。并且有一個更加古怪的 List<? extends Number>。類型層次的結構和形狀也變得復雜得多。類型和類不再幾乎是相同的東西了。

extends 的新含意 

在 Java 語言引入泛型之前，extends 關鍵字總是意味著創建一個新的繼承自另一個類或接口的類或接口。

引入泛型之后，extends 關鍵字有了另一個含意。將 extends 用在類型參數的定義中（Collection<T extends Number>）或者通配符類型參數中（Collection<? extends Number>）。

當使用 extends 來指示類型參數限制時，不需要子類-父類關系，只需要子類型-父類型關系。還要記住，有限制類型不需要是該限制的嚴格子類型；也可以是 該限制。換句話說，對于 Collection<? extends Number>，您可以賦給它 Collection<Number>（盡管 Number 不是 Number 的嚴格子類型）和 Collection<Integer>、Collection<Long>、Collection<Float> 等等。

在任何這些含意中，extends 右邊的類型都可以是參數化類型（Set<V> extends Collection<V>）。