精通Java MEAP：现代开发技术与多语言实践

4星 · 超过85%的资源需积分: 9 9 浏览量更新于2024-07-26 1 收藏 6.34MB PDF 举报

"The Well Grounded Java MEAP" 是一本专为Java开发者设计的书籍，旨在深入探讨Java 7的特性，如try-with-resources和NIO.2，并介绍新兴的基于JVM的语言，如Groovy、Scala和Clojure。书中通过实用的例子帮助读者掌握现代开发流程、并发性、性能优化等众多有价值的技术。本书分为四个部分： **Part 1: Developing with Java 7** 这部分首先介绍了Java 7的关键特性。"Introducing Java 7"章节讲解了Java 7的新特性，如自动资源管理（try-with-resources）和非阻塞I/O（NIO.2），这些改进显著提高了Java的效率和易用性。这部分内容将帮助读者巩固Java 7的基础知识，理解如何在实际项目中应用这些新功能。 **Part 2: Vital techniques** 这部分探讨了开发过程中的核心技术。"Dependency injection"章节讲解了依赖注入，这是一种常见的设计模式，可以提高代码的可测试性和可维护性。"Modern concurrency"章节深入讨论了Java的并发处理，包括线程安全、并发集合和并发工具，这对于构建高性能、多线程的应用至关重要。此外，"Understanding performance tuning"章节提供了性能优化的策略和技巧，帮助开发者提升应用程序的运行效率。 **Part 3: Polyglot programming on the JVM** 这部分引入了JVM上的多种语言。"Alternative JVM languages"章节概述了Groovy、Scala和Clojure等语言的优势和应用场景。"Groovy: Java's dynamic friend"展示了Groovy的动态性，它简化了代码并提供了脚本语言的灵活性。"Scala: power and conciseness"探讨了Scala的强大功能和简洁语法，它结合了面向对象和函数式编程的优点。"Clojure: safer programming"则强调了Clojure的内存安全和并发特性，以及其在处理复杂数据结构时的优势。 **Part 4: Crafting the polyglot project** 这部分关注的是采用多种语言进行项目开发的实践方法。"Test-driven development"章节倡导测试驱动的开发方法，强调编写可验证的代码。"Build and continuous integration"章节讲述了构建管理和持续集成的重要性，以及如何利用工具实现自动化。"Rapid web development"章节介绍了快速构建Web应用的策略和技术。最后，"Beyond ground level"章节探讨了更高级的主题，可能包括微服务架构、分布式系统等。书的附录包含了更多资源信息、Spring配置示例和全局术语表，为读者提供了进一步学习和参考的材料。《The Well Grounded Java Developer》是一本全面而深入的指南，适合那些希望扩大技能范围、了解Java生态系统的开发者，以及对JVM上其他语言感兴趣的读者。通过这本书，读者不仅可以提升Java 7的使用技巧，还能掌握多语言开发的现代方法，从而成为一名更加全面的开发者。

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=725

This is an important change, for the simple reason that virtually no-one gets manual

handling of resource closing 100% right. Until recently, even the reference howtos from Sun

were wrong. The proposal submitted to Project Coin for this change includes the astounding

claim that 2/3 of the uses of

close() in the JDK had bugs in them!

Fortunately, compilers can be made to excel at producing exactly the sort of pedantic,

boilerplate code that humans so often get wrong, and that's the approach taken by this

change.

As an example, let's consider some Java 7 code for saving code from the web. As the

name suggests,

url is a URL object that points at the entity we want to download, and file is

a File object where we want to save what we're downloading.

Listing 1.3 Java 7 Syntax for Resource Management

