传说中凤凰每隔500年要投入火中以求得新生。有一种恒星在其「临死亡」的剎那，将发生激烈的爆炸，如迴光返照般放出极耀眼的光芒。星球毁灭了自己，却也同时触发了新恒星的诞生。这就是超新星，天上的火凤凰。

在宇宙中，恒星的分类是按照它们的死亡的方式，一类象我们太阳这种，最终安静的成为白矮星，另一类是比太阳大8倍以上的恒星，它们的死亡是爆炸。恒星越大，寿命就急剧的缩短，质量差3倍，寿命就差750倍，也就是说，一个比我们的太阳大3倍的恒星，它的寿命就只有1300万年，所以，生命的进化是不可能托付给大恒星的。但是，宇宙的物质的丰富和流动，却全靠它们。

宇宙在过去有过一个非常单调的开端，只有氢元素和少量的氦元素，然而宇宙在成长，而成长的标志就是重元素的增加，这种增加使宇宙越来越丰富，宇宙的所有的奇迹，都是在有了完整的元素制造之后。而制造元素，就是把氢元素以不同的数目聚合，而要完成所有元素的聚合的场所，就是拥有巨大引力的大恒星。从丰富物质角度来说，大恒星是宇宙中的精品，它们不仅能生产所有的元素，而且由于恒星越大，寿命越短，因此周期也短，所以，恒星的巨无霸是宇宙制造元素效率最高的工厂。不过，宇宙中最大的恒星的质量极限是一百个太阳，如果再大，就会因为自身的核反应过猛而解体。

船底座海山二星(Eta Carinae)可能即将爆炸

引力制造元素，但也束缚元素，小恒星大约能制造出十来种元素，但这些元素最终不能在宇宙中流动。大恒星能制造更多的元素，一般超过太阳质量 8倍以上的恒星就能使聚变一往无前，其核心达到几十亿度的高温不断的创造不可思议的聚变，每次聚变所产生的能量都使恒星膨胀得更大一些，于是它就象洋葱一样形成令人吃惊的多层核聚变的巨大空间，这个空间可以达到一百亿公里，装下整个的太阳系。在聚变的深入的过程中，恒星变得越来越危险了，因为元素越重，聚变提供的能量越少，而巨大的恒星又必须靠不断释放的核能支撑。然而，当聚变到排列第26位的铁元素时，摇摇欲坠的恒星遭受到最致命的破坏──因为铁元素的结构极其稳定，它在聚变时不释放能量，于是，巨大而膨胀的恒星将会因核心失去支撑而倒塌。

因此而恒星粉碎性的爆炸，能量的狂飙扫荡天庭，这就是超新星爆发。此刻它的能量相当于正常恒星的一百亿倍，在这个超能量的瞬间，宇宙中所有的元素都被聚变出来了。象金银首饰这种重元素，就是在超新星的爆炸中诞生的，当我们佩戴它们时，要记住宇宙制造高档产品确实是代价很高，它需要报废一颗至少比太阳大8倍以上的恒星，才能使我们披金戴银。

超新星发生在一个恒星即将结束生命时，亦即在红巨星阶段，核心燃料快要消耗殆尽时，恒星会因为没有额外的燃料而自行崩溃。如果恒星的质量够大，恒星内部的内爆层会在接触核心时反弹，产生巨大的爆裂，爆炸所产生的震波会将恒星的所有物质射入太空中。

我们的太阳将会在50亿年后衰亡，因它内部提供予核融合的燃料终於消耗殆尽。到时太阳会变成一个主要由碳和氧组成、密度高而「寒冷」的白矮星。 另一方面，一颗比太阳更重的恒星的中心温度更高。这些巨大星体会在经过一次壮观的爆炸后灭亡，这过程称为「超新星爆炸」。爆炸释出的能量非常巨大，超新星爆炸的光度可能相当於1,000亿万颗恒星同时发出的光芒。

