你好，很惭愧，今天才发现你的日志。最近我也在做一个P2P的东西，前期要要开发一个简单的P2P平台，就是那种最简单的。可是实现对等点发现，资源发现，文件传输就行，但是感觉有力不从心，不知道你能不能给点建议。
邮箱da_fen_qi@163.com
诚侯赐教！

呵呵，只关注开发相关功能！

eclipse的自动更新是千呼万唤到了3.4才改进了些，

国内的网络用自动更新就是折磨自己啊，装个东西要几个小时

你好 我是出版社的编辑，我看到你博客中的内容，现在有一本Eclipse的书正在找人写。如果对写书有兴趣可以和我联系
我的邮箱：books_522008@yahoo.com.cn
或者加我的MSN：pyq_19852008@hotmail.com

可以了，在M4才加进去的p2，以后会越来越好的

结对编程有个好处，你不好意思当着另一个同事的面去看新闻泡论坛，所以大部分时间始终围绕工作和技术

希望金蝶网站越来越好

希望金蝶友商网能越办越好

这个事情还是很有意义的！
特别是并发方面

Java越来越复杂了...:-(

是件好事情啊！不错不错啊！

请问：
有无小型纺织行业的会计核算软件

对于web-rpc我用的就是json-rpc(现在叫jabsorb)，当然我们又做了修改，以便和spring结合，另外去掉了初始化的过程。
DWR的协议，还有国内的一些哥们写的RPC的协议不太喜欢，DWR的人说他们会支持多种协议，并且说他们的功能比json-rpc强，反正我们用不着。

我也在用json-lib的时候,对date类型有些困惑

我就发现 像 Map　这些类型，实在是不好转换，　如果你试用过 Dorado　它的处理方式也差不多，　只是按规定写方法。　也不知它们的安全性如何保证的。

这也只是在javascript的前提下

@久城
如果你使用json-lib，可以让对象实现JSONString接口，另外json-lib有一些配置参数，但是json-lib做的不好。

@Strive
既然你做的RPC，就应该使用方法的签名自动转换JSON数据到目标类型。[]格式的JSONArray转到目标的ArrayList是很容易的事情啊

请教一下，在server -> client时，大家用什么方法把Java Object输出成json String?

我弄了一个 RpcSide 但是不知道如何控制权限, 可以前台调后台类,整合了Spring 按规范方式书写方法就能调用, 不知道 ArrayList 这些是如何解析回来, 普通的 String Number Boolean Date都能解析,而且不慢, 请楼主能给一个好的解决方案来处理 js Array 到 Java ArrayList 互相转换,传输,还有 AJAX安全处理的机制?>

现在也在用json
和jquery完美搭档

json是不错，不过我的建议是在server -> client单向使用，不用json lib，在输出时写个几十行的程序就可以把Java object输出成json string，毕竟jscript是json的舞台。

json的确在某些方面比xml使用起来方便。但是对于xml，用xpath选择层次比较深的节点，是不是比用json又更好呢？

有意思哦

AOP素个好东西，现在的实现上的问题只是因为sun不肯自己去写一个改bytecode的API而已。
OpenSource里面的东西没有经过严谨的测试自然会有这样那样的问题。
不过估计sun最后自己会拿一个版本去改个官方的实现。
至于在大项目中的应用，2005年一个上千人月的项目中就用了。

AOP也不是OO的竞争伙伴，而是弥补OO的不足。


现在的框架我觉得也不需要全理解，搞得很高手，很有技巧，因为这种东西一方面还在完善中，一方面新陈代谢很快。应该去理解它的思想，知道他应该干什么，怎么去做。基本就够了。

楼主我看是把理论和实现混淆了。
一个东西，理论可能很先进，但是实现起来会有这样那样的问题。
不过实现的不好不代表这个理论就废掉了。

现在潮流的大方向是简单化，傻瓜化，提高生产性，降低技术难度。所以hibernate,aop,包括Linq应运而生，这是需求的产物。在大规模开发中，从资金，时间都不可能要求coder们都有很高手的水平，牺牲一定的性能提高开发效率是大势所趋。或许再过10年，就不需要你写什么SQL了，在ER图里拖拖拉拉就可以生成SQL，和现在做网页一样。呵呵。

hibernate我也看过它的一点源代码。hibernate的优点我看主要是轻量级的封装，它里面的设计也很好，我看起来很轻松。至于HQL，把数据库关联的部分再抽象出来，思路正确，但也不是多复杂的东西。
对被EJB2.1折磨过的我来说，这样一个简单易用易于二次开发的框架，的确是很满意了。

其实hibernate和SQL倒没什么对立，只不过把SQL封装了一下。

呵呵……
编程还是打字啊

XP我认为只适用于小项目或者进行产品前期预研，规模大一点的项目还是走正规的研发流程更好一些，否则一团糟。

XP 的精髓
我想大家都明白我们都在干什么.本质是还是解决问题.
解决问题,在不同的环境下有不同的解决办法,没有适用于所有环境的方法.全部口口都是软件工程,软件工程是干什么的.我们想明白没.

确实听荒唐的，我更愿意把“结对编程”当成代码走查或者培训新员工的手段，至于JDO，呵呵，有几个人用JDO呢。不过没有闹剧这个世界就没有了趣味了。

@太阳里的雪
谁说的?
至于分库分表，关键在于设计，和使不使用Hibernate没有关系。

orm肯定不适合那些大型网站，如到时候的分库分表等，显得无能为力。

O/R Mapping是一个伟大的技术，它使程序员可以将大部分精力放在业务逻辑上，而不会为数据库这端的编程有后顾之忧。但是任何技术都不是银弹，可以解决一切问题，hibernate也留了sql query的口子，博主完全可以施展自己在SQL上的超深造诣，何必为了一点的不方便而大放厥词呢？照博主这么说，中国也不要改革开放了，大家一起穷死算了。

1）关系型数据库模式的提出和 SQL 语言的发明：

1970 年 IBM 研究中心的 E.F.Codd 博士提出了关系型的数据库模式，奠定了关系型数据库日后发展的理论基础，并为此于 1981 年荣获计算机科学界的最高荣誉奖 ACM 图灵奖。1973年 IBM 研究中心开始了一个大的关系型数据库系统研究项目 System R，探讨并验证在多用户与大量数据下关系型数据库的实际可行性。在 D.Chamberlin 博士的领导下System R的一个研究小组发明了一套比关系微积分与关系代数更适合最终用户使用的非程序化查询语言 SQL [Chamberlin74，76，80]。从此，基于 SQL 的关系型数据库逐渐成为了数据库管理系统的主流。目前所有的关系型数据库厂家的产品都遵循这一标准。由于 System R 与SQL 对关系型数据库管理系统结构的贡献，其主要设计人员于 1988 年获得了计算机领域中崇高的实用软件系统奖。

2）分布式数据库概念及对面向对象的支持：

80年代初期至中期，IBM艾玛登研究中心的研究人员通过System R*研究项目[Lindsay84]探讨分布式数据库的实现技术，其研究成果为日后的分布式关系型数据库架构标准DRDA（Distributed Relational Database Architecture）以及建立数据仓库常用到的数据复制等机制提供了技术来源。

1984 到 1992 年，IBM艾玛登研究中心开始了一项名为 Starburst 的大型研究计划[Haas90，Lohman91]，旨在建立新一代的、具延伸性的关系型数据库原型。所谓延伸性是指数据库各子系统实现开放性，使用户能够很容易地把新功能加注到一个 SQL 关系型数据库里，以便支持新的应用。通过把类似面向对象的抽象数据类型（Abstract Data Type）与继承性（Inheritance）融入 SQL 语言及关系型数据库核心的做法，Starburst容许系统内部与外部的功能被延伸。与此同时 Starburst 研究人员在查询改写优化处理（query rewrite optimization），特别是索引结构（specialized indices），日志预写恢复技术（recovery method based on write-ahead logging），主动数据库技术（active database）等方面皆有创新的贡献。Starburst 的研究项目产生了大量的修正基本数据库结构的文献与专利。如同 System R 推动了 SQL 关系型数据库的商业化一般，Starburst提供了新一代商用对象关系型数据库（Object-relational Database）宝贵的经验与技术来源。

DB2 在面向对象数据库技术上的发展目标是对象关系型数据库，它是以关系型数据库的架构为基础，加入面向对象的功能。这有别于所谓的 OO Database，OO Database 不是关系型数据库，而是以对象为目的所建立的一种新数据结构。现在计算机科学界以及数据库工业在面向对象的走向方面，是以这种对象关系型数据库为主流。DB2 面向对象的技术及其实施领先群雄。当其它数据库公司还在探讨面向对象技术融入数据库的可能性时，IBM就已在1995 年推出这些最先进的东西。它在新的数据库国际标准（SQL3）的研讨和形成上，也一直处于领导者地位，它完善的 OO 结构已经存在于产品内核里。IBM 正以滚雪球的惊人速度在开发其他更先进的功能，例如对复杂数据的更深层次优化，抽象数据类型（Abstract Data Type）等等。

对象数据库DB4O应用也比较广泛,虽然目前主要集中在嵌入式应用中.随着技术的发展,理论的发展(关系型数据库理论自其出现以来这么多年已经很成熟\稳定),不排除对象数据库大放异彩的一天.

不可否认,ORM在增删改的操作上的确可以简化开发量,但对于查询,尤其是复杂查询,还是得通过SQL来完成,并征对不同的数据库进行优化.

表一棒把人打死，技术本身就它的有优点和缺点的

幼稚，Glassfish的JPA包算是JSR规范的reference package,当然没有author

别的都不说你了，还是老老实实去写两个框架再来评价别人的东西

框架看多了 也会审美疲劳的。。。呵呵，不管啥技术，能给老总带来￥就是好技术。

技术场景不同，归根结底，IT是服务于业务的，当然也有用于纯计算的，不过市场份额不大。对我们没有用的东西不一定对别人也没有用。
比如说，有人对数据库操作性能要求很高，关系很复杂，数据量很大。那么他可能考虑不用Hibernate而直接用JDBC或其他更底层的方式。就好象操作系统的内核为了效率要使用一部分汇编一样。但是更多的情况可能不是如此。

sorry，看错了，作者是认为AOP式日志是个不恰当的例子，这点我赞成，不过对于AOP技术只是“小技巧”的评价绝不敢苟同。

温少好像没用过hibernate和AOP。
ORM和关系数据库不是矛盾竞争的关系，是合作的关系。

不了解的东西不要开口
AOP不能用于生产环境？spring的事务处理就是用AOP实现的，那么世界上这么多在跑的应用都是玩具咯？对于ruby和hibernate的评价就不多说了，不了解的东西不要开口。
作者是中了OO的毒了

非常同意作者对ORM的观点。.NET下的Linq在错误的方向上走的更远。用Hibernate或JPA进行复杂的查询和自杀相差无几。我觉的可行的方法是，用Hibernate或JPA作数据的增删改操作，用iBatis作查询。

看你初学，不说你了。以后这种无知文章不要乱发表，很黄，很暴力啊

Ruby，一个小脚本语言，只是因为动态类型、mixin之类的功能...
--------------------------------------------------
这就是你的观点？
严谨一点吧。

看你对hibernate都不了解
更被说ruby了 可笑

写代码时,打字已经成为下意识的了.

原来JKD1。6在LINUX下的NIO是实现自EPOLL的。。但是不知道怎么设置LT或ET模式？

那方案3其实就是在多机的时候，id分成两个部分而已，一个实际是机器id，另一个是实际的本机id。
感觉为了追求id长度短，有点过份设计了，实际应用应当对这个长度要求很低，使用固定长度完全可以，毕竟你的环境也不会有100个以上的独立系统。

@simon.xu
你说的方法在过去的系统中用过，每次递增一批，这算是方案2的改进。使用方案3，在种子上作一些处理之后，能够更好实现全局唯一，可以确保不同服务器不同的数据库分配出来的ID唯一。

从我博客主站上看：
http://www.cnblogs.com/jobs/archive/2007/11/16/961116.html

评论更多，描述了更详尽的情况。