try ( FileOutputStream fos = new FileOutputStream(file);

InputStream is = url.openStream() ) {

byte[] buf = new byte[4096];

int len;

while ((len = is.read(buf)) > 0) {

fos.write(buf, 0, len);

}

This basic form shows the new syntax for a block with automatic management – the try with

the resource in round brackets. For C# programmers, this is probably a bit reminiscent of a

using clause – and that's a good conceptual starting point when working with this new

feature. The resources are used by the block, and then automatically disposed of when

you're done with them.

This is a big help in writing error-free code. To see just how much, consider how you

would write a similar block of code to read from a stream coming from a URL and write to a

file with Java 6.

Listing 1.4 Java 6 Syntax for Resource Management

InputStream is = null;

try {

is = url.openStream();

OutputStream out = new FileOutputStream(file);

try {

byte[] buf = new byte[4096];

int n;

while ((n = is.read(buf)) >= 0)

out.write(buf, 0, n);

} catch (IOException iox) {

} finally {

try {

out.close();

} catch (IOException closeOutx) {

Licensed to <simon.rydberg@transrail.se>

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=725

}

} catch (FileNotFoundException fnfx) {

} catch (IOException openx) {

} finally {

try {

if (is != null) is.close();

} catch (IOException closeInx) {

}

#A Handle exception (could be read or write)

#B Can't do much with exception

#C Handle exception

How close did you get? The key point here is that when handling external resources,

Murphy's Law applies – anything can go wrong at any time.

 The InputStream can fail to open from the URL or

 to read from it or

 to close properly

 The File corresponding to the OutputStream can fail to open or

 to write to it or

 to close properly or

 some combination of more than one of the above

This last possibility is actually where a lot of the headaches come from – the possibility of

some combination of exceptions is very difficult to deal with well.

This is the main reason for preferring the new syntax – it's just much less error prone –

the compiler is not susceptible to the mistakes which basically every developer will make

when trying to write this type of code manually.

One other aspect of TWR is the appearance of enhanced stack traces and suppressed

exceptions. Prior to 7 exception information could be swallowed when handling resources.

This possibility also exists with TWR, so the stack traces have been enhanced to allow the

developer to see the type information of exceptions that would otherwise be lost. For

example, consider this snippet, in which a null

InputStream is returned from a method:

try(InputStream i = getNullStream()) {

i.available();

}

This will give rise to an enhanced stack trace, in which the suppressed NPE is seen:

Exception in thread "main" java.lang.NullPointerException

at wgjd.ch01.ScratchSuprExcep.run(ScratchSuprExcep.java:23)

at wgjd.ch01.ScratchSuprExcep.main(ScratchSuprExcep.java:39)

Suppressed: java.lang.NullPointerException

Licensed to <simon.rydberg@transrail.se>

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=725

at wgjd.ch01.ScratchSuprExcep.run(ScratchSuprExcep.java:24)

... 1 more

TWR and AutoCloseable

Under the hood, the TWR feature is achieved by the introduction of a new interface, called

AutoCloseable, which a class must implement in order to be able to appear as a

resource in the new TWR try clause. Many of the Java 7 platform classes have been

converted to implement AutoCloseable (and it has been made a superinterface of

Closeable) – but you should be aware that not every aspect of the platform has yet

adopted this new technology. It is included as part of JDBC 4.1, though.

For your own code, however, you should definitely use TWR whenever you need to work

with resources – it will help you avoid bugs in your exception handling. As a helping hand,

Java 7 ships with a tool which you can run over user code to detect places where

AutoCloseable can help.

1.3.5 Diamond Syntax

One of the problems with generics is that the definitions and setup of instances can be really

verbose. Let's suppose that you have some users, whom you identify by a userid (which is

an integer) and each user has some lookup tables (possibly more than one), and the tables

are specific to each user. What would that look like in code?

Map<Integer, List<String, String>> usersLists = new HashMap<Integer,

List<String, String>>();

That's quite a mouthful, and almost half of it is just duplicated characters. Wouldn't it be

better if we could just write something like:

Map<Integer, List<String, String>> usersLists = new HashMap<>();

and have the compiler just work out the type information on the right hand side? Thanks to

the magic of Project Coin – you can. In Java 7 the shortened form for declarations like that is

entirely legal. It's backwards compatible as well – so when you find yourself revisiting old

code, you can just cut the older, more verbose declaration and start using the new type-

inferred syntax to save a few pixels.

For the curious, we should point out that the compiler is using a new form of type

inference for this feature. It is actually working out the correct type for the expression on the

right hand side, and is not just substituting in the text which defines the full type.

The Name

This form is called “Diamond Syntax” because, well, the shortened type information looks

like a diamond. The proper name in the proposal is “Improved Type Inference for Generic

Licensed to <simon.rydberg@transrail.se>

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=725

Instance Creation”, which is a real mouthful, and has ITIGIC as an acronym, which just

sounds stupid – so Diamond Syntax it is.

1.3.6 Simplified Varargs Method Invocation

This is one of the simplest changes of all – it just moves a warning about type information

for quite a specific case where varargs combines with generics in a method signature.

Put another way – unless you're in the habit of writing code that takes as arguments a

variable number of references of type T and does something to make a collection out of them

then you can move on to the next section. On the other hand, if this bit of code looks like

something you might write, you should read on:

public static <T> Collection<T> doSomething(T... entries) {

...

}

Still here? Good. So what's this issue all about?

Well, as you probably know, a varargs method is one which takes a variable number of

parameters (all of the same type) at the end of the argument list. What you may not know is

how varargs is implemented – basically, all of the variable parameters at the end are put into

an array (which the compiler automatically creates for you) and are passed as a single

parameter.

This is all well and good, but here we run into one of the admitted weaknesses of Java's

generics – you are not normally allowed to create an array of a known generic type. So, this:

HashMap<String, String>[] arryHm = new HashMap<>[2];

won't compile - you can't make arrays of a specified generic type. Instead, you have to do

this:

HashMap<String, String>[] warnHm = new HashMap[2];

That gives a warning which has to be ignored. Notice that you can define warnHm to be of

the type array-of-

HashMap<String, String> - you just can't create any instances of that

type, and instead have to hold your nose (or at least, suppress the warning) and force an

instance of the raw type (which is array-of-HashMap) into warnHm.

These two features – varargs methods really working on synthetic arrays that the

compiler conjures up; and arrays of known generic types not being an instantiable type –

come together to cause us a slight headache. Consider this bit of code:

HashMap<String, String> hm1 = new HashMap<>();

HashMap<String, String> hm2 = new HashMap<>();

Collection<HashMap<String, String>> coll = doSomething(hm1, hm2);

Licensed to <simon.rydberg@transrail.se>

http://www.manning-sandbox.com/forum.jspa?forumID=725

The compiler will attempt to create an array to contain hm1 and hm2 – but the type of the

array should strictly be one of the forbidden array types. Faced with this dilemma the

compiler basically cheats and breaks its own rule about the forbidden array-of-generic-type.

It creates the array instance, but grumbles about it, producing a compiler warning which

mutters darkly about "uses unchecked or unsafe operations".

From the point of view of the type system, this is fair enough. However, the poor

developer just wanted to use what seemed like a perfectly sensible API, and now there are

these scary-sounding warnings for no adequately explained reason.

HAT'S CHANGED IN JAVA 7

The new feature which comes in 7 is to change the emphasis of the warning. After all, there

is a potential for violating type safety in these types of constructions, and somebody had

better be informed about them. There's not much that the users of these types of APIs can

really do, though. Either the code inside

doSomething() is evil and violates type safety, or

it doesn't. In any case, it's out of the API user's hands.

The person who should really be warned about this issue is the person who wrote

doSomething() - the API producer, rather than the consumer. So that's where the warning

goes – it's moved from the site of use of the API to the site where the API was defined.

The warning used to be triggered when code which used the API was compiled. Instead,

it's now triggered when an API is written which has the potential to trigger this kind of type

safety violation. The compiler warns the coder implementing the API – and it's up to him or

her to pay proper attention to the type system.

To make things easier for API developers, Java 7 also provides a new annotation type,

java.lang.SafeVarargs. This can be applied to an API method (or constructor) which

would otherwise produce a warning of the type discussed above. By annotating the method

with

@SafeVarargs, the developer is essentially asserting that the method does not

perform any unsafe operations. In this case, the compiler will suppress the warning.

HANGES TO THE TYPE SYSTEM

That's an awful lot of words to describe a very small change – moving a warning from one

place to another is hardly a game-changing language feature – but it does serve to illustrate

one very important point. Earlier in this chapter we mentioned that Project Coin encouraged

contributors to mostly stay away from the type system when proposing changes.

This example shows how much care is needed when figuring out how different features of

the type system interact, and how that interaction will alter when a change to the language

is implemented. This isn't even a particularly complex change – larger changes would be far,

far more involved – with potentially dozens of subtle ramifications.

This final example illustrates how intricate the effect of small changes can be – and

completes our discussion of the changes brought in by Project Coin. Although they represent

mostly small syntactic changes, they can have a positive impact on your code which is out of

proportion with the size of the change. Once you've started using them in practice you will

hopefully find that they offer real benefit to your programs.

Licensed to <simon.rydberg@transrail.se>

剩余393页未读，继续阅读

sunnyy333

粉丝: 0
资源: 1

精通Java MEAP：现代开发技术与多语言实践

The Well Grounded Java Developer

The.Well-Grounded.Java.Developer(2012.7)

grounded-segment-anything

Grounded-Segment-Anything

write a nrf24L01 communication demo, witch controlled by stm8s

CPW GCPW的区别

how ATEtest a Power Switch IC

FileNotFoundError: [Errno 2] No such file or directory: '/home1/lpj/Grounded-Image-Captioning-master/coco-caption/pycocoevalcap/wmd/data/GoogleNews-vectors-negative300.bin'

Write an essay about 150 words. Statec learly what you stand for. Give convincing reasons for your arguments.

Y ou Truly Understand What I Need : Intellectual and Friendly Dialogue Agents grounding Knowledge and Persona

最新资源