Java 7深度开发指南：掌握最新特性和多语言编程

5星 · 超过95%的资源需积分: 10 123 浏览量更新于2024-07-29 1 收藏 2.62MB PDF 举报

"TheWell-GroundedJavaDeveloper.pdf"是一本深入讲解Java 7的教材，专为想要掌握最新Java技术的开发者设计。该书籍共分为四个部分，旨在提供全面且实用的知识。 **Part 1: Developing with Java 7** 这部分主要介绍Java 7的新特性，包括： 1. **Introducing Java 7**：章节详细阐述了Java 7的升级内容和改进，让读者对新版本有一个全面的认识。 2. **New I/O**：Java 7引入的新的I/O处理机制，提高了性能和开发效率。 **Part 2: Vital Techniques** 这部分关注关键编程技术的实践： 3. **Dependency Injection**：讲解依赖注入的设计模式，帮助开发者构建松耦合、可维护的系统架构。 4. **Modern Concurrency**：探讨Java 7在并发编程方面的增强，如改进的多线程工具和并发控制机制。 5. **Class Files and Bytecode**：深入理解Java类文件和字节码，这对于性能优化至关重要。 6. **Understanding Performance Tuning**：提供了优化代码性能的基础知识和策略，确保应用程序高效运行。 **Part 3: Polyglot Programming on the JVM** 这部分探讨在Java虚拟机上使用其他语言的可能性： 7. **Alternative JVM Languages**：介绍了可以与Java无缝集成的其他脚本语言和动态类型语言。 8. **Groovy, Java's Dynamic Friend**：强调Groovy如何作为Java的补充，提供动态编程的灵活性。 9. **Scala, Power and Economy**：展示了Scala的静态类型和函数式编程特性，以及其简洁性。 10. **Clojure, Safer Programming**：Clojure作为一种更安全的编程范式，如何提升开发体验。 **Part 4: Crafting the Polyglot Project** 这部分着重于项目管理和多语言协作： 11. **Test-driven Development**：提倡测试驱动开发的重要性，确保代码质量。 12. **Build and Continuous Integration**：讲解构建工具和持续集成实践，提升开发效率。 13. **Rapid Web Development**：如何利用现代Web框架快速构建和部署应用。 14. **Beyond Ground Level**：这部分可能涵盖了高级主题，如设计模式、架构原则等，以提升开发者的专业技能。附录A提供更多信息来源，B包含Spring配置示例，C则是关于glob语法的解释。这本书不仅适合初学者系统学习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 Mei Zhu <mzhu2005@gmail.com>

©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 Mei Zhu <mzhu2005@gmail.com>

©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 Mei Zhu <mzhu2005@gmail.com>

©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 Mei Zhu <mzhu2005@gmail.com>

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 Mei Zhu <mzhu2005@gmail.com>

剩余192页未读，继续阅读

gaopengxiang417

粉丝: 0
资源: 12

Java 7深度开发指南：掌握最新特性和多语言编程

TheWell-GroundedJavaDeveloper

2进制3位数过去现在将来输赢公式代码.txt

福州大学在广东2021-2024各专业最低录取分数及位次表.pdf

WordPress 集网址、资源、资讯于一体的导航类主题开心版

【Java学习】activemq消息中间件学习demo.zip

爬取淘宝热销(热门)手机支架商品信息公开透明的数据集

【目标检测数据集】斧子数据集2396张VOC+YOLO格式（含增强60%）.zip

南昌大学科学技术学院在广东2021-2024各专业最低录取分数及位次表.pdf

南京财经大学红山学院在广东2021-2024各专业最低录取分数及位次表.pdf

武昌首义学院在广东2021-2024各专业最低录取分数及位次表.pdf

最新资源