超新星的爆发是在约一秒钟之内完成的。由於高能辐射与爆炸拋射出来的恒星大气相互作用，使得超新星也可能有X射线等辐射。例如SN1987A在爆炸后100多天才被Ginga卫星所探测到它的X射线。而光学波段的突然增亮，首先是由膨胀大气引起的，后来则由Ni56等同位素的衰变提供能量，使得光度下降较为缓慢。图五中给出了典型的超新星光变曲线。超新星爆发的高速拋射物与周围介质相互作用形成的激波引发出电波辐射，而对星周尘埃的加热则可以产生红外辐射。但这些只有周围有稠密的星际物质的II型或Ib、Ic型超新星才能观测得到。

在不到一秒钟时间内释放出10⁵¹~10⁵³erg的能量（相当於90个太阳在其一生所释放能量之总和）的天体，它的前身星是什么？产生如此巨大能量的机制是什么？这些是天文学家首先面临的问题。

首先我们来看看Ia型超新星。在它的光谱中缺少氢谱线，而且根据统计它在不同类型的星系中都有可能出现。据此天文学家提出了Ia型超新星是密近双星演化到晚期的终极结果的想法。设想有一密近双星系统，其两个成员星的质量均小於8M¤ ，其中质量大的那一个演化得比较快，在其核心燃烧完氢后，接著燃烧氦，而变成中心为碳和氧的白矮星。这时初始质量较小的那颗成员星的物质就被它吸积。假如物质转移速度小於每年10^-8M¤ 的话，在白矮星周围形成氢壳，当它达到核融合点火的温度时，其表面就产生核融合点火爆发，这就是新星爆发的现象，其规模比超新星要小得多。

当转移速率在每年10^-6M¤ ~10^-8M¤ 之间的话，表面同样会产生核融合，而形成氦，氦形成碳，逐步使其碳核心质量增加，直到钱氏 (Chandrasekhar) 极限的1.4 M¤ 。其中心密度可达到3×10⁹g/cm³，而且中心达到碳点火的温度。碳被点燃，并且融合过程从中心往外迅速传播，在不到一秒钟之内传到白矮星的最外层。其爆炸将产生10⁵³erg的能量，而且爆炸规模巨大无比，以至於将这颗白矮星完全「炸飞」了。由於白矮星中的氢已经燃烧殆尽，所以它的光谱中没有氢线，同时因为它是一种「老年」的恒星，因此会出现在不同的星系之中。

II型的超新星则不同。它的光谱中以氢线为主，而且往往出现在螺旋星系的旋臂上，在那裡往往有恒星正在形成。一个目前被广泛接受的II型超新星爆炸的模型是：一个大质量的恒星（质量大过10M¤ ），在其最初的3000万年甚至更短的时间内，它的核心首先是氢融合为氦，然后氦变为碳和氧，碳变为氖和镁，氧和镁变为硅和硫，直到最终硅和硫融合为铁属元素。上述每种融合过程都释放出大量的能量，维持著恒星的「生命」，而且其核心变得愈来愈密，温度则愈来愈高，以致能够抵抗恒星引力的收缩。但到了核心变为铁心后，由於铁属元素的核束缚能最小，融合无法继续为恒星提供能量，反而要吸收能量。引力收缩就开始，中心的密度和温度继续增大，到 10¹⁰K和10¹⁰g/cm³时，电子就被压到原子核内而形成富含中子的同位素，而高能辐射又将原子核「撕」成a粒子。这两个过程都要吸收能量，使得重力塌缩变得更快。当中心密度超过2.7×10¹⁴g/cm³时，塌缩不能继续，产生反弹而引发超新星爆发。它将外层核融合的剩余物，包括最外层的氢向外拋，而留下一个核核心，也就是中子星。所以在光谱中有强的氢线，同时因为大质量恒星（寿命短；因此我们看到的都是不久前形成的）是和恒星形成区相关的，所以他们往往出现在螺旋星系的旋臂上。至於Ib和Ic型超新星，目前也认为是一种称为「沃夫─瑞叶星」 (Wolf-Rayet stars; W-R stars) 的大质量恒星演化到晚期的结果。由於W-R星有大规模的恒星风，质量流失很大，因此表层已失去了氢甚至氦，所以其光谱中没有氢线(或甚至於氦线)。

