2010年12月5日
#
Java 8之前，同一注解不能在相同的目标元素上多次使用，例如，如下的注解在Java 8之前是不允许的：
public class SampleClass {
@Quality("Security")
@Quality("Performance")
@Quality("Readability")
public void foo(){
//
}
}
Java 8引入了Repeatable注解（@Repeatable）可以解决这一问题，但光有可重复的注解定义还不够，还需要它的容器注解，两者一起来实现可重复注解的使用。实例如下：
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
@Repeatable (Qualities.class)
public @interface Quality {
String value();
}
@Target(ElementType.METHOD)
public @interface Qualities {
Quality[] value();
}
其中，Quality是可重复注解，由@Repeatable注解标明，它的容器注解是Qualities，用于存放所有可重复的Quality（存贮在Quality[]中）；同时还要注意可重复注解和它的容器注解的目标元素必须是一样的（这也不言自明）。如此这般，我们最开始的
SampleClass 在Java 8环境下就可以安全使用了。
以下单例实现思想来自《Java Design Patterns: A Programmer's Approach》.
该方法利用了Java缺省的Lazy类实例化机制克服了传统单例模式实现中Lazy实例化方式的不足。
public class Singleton {
private Singleton(){}
public static Singleton getInstance(){
return Helper.instance;
}
static class Helper {
private static Singleton instance = new Singleton();
}
}
以下转自StackOverflow（
http://stackoverflow.com/questions/5074063/maven-error-failure-to-transfer），亲测可用。
This worked for me in Windows as well.
- Locate the {user}/.m2/repository (Using Juno /Win7 here)
- In the Search field in upper right of window, type ".lastupdated". Windows will look through all subfolders for these files in the directory. (I did not look through cache.)
- Remove them by Right-click > Delete (I kept all of the lastupdated.properties).
- Then go back into Eclipse, Right-click on the project and select Maven > Update Project. I selected to "Force Update of Snapshots/Releases". Click Ok and the dependencies finally resolved correctly.
当我们写Groovy脚本代码的时候，有时会发生编译错误，如下：
- Groovy:Invalid duplicate class definition of class XXX : The source XXXX\XXX.groovy contains at least two
definitions of the class XXX.
- The type XXX is already defined
原因在于Groovy会把.groovy代码文件作为脚本或类定义来处理，例如如下代码：
class Order {
def security
def value
private buy_sell(su, closure) {
security = su[0]
quantity = su[1]
closure()
}
def getTo() {
this
}
}
def methodMissing(String name, args) {
order.metaClass.getMetaProperty(name).setProperty(order, args)
}
def getNewOrder() {
order = new Order()
}
Integer.metaClass.getShares = { -> delegate }
Groovy会把上述代码作为脚本处理，同时缺省用文件名来作为一个外围类类包括整个脚本程序，此时，如果该文件名恰好也是Order的话，那么就会出现重复的类定义错误提示。
解决办法是将脚本文件名取另外一个不同的名字。
已经申请OCUP中级考试的学员可以在一年内（截止到17年9月份）免费申请OCUP2中级考试的资格（原有考试仍可以参加）。此外，2014年3月份之后参加了原有OCUP中级认证考试的学员可以免费申请OCUP2中级认证考试。详见OMG网站声明（http://www.omg.org/ocup-2/exam-info.htm）。
搬家总是难免的，但旧家的东西不能带走难免会留下些许遗憾，希望它们能永远留下来.......
欢迎光临我的新家：
http://blog.sciencenet.cn/?53016 （科学网）
转自网络。
3岁，他去上幼儿园了，看着他小小的坚强的背影，心中又喜悦又有点小小的心酸。离别了一整天，孩子看到你高兴得奔跑过来，扑在你的怀里。跟你说：妈妈，我想你了。那一刻，抱着孩子就像抱着了整个世界。
6岁，他上小学了，孩子终于走进校门，这是多么值得纪念的事情，孩子的人生从此翻开了新的篇章，却没想到，这也是孩子离开我们的第一步。他已经对与你分开一天习以为常了，而且他喜欢每天去学校，这是他更喜欢的生活。甚至，他有时还会说：妈妈，在家好无聊，没有小朋友和我玩。
12岁，他上初中了，甚至有的开始上寄宿学校，一个月或者几个月回一次家，见上一次面。他们开始不再依赖你，甚至，他们喜欢和你对着干。你想帮他们做点事情，他们说:妈妈，我自己来吧。突然觉得这句话让我们觉得好失落，孩子是不是不再需要我们了？
18岁，他离开你去上大学，一年回来两次。回来的好几天前，家里的冰箱就装不下了，为他准备了各种各样他喜欢吃的东西。可是一回来打个照面，他就忙着和同学朋友聚会去了。从此，你最怕听到的一句话是：妈妈，我不回家吃饭了，你们自己吃吧。
大学毕业后，孩子留在了远方工作，一年也难的回来一次了。好不容易回来一趟，几天就走了。你最盼望的就是孩子的电话，希望，孩子对你说一声：妈妈，我很好，你保重身体。这样就足够了。
孩子结婚了，回家的时间有一半匀给了你的亲家，孩子回来的更少了。你已经习惯就老两口在家了，但是，你最希望听到孩子对你说：妈妈，今年过年我回家过啊！
当孩子又有了他们自己的孩子，你已经不再是他们的家庭成员了，他们的一家三口（或一家n口）里，已经不包括你们了。
而我们也慢慢的习惯了这样的日子。只是习惯在闲来无事的时候，经常翻翻相册，看看我们自己的一家三口，无论孩子身在何方，他却永远是我们家庭中无可取代的一员。
是啊，其实当孩子在身边的日子，我们是多么幸福。可是有时我们却还会抱怨。抱怨因为他，你做了太多的牺牲。抱怨他晚上老醒来，让你睡不好，抱怨他无理取闹，抱怨他爱撒娇长不大，抱怨他生病，让你操碎了心，抱怨为了培养他，花费了太多的精力与金钱...可是，如果你想想，10多年后，就算你想要，也没有机会了。孩子会不停的长大，过了这个时期他就再没有这个时期的习性。你是不是常常在他断奶后怀念喂他吃奶的日子，可是那时你却觉得好累好辛苦好厌倦。是不是常常看他以前吃手的照片觉得好可爱，可是你曾经却为要不停的给他洗手而烦恼透了。是不是在他褪去童声后，特别想念他曾经奶声奶气的声音，可是他以前撒娇的时候你却很不受用。是不是当孩子去上学后你特别怀念他黏在你身边的日子，可是以前你却总在想他要什么时候才能去上学啊。。。
时间无法倒流，过去了就只能永远过去了。孩子能呆在身边的日子是多么难得与宝贵。因为这一点，我更加的珍惜与孩子相处的每一刻，也让我无论遇到什么，都心存感恩。谢谢上天给我这么一个孩子，让我分享与见证他成长的每一刻。无论带给我多少困难，烦恼，甚至挫败，无论让我失去多少睡眠，时间，金钱，精力，我仍然豁达，因为，这都是上天的恩赐。
当他在身边的每一天，我都会让他觉得幸福，也是让我们都有一个美好的回忆。我不会给他太多压力，束缚，更不会给他牵绊，阻扰，但是我会适时管教，也会做量力而行的投资，因为我有责任与义务教会他生活的本领，好让他来日自由快乐的飞翔。同时，我也会告诉他，就算所有的路都行不通时，还有一条路你可以畅行，那就是回家的路。。。。。。。。
今日编辑一PDF文件（用的是Adobe Acrobat Pressional 7.0），删除了几页，然后保存，结果文件大小反而增加了；而删除几页后另存，则文件大小减少。
你也试试看。
Robert L. Glass在《Negative Productivity and What to Do about It》（详见IEEE Software, September/October 2008, p. 96）阐述了自己对那些影响项目进度的人的亲身感受和对此应采取的解决方案。
作者以个体差异开头（作者指出，在软件工程文献中提到过非常大的个体差异：28:1 (for error identification) to 25:1 (for coding ability) to 11:1 (for timing efficiency) to 6:1 (for sizing efficiency)。但不幸的是，这些差异并没有得到我们足够的认识，作为实践者，我们不知道如何鉴别出那些是别人28倍生产力的人，他们对于按时交付高质量的软件非常重要；作为研究者，在案例研究中也没有对个人进行足够的区分，这将导致对结果的误读。），然后引出对项目进展带来负作用（影响项目进度）的人''(someone who has negative productivity—that is, someone whose inclusion on a project actually makes the project less efficient.)''，接着以自己的亲身经历的三个例子做了阐述：
1. Disfunctional labor relations. 项目（与软件无关）组被抽走一人，却发现生产力提高了；这个案例让作者意识到项目中存在让人不易觉察的对项目生产力产生负影响的人；
2. Moral rebellion. 作者所带领的项目组中存在一个对公司存在性不认同的人，导致项目进度滞后，使作者受到了软件职业中最差的评价；
3. Overly high standards. 作者所在的项目组由于一个对质量要求非常严的QA，总是对提交的产品不满意，结果导致产品迟迟不能交付。
对待这些人，作者给出了自己的解决方案：解雇他们。''(If someone on your project is deliberately delaying its progress, there’s probably only one reasonable solution. Fire them! If you don’t, your team will be sorry, your company will be sorry, and, quite likely, you’ll be sorry as well!)''