摘要: Groovy 是一种利用其他语言（如 Ruby、Jython 和 Smalltalk）中的特性的动态语言。Groovy 在 Java VM 上运行，并使任何现有的 Java 对象（以及所有 API）可用于 Groovy。Groovy 当前遵循 JSR-241 中的标准；您可以在 Groovy 网站及其项目主管 (Guillaume Laforge) 的网志中了解有关该语言的详细信息。
Grails 之于 Groovy 相当于 Ruby on Rails 之于 Ruby。（该名称最初为“Groovy On Rails”，现在已改为“Grails”以避免混淆/竞争。）与 Ruby on Rails 一样，Grails 用于创建 CRUD（创建、读取、更新、删除）Web 应用程序。您可以在 Grails 网站及其项目主管 (Graeme Rocher) 的网志中了解有关 Grail 的详细信息。
阅读全文
摘要: Groovy 的 Eclipse 插件能够编辑，编译以及运行 groovy 脚本和类
阅读全文
摘要: 经典大片，国人骄傲，不容错过！
阅读全文
摘要: 今天我无意间看到了一个Grails与RoR(Ruby on Rails)的性能比较，觉得有必要与各位还不了解Grails的朋友分享一下，以消除对Grails的神秘感甚至误解：
阅读全文
摘要: Groovy: The Sleeping Giant
阅读全文
摘要: Groovy轻松入门系列教程之Grails实战基础篇，高效开发不是梦！
阅读全文
摘要:
阅读全文
摘要: 多次转载，链接与题目均已丢失，无法注明，向原作者致歉！
闻者伤心，见者流泪～
阅读全文
摘要: Groovy轻松入门系列教程之搭建Groovy开发环境
阅读全文
摘要: 将Spring2.0.2升级至2.0.3须谨慎！
阅读全文
摘要: 2007年Groovy好事连连，不容错过！
阅读全文
摘要: 通过比较Groovy与Java的不同点和相同点，快速掌握Groovy :-)
阅读全文
摘要: 让我们来回顾一下主流语言的发展历程：机器语言(由01组成) -> 汇编语言 -> ... -> C语言 -> C++ -> Java -> ?
不知道大家有没有发现在语言发展过程中，存在这么一个规律：
阅读全文
摘要: Groovy高效编程之统计单词频率，展现Groovy的魅力 :-)
阅读全文
摘要: 想必关注Java的朋友不会没有听说过Groovy吧？的确，由于Groovy的语法与Java极其相近，所以对于我们这群Java狂热分子特别友好。Groovy对于有Java基础的朋友来说，几乎可以说是唾手可得！
阅读全文
Ruby的语法可以借鉴，但其本身的实现就免了
说Ruby是一种没有光明前途的语言的原因：
Ruby的Thread是伪线程,不管代码中写了多少个Thread.new,Ruby都只启动了一个线程去运行这些Thread的代码。
这样做的确使得Ruby的Thread很容易控制，程序也不容易产生类似死锁这类严重的线程问题。但是效率始终无法提高，因为在ruby进程中，实际上只有一个真实的线程在运行，同样的代码在那么多核或者多cpu的电脑上运行效率和单核cpu的电脑上的效率并不会相差多少。
你目前在工作站上用的CPU时钟速度是多少？10GHz么？ 2001年8月Intel芯片就达到2GHz，按照2003年前的CPU发展趋势推算，到2005年初，我们就能拥有第一块10GHz的Pentium芯片。但实际上没办到。而且情况好像越来越糟——我们根本就不知道到底在什么时候这样的芯片可以出现。
那么放低期望，4GHz又如何呢？目前我们已到3.4GHz——那么4GHz已经不远了吧？唉，好像4GHz也遥不可及。可能你知道，Intel首先于2004年中将4GHz芯片的发布时间推迟到2005年，而到了2004年秋季，则彻底取消了4GHz计划[译注11]。在本文写作的同时，Intel宣布计划到2005年早期，实现到3.73GHz（即图中的右上最高处）的微量提升。所以，至少就目前来说，时钟速度的竞赛实际上结束了，Intel和其他大多数处理器厂商将把旺盛的精力投入到多核等方向去。
也许，我们某天在主流PC里能装上4GHz的CPU，但2005年别想。Intel实验室里的确已经有运行在更高速度的芯片——不过代价是惊人的，比如庞大数量的冷却装置。你想不久在你的办公室里就有这样的冷却设备，坐飞机的时候，就把它们放在你膝盖上？别做梦了！
如果应用程序想充分利用CPU吞吐增加量，那它们就必然日益需要并发，这种形势逐渐明朗，并将在接下来的数年里深入发展。Intel已经扬言未来他们会推出集成100颗内核的芯片，那么单线程应用最多就只能利用这种芯片1/100的潜在生产力。“哦，性能没那么重要吧，计算机总是跑得越来越快”的论调已经变得天真而可疑，甚至在未来不久将完全错误。
总结一下我的观点：
CPU性能提升途径主要是靠实现多核，靠提高主频是没有多大希望了，而单线程仅仅能利用单核资源，严重浪费了多核CPU提供的性能，不幸的是，Ruby的线程是伪线程，即始终仅有一个线程在执行，随着软件的日益庞大，Ruby将不得不求助于CPU主频的提升，但像前面所说的那样，4G都是一个遥不可及的目标，别提10G甚至更高了。我坚信，RoR终有一天不堪重负，被Java击溃！
摘要: 迅雷一道算法题的解答 :-)
阅读全文
每个问题有很多种解法，但其中存在一种最优的算法，据我观察和思考，‘懒人’是写不出那种最优算法的，为什么呢？因为最优算法有一个很明显的特点就是算法本身集结了人类的聪明才智，让我来用一个实例来证明这个观点：问题：
请计算当参数为 n(n很大) 时, 1-2+3-4+5-6+7+......+n 的值
‘懒人’解法：
public class Lazy {
public static void main(String[] args) {
int n = 10000;
int result = 0;
for (int i = 0, flag = 1; i < n; i++) {
result += flag * (i + 1);
flag = -flag;
}
System.out.println(result);
}
}
‘勤人’解法：
public class Diligent {
public static void main(String[] args) {
int n = 10000;
int result = 0;
if (0 == n % 2) {
result = -n / 2;
} else {
result = -n / 2 + n;
//由于-n / 2会舍弃小数部分，所以无需写成-(n - 1) / 2
}
System.out.println(result);
}
}
人类的智慧为计算机担负了不少的计算量，“懒人”算法的时间复杂度为O(n)，而“勤人”算法的时间复杂度仅为O(1)，这题的最优算法出世了！
忠告各位喜爱编程的朋友，在解决问题之前，请可怜可怜您使用的那台精疲力尽的计算机吧，花些时间思考一下，您付出的一分一秒都会有回报的 :-)
摘要: 如果您对选择Ruby还是Python犹豫不决的话，这篇文章很适合您 :-)
如果想找一种能与Java真正无缝结合的动态语言，我吐血推荐Groovy ( http://groovy.codehaus.org )，JVM上的JCP官方标准语言。
阅读全文
摘要: 小弟关注Groovy已有数月(您可以到Groovy官方网站 http://groovy.codehaus.org 下载)，发现其极具魅力，故在我参加的学校'创新试验项目'中，就用它来实现最简易的ORM，做的非常简单，主要原因是没有时间，因为小弟学业繁重，所以抽出一个下午的时间来实现一个简易版的ORM，数据库用的是MySQL。现在简单说明一下所示代码，将User类的一个实例通过save方法保存到数据库中，然后再根据给定条件通过findBy方法从数据库中取出实例，最后删除一个特定实例。由于深知通过XML文件进行配置的痛苦，所以在设计时没有用到任何XML文件。此程序让程序员只需关注自己要处理的对象，而不用关心数据库方面的东西，简化开发过程。最后我想说明的是，由于时间问题，所以编码方面只注重算法的体现，没有考虑其他方面。下面给出的代码仅供演示及参考(源码已经上传，点击下载)：
阅读全文