超新星1987A(1987年发现的第一个超新星)是近代爆炸的超新星中，最靠近地球的一个，位於169,000光年外(我们银河系的伴星系)的大麦哲伦星系。它也是自从克卜勒在1604年於银河系中观测到超新星以来最明亮的一个；同时是自1885年以来第一个肉眼看得见的超新星。那原来是一个蓝超巨星的位置，其质量约为太阳的20倍。天文学家相信这个星球先是膨胀成红超巨星，在吹开一部份的星球体后，经过收缩与再加热，成为一个蓝超巨星。之后，在短短不到一秒钟，整个星球的中心突然就崩垮了，一阵微中子将中心加热至100亿度。这个过程引爆出震波，将此星球炸散掉，并喷出大量的微中子到太空中。

直至1987年5月，国际紫外线探索号已在超新星的碎片中发现了许多化学元素，显示出这个始祖星球已经过了红巨星期，证实了原来的理论。到了7月，一个日本的人造卫星和德国的望远镜都侦测到从碎片中发射出来的X光线。自8月到11月，更有其他的研究团队侦测到高能的伽玛射线，这是在即将死去的星球中心出现核反应所产生的放射性元素，衰变时所放射出来的。此资料证实了大家所相信的理论，即超新星会产生组成地球大部分的重化学元素。

 
超新星1987A影像

哈伯太空望远镜先进巡天相机 (ACS) 所拍摄的超新星1987A影像，在其四周包围著一串如珍珠项链般的气体环，这些「珍珠」其实是超新星爆发所产生的冲击波，以超过每小时6千万公里的速度追撞上了“恒星在爆炸前数万年所喷出, 膨胀速度较慢的气体”。爆震波追上了这个环，由於碰撞作用，气体受到衝击，温度升高到了数百万至1千万度，因而发出了红外辐射。环中的尘埃是在星风中形成的，而不是在超新星爆发中形成的。光环直径约一光年，光环中央的长椭圆形黯淡星体就是超新星残骸，主要受超新星爆炸时所产生放射性元素鈦 44 衰变辐射加热而发光，未来数十年都还将持续发光。天文学家在 1996 年首次在 SN 1987A 的外圈发现一个亮点，现在则可看出数十个。天文学家推测，未来几年中还将陆续出现更多类似的光点，这些亮点的光会将周围照亮，天文学家届时将可推测超新星爆炸前是如何喷发物质至太空中。当震波逐渐往外移时，产生的紫外线和X射线辐射将加热更多周围过去所喷出的物质。就如同参与钱卓研究计画的科学家理查、麦克雷所说：「超新星1987A将会点亮它自己的过去」。

超新星的爆炸使物质摆脱了引力的束缚，但铁元素的核却坠入引力的深渊，巨大的塌方把电子都压进了质子，于是质子全变成了中子，而中子之间没有电磁力的排斥，原子核可以相互紧紧的挨在一起，这就形成了最致密的物质──中子星，它一立方厘米的质量能达到十亿吨，而它引力强大到让光都要成抛物线才能挣脱。把一个几百万公里直径的物体压缩成只有30公里的直径，就是中子星，而同时被压缩的还有磁场，这是一个匪夷所思的超高能核电站，它可以把表面附着的电子象高压水柱一样喷射出去，它们所具有强烈的方向性可以成为宇宙定位的灯塔。十几年前，人类寻访外星生命的一艘飞行器上所携带的人类的自我介绍，就是用多颗中子星为地球做定位。一些大的超新星爆炸之后，将会产生引力的奇迹──黑洞，巨大的引力把物质化为无形，因为连光都要被吸回它的表面，如果把地球压缩成一个核桃，就是黑洞，因为地球其实是一个强力和电磁力支撑的物体，如果把原子核都毁灭了，地球就将成为几厘米直径的浓缩引力的载体，黑洞的存在已经被证实。

