Groovy实战：Java开发者的工具宝典

需积分: 6 142 浏览量更新于2024-08-02 收藏 5.3MB PDF 举报

"Groovy Recipes Greasing the Wheels of Java.pdf" 本书《Groovy Recipes Greasing the Wheels of Java》是针对Java开发者的一本实用指南，它将Groovy介绍为一款强大的工具，可帮助开发者高效地处理各种任务。Groovy是一种动态、灵活的编程语言，它与Java紧密集成，为Java开发环境提供了便利。这本书的核心在于提供一系列解决实际问题的代码“食谱”，使得开发者能够快速解决遇到的问题，而不仅仅是理论讲解。书中的读者评论强调了这本书的价值，例如，作者Jason Rudolph指出，这本书是Java开发者快速解析Atom feed、从Grails应用服务Excel电子表格或创建tarball的理想手册。书中的每节内容都以实际代码开始，直接展示解决问题的方法，读者可以选择立即应用，或者深入阅读详细的解释。 Dierk König，来自Canoo Engineering AG的评论家，认为这本书就像他在Groovy开发中的得力助手，提供了日常任务的精心设计的解决方案，能帮助开发者快速上手并提高工作效率。 Joe McTee，一位软件工程师，评价该书的格式非常适合在需要时迅速获取关键信息，是一本适应敏捷开发节奏的书籍。他还认为Groovy作为Java领域的重要趋势，这本书能帮助读者快速掌握其核心并应用到实际项目中。书中的内容涵盖了多个方面，包括但不限于Groovy的基础语法、脚本编程、XML和JSON处理、Web服务交互、Grails框架的应用以及文件操作等。通过这本书，读者可以学习如何利用Groovy的强大功能来提升Java开发的效率和灵活性，同时享受到Groovy简洁且富有表达力的代码风格。此外，书中可能还会涉及Groovy与Java的互操作性，如如何在Java项目中嵌入Groovy脚本，以及如何利用Groovy的闭包和元编程特性来简化代码。对于想要扩展Java技能集的开发者来说，这本书无疑是一个宝贵的资源，它能帮助他们更好地理解和运用Groovy，从而提升开发工作的质量和效率。

GROOVY, THE WAY JAVA SHOULD BE 16

1.1 Groovy, the Way Java Should Be

roovy w as expressly designed to appeal to Java developers. Groovy is

Java at the end of the day. The other languages that r un on the JVM

are just that—other languages. The point of JRuby

is to get existing

Ruby code running on the JVM. The point of Jython

is to get existing

Python code running on the JVM. The point of Groovy is to integrate

with your existing Java code.

I’m not trying to diminish the value of those other languages. If you

already have an existing codebase implemented in another language,

the beneﬁts are undeniable. But how do they beneﬁt Java developers

with an existing Java codebase? Groovy and Java are so compatible

that in most cases you can take a Java ﬁle—foo.java—and r ename it to

foo.groovy. You will have a perfectly valid (and executable) Groovy ﬁle.

That trick won’t work with any of y our oth er neighbors on the JVM.

But more than language-level compatibility, Groovy allows you to dra-

matically reduce the amount of code you would normally wr i te in Java.

For example, let’s start with a simple Java class named Person.java that

has two attributes, ﬁrstName and lastName. As Java developers, we are

trained from a tender young age to create public classes with private

attributes. All outside access to the attributes is routed through public

getters and setters.

Java

Code

