Achilles’s Cabin

按照jetBrains网页上的那个HelloWorld教程一步一步做下来 后来定义generator的时候出现了异常，找了半天也没找到原因 不知道是不是他们工具的bug，从前面的操作已经感觉到了一点这个mps的好处了 它用这种editor的形式使得程序也可以数据一样操作，他们声称的这种是自定义的DSL 这个稍稍有点体会

EAP即Early Access Program JetBrains的网站上说：It is important to distinguish EAP from a pre-release software. Please note that the quality of EAP versions may at times be far below even usual beta standards.
二月份的时候看到了Sergey Dmitriev发表的一篇文章Language Oriented Programming: The Next Programming Paradigm，感觉这是个好东西，有点类似于mda，但是侧重点不同。下载了个Mps，赶快看看有没有什么激动人心的东西

If you plan to create custom painting code for a component, this section is required reading. Understanding the concepts in this section might also help you troubleshoot if Swing components don’t seem to be displayed correctly.
How Painting Happens
When a Swing GUI needs to paint itself — whether for the first time, in response to becoming unhidden, or because it needs to reflect a change in the program’s state — it starts with the highest component that needs to be repainted and works its way down the containment hierarchy. This process is orchestrated by the AWT painting system, and made more efficient and smooth by the Swing repaint manager and double-buffering code.
Swing components generally repaint themselves whenever necessary. When you invoke the setText method on a component, for example, the component automatically repaints itself and, if appropriate, resizes itself. Behind the scenes, when a visible property changes the repaint method is invoked on the component to request that it be scheduled for painting. If the component’s size or position also needs to change, a call to revalidate precedes the one to repaint. The repaint and revalidate methods are thread safe — they can be invoked from any thread.

——————————————————————————–
Note: Like event-handling code, painting code executes on the event-dispatching thread. While an event is being handled, no painting will occur. Similarly, if a painting operation takes a long time, no events will be handled during that time.
——————————————————————————–

Programs should paint only when the painting system tells them to because each occurrence of a component painting itself must execute without interruption. Otherwise, unpredictable results could occur, such as a button being painted as half pressed and half unpressed.

For smoothness, Swing painting is double-buffered by default — performed to an offscreen buffer and then flushed to the screen once finished. You can improve painting performance by making components opaque when possible, so that the Swing painting system doesn’t waste time trying to paint behind these components. To make a Swing component opaque, invoke setOpaque(true) on the component.

Although the painting area available to Swing components is always rectangular, non-opaque Swing components can appear to be any shape. A button, for instance, might display itself by painting a filled octagon. The component behind the button (its container, most likely) would then be visible, showing through at the corners of the button’s bounds. The button would have to include special hit detection code to avoid acting pressed if the user happens to click its corners.

The Swing Painting Methods
The painting method you’re most likely to override is paintComponent. It’s one of three methods that JComponent objects use to paint themselves. The three methods are invoked in this order:
paintComponent — The main method for painting. By default, it first paints the background if the component is opaque. Then it performs any custom painting.
paintBorder — Tells the component’s border (if any) to paint. Do not invoke or override this method.
paintChildren — Tells any components contained by this component to paint themselves. Do not invoke or override this method.

——————————————————————————–
Note: We recommend that you don’t override or invoke the method that calls the paintXxx methods: the paint method. Although overriding paint is legitimate in non-Swing components, it’s generally not a good thing to do in components that descend from JComponent. Overriding paint can confuse the painting system, which relies on the JComponent implementation of the paint method for correct painting, performance enhancements, and features such as double buffering.
——————————————————————————–

The following figure illustrates the order in which each component that inherits from JComponent paints itself. Steps 1 and 2 — painting the background and performing custom painting — are performed by the paintComponent method. Step 3 is performed by paintBorder, and step 4 is performed by paintChildren

1. background
(if opaque) 2. custom
painting
(if any) 3. border
(if any) 4. children
(if any)

[PENDING: We will change the figures so that green areas in 1 & 2 are a bit bigger — they should cover the same area as is covered by the black and green areas combined in 3 & 4.]
The standard Swing components delegate their look-and-feel-specific painting to an object called a UI delegate. When such a component’s paintComponent method is called, the method asks the UI delegate to paint the component. Generally, the UI delegate first checks whether the component is opaque and, if so, paints the entire background of the component. Then the UI delegate performs any look-and-feel-specific painting. The JComponent class doesn’t set up a UI delegate — only its subclasses do. This means that if you extend JComponent, your component needs to paint its own background if it’s opaque.

If you need more information about painting, see Painting in AWT and Swing. It’s an article in The Swing Connection that discusses in depth the intricacies of painting.

ejb3.0的使用和2.0比起来清爽了许多，现在就让我们开始3.0的浪漫旅程。
bean实现类：
import javax.ejb.Stateless;

@Stateless
public class HelloBean implements IHello
{
public String sayHello(){
return “System.out.println(\”hello boss\”)”;
}

}
远程接口：
import javax.ejb.Remote;

@Remote
public interface IHello
{
public void sayHello();

}
研究一下这个实现容易发现 现在的bean完全省略了home接口，这个远程接口不用实现ejbObject而且远程方法不用throws RemoteException只要在前面注释为Remote其余工作都由容器来搞定，是不是清爽多了
现在的ejb看起来更接近于普通java对象（pojo），远程接口看起来更像一个普通的java接口
而且测试过程中第一次使用了ant ，这个东西非常像linix下的make,感觉真是个好东西，网上说3.0可以脱离容器测试 但是好像规范没有给出具体的说明。

准备研究一下ejb3.0的开发

工作量一定不小 待我慢慢纪录进展