超新星是宇宙中4种力配合的杰作，它们共同建造一个巨大的原子锅炉，然后以锅炉的崩溃所激发的能量完成所有元素的制造，并且在最后的瞬间把元素都彻底的抛洒出去，正因为有这种抛洒，物质才有可能演化，否则，就象有钱不去投资，再多的财富也将没有任何意义。恒星以自身的毁灭造就了宇宙中最伟大的新生。 在超新星的物质弥漫之后，引力将会再次把这些物质凝聚成天体，大的塌缩成恒星，小的形成行星，如果这颗恒星有较长的寿命，而它的周围有若干合适的行星围绕，那么这个长寿的核能和比较靠近它的行星上丰富的宇宙元素的光和热交流，就可能最终产生宇宙中最复杂的物质形态──生命。

上一篇文章我们知道了Eclipse弹出菜单的基本用法。其实Eclipse的弹出菜单可以用来做很多文章，简单一点的根据文件类别，我们可以进行不同的文件操作，比如Ant的build.xml我们可以用来build，Java文件我们可以用Java Editor打开，这些基于文件类型的操作我们都可以很容易的实现。但是还有一种情况，如果文件类型一样，我们想进行不同的操作，该怎么实现呢？实际上这样的应用很多，比如同样是Java文件，含有main方法的Java文件有Run和Debug的选项，其它的都没有。还有现在的框架都是基于XML文件进行配置的，如果一个项目使用了多个框架，我们怎么根据不同的XML文件进行框架的区分呢？答案就是enablement的test。

<!ELEMENT test EMPTY>
<!ATTLIST test
property CDATA #REQUIRED
args     CDATA #IMPLIED
value    CDATA #IMPLIED>

This element is used to evaluate the property state of the object in focus. The set of testable properties can be extended using the propery tester extension point. The test expression returns EvaluationResult.NOT_LOADED if teh property tester doing the actual testing isn't loaded yet.

• property - the name of an object's property to test.
• args - additional arguments passed to the property tester. Multiple arguments are seperated by commas. Each individual argument is converted into a Java base type using the same rules as defined for the value attribute of the test expression.
• value - the expected value of the property. Can be omitted if the property is a boolean property. The test expression is supposed to return EvaluationResult.TRUE if the property matches the value and EvaluationResult.FALSE otherwise. The value attribute is converted into a Java base type using the following rules:
  • the string "true" is converted into Boolean.TRUE
  • the string "false" is converted into Boolean.FALSE
  • if the string contains a dot then the interpreter tries to convert the value into a Float object. If this fails the string is treated as a java.lang.String
  • if the string only consists of numbers then the interpreter converts the value in an Integer object.
  • in all other cases the string is treated as a java.lang.String
  • the conversion of the string into a Boolean, Float, or Integer can be suppressed by surrounding the string with single quotes. For example, the attribute value="'true'" is converted into the string "true"

比如我们要让含有main方法的Java文件它的右键弹出菜单包含一个额外的选项“This is main class”，需要编写如下的Plugin.xml：

我们需要检测在当前情况下是否需要显示这个菜单项，使用扩展点org.eclipse.core.expressions.propertyTesters：
<!ELEMENT propertyTester EMPTY>
<!ATTLIST propertyTester
id         CDATA #REQUIRED
type       CDATA #REQUIRED
namespace  CDATA #REQUIRED
properties CDATA #REQUIRED
class      CDATA #REQUIRED>

id - unique identifier for the property tester
type - the type to be extended by this property tester
namespace - a unique id determining the name space the properties are added to
properties - a comma separated list of properties provided by this property tester
class - the name of the class that implements the testing methods. The class must be public and extend org.eclipse.core.expressions.PropertyTester with a public 0-argument constructor. 

这里只须注意propertyTester的namespace和properties正好对应test的property。

至于检测的逻辑我们在advancedpopupmenus.popup.actions.VisablePropertyTester中实现，这个类必须继承自org.eclipse.core.expressions.PropertyTester。

我们只要判断接受的Java文件中是否含有main方法，如果有，则返回True，没有则返回False。

如果我们是要接受一个Web开发的配置文件，我们可以这样写：

这几天阅读GEF 相关的几篇文章：