public class Person {

private String firstName;

private String lastName;

public String getFirstName() {

return firstName;

}

public void setFirstName(String firstName) {

this.firstName = firstName;

}

public String getLastName() {

return lastName;

}

public void setLastName(String lastName) {

this.lastName = lastName;

}

2. http://jruby.codehaus.org/

3. http://www.jython.org

Download at Boykma.Com

GROOVY, THE WAY JAVA SHOULD BE 17

I’m not arguing with established Java practices. Encapsulat

ion offers

many beneﬁts. Unfortunately, it comes w i th a heavy verbosity tax.

It took us more than twenty lines of code to deﬁne a class that has two

attributes. Each new attribute will cost us six more lines of code f or

boilerplate getters and setters. The fact that modern IDEs will generate

the requisite getters and setters for us doesn’t make the problem go

away; it makes the symptoms only slightly less painful.

What does the corresponding Gr oovy class look like? You can rename

Person.java to Person.groovy and the ﬁle will compile, but it is hardly

idiomatic Groovy.

What Java developers ﬁrst notice about Groovy is its brevity. Good

Groovy code is Java boiled down to its essence. You can see this imme-

diately in the Groovy version of the Person class:

Groovy

Code

class Person {

String firstName

String lastName

}

Yes, that’s all there is. Even better, it’s a drop-in replacement for the

Java class. Compile it down to bytecode, and t he Groovy version is

indistinguishable from it s Java counterpart. You’ll need to have groovy.

jar in your classpath, but with that in place your Java code can seam-

lessly call any plain old Groovy object (POGO) in lieu of a POJO with

the same name and ﬁelds.

All POGOs ar e public by default. All attributes are private. There are

getters and setters for each ﬁeld, but these methods are autogenerated

in the bytecode rather than the source code. This drops the 6:1 code

ratio for new ﬁelds down to exactly 1:1. Looking at t his POGO compared

to the Java class, there is noth i ng more that could be left out. It i s the

core of the POJO with all the syntactic noise stripped away.

Of course, you could slowly begin adding Java language features back

in one by one.

You could certainly use semicolons if you prefer. You could explicitly say

public class Person and private String ﬁrstName. There is n oth i ng stopping

you from having getters and setters in your source code.

Download at Boykma.Com

GROOVY: THE BLUE PILL OR THE RED PILL? 20

replacement for Java without changing any of the semantics of

the Java

language. This should appeal to conservative organiz ations.

In “red pill” mode, Groovy introduces new language constructs that are

different from Java. File.eachLine is a clos ure—it is a whole new way

to iterate over a ﬁle without using java.util.Iterator. Closures are being

considered for in clusion in Java 1.7, yet you have them ri ght her e,

right now. This should appeal to folks who are envious of cool features

in other languages, wishing Java could do similar things.

Perhaps James Strachan said it best on August 29, 2003, when he

intr oduced the world to a little open source project he had been work-

ing on. In a blog entry

titled “Groovy: The Birth of a New Dynamic

Language for the Java Platform,” he said this:

“Dynamically typed languages like Ruby and Python are g etting quite

popular it seems. I’m still not convinced we should all move to dynami-

cally typed languages any time soon—however, I see no reason why we

can’t use both dynamically and statically typed languages and choose

the best tool for the job.

“I’ve wanted to use a cool dynamically typed scripting language specif-

ically for the Java platform for a little while. Ther e’s plenty to choose

from, but none of t hem quite feels right—especially from the perspec-

tive of a die-har d Java programmer. Python and Ruby are both pretty

cool—though they are platforms in their own right. I’d rather a dynamic

language that builds right on top of all th e groovy Java code out there

and the JVM.

“So I’ve been musing a little while if it’s time the Java platform had

its own dynamic language designed from the ground up to work real

nice with existing code, creating/extending objects normal Java can

use, and vice versa. Python/Jython [is] a pretty good base—add the

nice stuff fr om Ruby and maybe sprinkle on some AOP features, and

we could have a really groovy new language for scripting Java objects,

writing test cases, and, who knows, even doing real development in it.”

That i s how Groovy got both its name and its worldview. Groovy is

a language that takes on the characteristics you’d like it to take on.

Traditional Java development made easier or a way to get all those

exciting new features from other languages onto the JVM? The answer

is both.

4. http://radio.weblogs.com/0112098/2003/08/29.html

Download at Boykma.Com

剩余253页未读，继续阅读

missedone

粉丝: 0

Groovy实战：Java开发者的工具宝典

Groovy and Grails Recipes.pdf

Groovy.in.Action.2nd.Edition.pdf

Groovy入门教程[参照].pdf

groovy.lang.GroovyRuntimeException: Could not find matching constructor for: groovy.xml.MarkupBuilder(java.nio.channels.Channels$1)

groovy java.lang.IllegalArgumentException:argument type mismatch

Groovy使用javax.servlet.http.HttpServletResponse

最新资源