http://benisoft.com/cn/java/AShapeDiagramEditor_zh.htm

http://blog.popsoft.com/more.asp?name=saden5&id=6591

http://www.blog.edu.cn/user1/19180/archives/2005/372857.shtml

看下来感觉不错，有些收获，尤其是createEditPart，两个参数，EditPart是上下文，另一个是Model，有可能用到项目的Property Editor上面，根据上下文和传入的Model来控制界面的显示。GEF的这段代码可以用来研究研究。

public class PartFactory implements EditPartFactory {
     public  EditPart createEditPart(EditPart context, Object model) {
         EditPart part = null ;
         if (model instanceof Diagram)
            part = new DiagramPart();
         else if(model instanceof RectangleModel) {
              part = new RectanglePart();
      }
        part.setModel(model);
        return  part;
    }
}

至于GEF，感觉只要有入门文章，再看看项目上的代码，上手很容易，如果要做出复杂的应用，还要在研究研究它的API。八进制的文章写得基本上很清楚了，

BTW:Eclipse 有些view是绝佳的查看代码的工具，比如Type Hierarchy视图，Call Hierarchy视图都非常有用。真是不用不知道呀！  

GEF我严重低估了它的学习周期，原因是我一直无法把握它的全局架构。了解了这一点之后，我首先从GEF的设计着手研究。

在表现层上，GEF采用的是EditPartViewer，所有的用户界面都在上面显示，一般采用的是Draw2d。Draw2d上所有的图形都是实现了IFigure接口，所以实际上EditPartViewer上放置的都是一些IFigure。当用户针对EditPartViewer做出了一些动作，实际上都是对某个IFigure提出了请求。每一个IFigure都对应了一个控制器EditPart，EditPart也是一个事件监听器，用来捕获用户的操作事件。

每一个EditPart都可以对应若干个EditPolicy。所有的用户请求分类都被认为是一种角色（Role），当EditPart收到一个用户请求以后，就会分析这个请求属于哪一种角色，然后将请求交给相应的EditPolicy进行处理。EditPolicy根据请求创建相应的Command，通过Command就可以操作GEF背后的Model，达到通过操作图形来操作Model的效果。由于EditPolicy是和Role对应的，而不绑定于EditPart，所以实际上针对不用的EditPart，EditPolicy能达到重用的效果。

public int getAdvanceWidth(char ch)

Returns the advance width of the specified character in the font which is currently selected into the receiver.

The advance width is defined as the horizontal distance the cursor should move after printing the character in the selected font.

Parameters:

ch - the character to measure

Returns:

the distance in the x direction to move past the character before painting the next

Throws:

SWTException -

• ERROR_GRAPHIC_DISPOSED - if the receiver has been disposed

  public static int getStringWidth(String string,Control control){

      int width = 0;
      GC gc = new GC(control);
      for(int i=0;i<string.length();i++){
            char c = string.charAt(i);
            width += gc.getAdvanceWidth(c);

      }

      gc.dispose();

      return width;
  }

iBatis 和 Hibernate 是目前最流行的2种O/R框架，但是两者差别也很大。由于某些原因，我必须学习Hibernate。其实这两种工具我觉得有一种就可以畅行无阻，实无两者都学习的道理。但是Java社区偏偏喜欢重复发明轮子，人在江湖，身不由己呀，想不学都难。

初期的时候，我并无采用任何框架的习惯，喜欢用自己的一套O/R工具，其实用自己的工具也无可厚非，但是使用一套成熟的框架有一个极为令人诱惑的附加效果：稳定性。既然称之为成熟的框架，那么就必然是健壮、应用的。于是我开始接触iBatis和Hibernate，总体而言iBatis比Hibernate更容易上手的多，它就是简单的SQL Mapping，没有面向对象形式的继承，仅仅就是把一张表映射到一个POJO上，一个平面的体系，很容易构造。一个查询对应一个自己手工编写的SQL，相当灵活，完全由自己控制。我想很适合那些自己设计表结构，自己编写O/R部分的开发人员。使用iBatis基本上就是一个傻瓜式的开发，不需要考虑对象之间的关系，也就是one and more。只要你会使用SQL，你就可以快速上手。

Hibernate我没有做过实际项目，目前处于学习状态，很难说这个东西到底是好是坏，不过就代码而言，我更喜欢iBatis的参数设置方式，传递一个key或者一个map就可以了，框架帮你自动映射。而不是Hibernate的那种JDBC式的传参方式，丑陋无比，不能自动映射，必须手工一一对应。

实际上iBatis是一个O/R toolkit，而Hibernate是一个O/R Manager，更多地参与了对象实体的管理。采用Hibernate，就要去应用面向对象的一些设计理念，也就是对象的继承体系，要和数据库的设计关联起来。可以这样来说，iBatis建立的是一个二位体系，而Hibernate建立的则是一个三位体系。从这个意义上来说，采用iBatis和Hibernate，2者对代码底层架构甚至是数据库的设计有质的影响。基本上来说，只要有表结构，就可以采用iBatis。而如果想采用Hibernate，大概数据库设计也要按照OO的思维模式来设计了。

iBatis学习曲线温和，只要会SQL就可以进行开发了，不过因为是直接操作SQL，所以在跨数据库方面就比较笨拙了，而且对表结构进行修改的时候，所有的相关部分，包括xml配置文件，映射class类，执行类都需要修改。Hibernate基本上SQL由它自动生成，通过设置Dialect可以实现在不同数据库之间的切换，而基本上不需要修改代码。不过个人感觉这个东西上手还是蛮复杂的，当然我指的并不是简单应用，而是把一个iBatis应用转化为Hibernate应用。

回头再写一些代码，应该能够对Hibernate有更实际的了解。对于Hibernate的关系，我已经从DOOP里学到了，剩下的就是它的关联、继承以及组件了。

　　在情感世界，我觉得“拒绝”和“被拒”，都需要勇气。
　　“拒绝”并不代表赢了。但凡两个人以上合作的游戏，只有水乳交融才叫成功。即使你本人是提出拒绝的那位，不见得领了风骚，实逼于鸣金收兵。
　　对还爱的人说“不”，是很不容易的，左手是泪，右手是恨。
　　话一出口，就得面对它，承认它，就此打落门牙和血吞，全靠年轻气盛，勇气少一点，就很难吞下。岁月流转，做人很难，做永远相亲相爱的恋人难之又难。
　　有时无辜被拒，有时无情拒人，这就是爱恨交织的人生吧。

　　我本以为自己对爱情领悟的还算透彻，实际上爱情这个东西，真的是千变万化，令人琢磨不透，经历的越多，才发现爱情越复杂。君不见现在流行的情歌全都不尽相同？拥有一份爱情，可以让人感到无限的幸福和希望，但同样它也是烦恼的滋生地。人总是生活在矛盾之中，总是喜欢明知不可为而为之。我一向认为自己是一个无欲无求的人，但依然还有无尽的烦恼。人不能只为自己活着，还要为自己身边的人活着。人的烦恼十有八九都是自找的，所谓知足者常乐，但是能做到者又有几何。

　　仿佛总是生活在大喜大悲之中，冥冥之中我学会了乐观做人，以悲观的思想来面对感情。现实社会的道德伦常已经完全被新的文明所颠覆。本来简简单单的我经历了小说一般的爱情，曾经的我没有选择放弃，没有选择拒绝，今后的我同样也不会，就算是小说，也要按照我自己的方法书写下去。

　　人生终归是要继续走下去的……

我最喜欢的歌词：

你出现我身边像个奇迹发生
没想到会是你让我如此失魂
我心中的感觉是这样陌生
快乐的牵挂在相聚的每一分
曾以为我见过所有爱的可能
这一刻才明了我有多么天真
想给你全世界一刻我都不愿等
想要你的心却怕不能成真
因为你有你的人生我有我的旅程
在前方还有等着你的人
你会哭会笑会爱会伤神
你会不会敲我的门
虽然你对我的认真我也感动万分
你终究不是属于我的人
但记得在你孤单的时候
我会伸出双手
我会是你朋友到永久