深入探索Java隐藏特性

需积分: 6 162 浏览量更新于2024-07-22 收藏 2.97MB PDF 举报

"Java Secrets" 是一本面向已经掌握Java语法和基础面向对象编程知识的读者的书籍。作者Elliotte Rusty Harold通过本书揭示了Java中未被Sun官方文档覆盖、不易获取且在其他众多书籍中鲜有提及的深层次内容。书中分为三个部分：Java的工作原理、太阳微系统的类（The Sun Classes）以及平台依赖的Java。在Part I - How Java Works中，作者首先指出，一些小知识可能会带来危险，他提醒读者深入理解Java的重要性。这部分会探讨Java的核心秘密，揭示Java内部运作的机制。 Chapter 1 - Introducing Java Secrets 提到，本书不是对基本语法和AWT的重复介绍，而是专注于那些隐藏的、不常见的Java特性。作者提到，这些秘密可以为开发者提供更广泛的适用性，更大的编程力量，并激发创新思维。这些秘密来源于哪里？除了官方文档，源代码和API文档也是重要的知识来源。尽管Java强调跨平台性，但书中所揭示的内容可能具有特定平台的依赖性，这也是为何它们未被广泛记录的原因。在Chapter 2 - Primitive Data Types中，作者深入讲解了Java中的基本数据类型。他探讨了内存中的字节表示，变量、值和标识符的概念，以及二进制、十六进制、八进制等数值表示法。对于整型（如int、long、short和byte），他解释了它们的存储方式。浮点数部分则涉及二进制表示法下的特殊值，如非规范化浮点数。此外，还讨论了字符类型CHAR，包括ASCII、ISOLatin-1和Unicode编码，特别是UTF-8的用法。布尔类型boolean也在其中，以及跨平台时需要注意的字节序问题。 "Java Secrets"是一本深入探讨Java内在机制和不为人知特性的书籍，适合希望进一步提升Java技能的专业人士阅读。它不仅涵盖了原始数据类型的细节，还揭示了Java平台下不常见的编程实践，为读者提供了超越基础知识的新视角。

sounds, however. In fact, it’s a little worse than that. Only applets that run in a Web browser or an applet viewer can play sounds.

Applet subclasses that you instantiate in main() or embed in your own programs cannot play sounds because they don’t have an

AppletContext.

Secret: There really isn’t any good reason for restricting sound playing to applets. Applications of all sorts often need to

play sounds. By using the sun.audio classes, you can play sounds in all your Java programs, not just your applets.

More power

Secret: The sun packages let you do things you just can’t do otherwise. For example, suppose you wanted to build an IDE

for Java development and actually use Java. To accomplish this, you need to compile files, debug them, and run them. All

the hooks to do that are in the undocumented sun.tools package.

Inspiration

The sun classes are often a fertile source of ideas. Although many of the classes and packages are incomplete, they often provide a

pattern on which you can model your own, more functional classes.

Secret: For example, the sun.net.nntp.NntpClient class lets you open groups, list the articles in the groups, request

specific articles, and post new articles. That’s useful, but some obvious methods are missing. There is no method to get a

list of all the newsgroups on the server, for example. You can use the sun.net.nntp.NntpClient class as a model for your

own NNTP class that does know how to get a list of all the available newsgroups and a lot more. Furthermore, your class

can fix some of the bugs in Sun’s NntpClient class.

Sometimes you can create your own classes by extending Sun’s; some-times you’ll copy and paste; sometimes you’ll write your own

classes from scratch using a similar API. Whichever you choose, it’s almost always easier to start with a good design and correct

some minor deficiencies than it is to design a class from scratch.

Of course, not all of Sun’s designs are good. Sometimes you can learn from the mistakes made in the sun classes so you don’t repeat

them. Not every class described in this book actually performs as advertised, and I’ll be sure to tell you when that’s so. One reason

that some classes and packages are undocumented is that they’re buggy, poorly designed, or incomplete. Learning from your

mistakes is good. Learning from someone else’s mistakes is even better. You can learn from Sun’s mistakes.

Where Did the Secrets Come From?

Some people have asked how I discovered this information. To be perfectly honest, it really wasn’t that hard. Sun has not gone to

particularly great lengths to hide Java’s internal structure from nosy eyes.

Previous Table of Contents Next

Java Secrets

by Elliotte Rusty Harold

IDG Books, IDG Books Worldwide, Inc.

ISBN: 0764580078 Pub

Date: 05/01/97

Buy It

Previous Table of Contents Next

Where is the documentation?

Until this book, there have been three main sources for information about Java internals. The first source is alpha releases. Far more

of Java’s internals tend to be exposed and documented in alpha versions than in later releases. Although many details have since

changed, the HotJava 1.0a3 release provides a broad picture of many otherwise undocumented features that remain in Java 1.1.

Alpha versions of other technologies like the Java Web Server (originally called Jeeves) and Remote Method Invocation (RMI) can

be similarly useful.

While a technology is being developed, it’s often completely open for inspection because Sun hasn’t yet decided which parts to

document and which to hold to themselves. Once the product is shipped, however, previously open classes can be closed off. This is

one reason why the alpha versions of Java still reveal a great deal of information that is otherwise unavailable. Of course, as time

passes, these alpha versions become a progressively less reliable guide to current technology, so any information garnered in this

fashion must be verified and tested. Nonetheless, an alpha version is often a useful starting point.

The second source of information is the source code itself. The JDK includes source code for all the classes in the java packages.

Furthermore, Sun freely licensed the full source code for Java 1.0 for non-commercial use, such as for education and personal

edification. Regrettably, this commendable policy of openness has been rescinded with Java 1.1. Now, source code for the sun

classes is available only to commercial licensees willing to shell out big money. Nonetheless, the available source code for the java

packages and for Java 1.0 still reveals much that is not obvious from the official documentation.

The third source of information is first-hand communication with Sun’s Java team. Regrettably, but necessarily, this access has so far

been restricted mostly to Sun commercial licensees lsuch as Netscape and Symantec. It is not reliably available to the general public.

However, many members of the Javasoft team do participate in various Java newsgroups and mailing lists and do post information

that hasn’t been revealed through more official channels. The Sun-sponsored mailing lists for unreleased products seem to be

particularly fertile sources for direct interaction with Javasoft team members. Programmers are often more loquacious about their

thoughts, ideas, and problems when they’re still looking for a solution than they are once they’ve found it.

Although these are all useful things to avail yourself of, the average programmer should hardly be expected to use these informal and

incomplete mechanisms as his or her sole source of information. This book is therefore designed to collect and organize much

information that has been previously either inaccessible or inconvenient to come by for the vast majority of Java programmers.

The source code

Prior to Version 1.1, Sun made the source code for the Java Development Kit (JDK) fairly freely available. It was not difficult to get

a source code license for personal or educational use. In addition, both Java 1.0 and 1.1 included the source code for the Java classes

in the base distribution. However, full source code for the JDK 1.1 is now available only to Java’s commercial licensees and a few,

select others such as the Linux development team. Apparently the commercial licensees were more than a little peeved that Sun was

giving away what they had paid substantial sums of money for, so Sun began restricting access to the source to make them happy.

This policy may or may not be relaxed in the future.

Nonetheless, you should get a license to the source code for whatever version you can come by, even if it’s a few releases out of

date. Some classes have changed a great deal, but many are substantially unchanged since the early alphas.

Previous Table of Contents Next

Java Secrets

by Elliotte Rusty Harold

IDG Books, IDG Books Worldwide, Inc.

ISBN: 0764580078 Pub

Date: 05/01/97

Buy It

Previous Table of Contents Next

The API documentation

The javadoc documentation generally covers only the public and protected members of a class. This is not enough, especially when

you’re trying to do things Java’s designers didn’t mean for you to do.

In particular, methods and fields that have default or package access may in fact be relevant to your classes. These are the members

that do not have an access specifier; they are not declared as public, private, or protected. For example,

int value;

InputStream getData();

Vector tokenize();

There are probably more members with package access in the classes in the Java class library than there are members with protected

and private access combined. Methods and fields with no access specifiers are accessible only from within the package in which

they’re declared.

Note: In versions of Java before 1.1b3, although these package access members could be invoked only by other classes in

the same package, subclasses in different packages could override these methods and fields. In these cases, another

method in the package might call one of the overridden methods. The superclass’s behavior could be affected by the

change in the overridden method, so by overriding a package member, you could change how any method that used the

member behaved. Sun eventually decided this was a bug and fixed it in Java 1.1b3. This behavior is still present in virtual

machines based on Java 1.0, however, and there are times when this is the best option. For example, you see in Chapter 12

that creating new encoders and decoders requires you to override these package access methods. In fact, the class was

designed under the assumption that you would do this. Now that this is no longer possible, you have to create new classes

in the sun.misc package instead.

Why bring this up now? Because often the only way to ensure that your overriding method does not unexpectedly interfere with the

proper workings of a class is to carefully inspect the source code. By looking at the source, you can see what a method is supposed to

do and what will change if you make it do something else.

Furthermore, although applets are expressly prohibited from adding new classes to existing packages, applications are not. When you

build a stand-alone application, you can build it in such a way that you add new classes to existing sun or java packages. You can

even completely replace existing classes if you prefer to use one of your own devising. It’s better to avoid this if you can, but there

are times when you have no other choice. In Java 1.0, the only way to do a reverse lookup on an IP address (that is, to convert a

dotted quad address like 204.178.32.1 into an Internet hostname like utopia.poly.edu) was to add a new package to the java.net

package. You should try to avoid doing this if you can, but when you have to do it, you might as well do it right. The more you know

about the internal workings of the classes with which you’ll be interfacing, the less likely you are to unintentionally break something

else.

Note: The bug that required this hack is fixed in Java 1.1.

What Versions of Java Are Covered?

You may rightly ask what versions of Java this book covers. The answer is “quite a few.” Although the documented parts of Java are

well defined with version numbers and release dates, the undocumented parts described here are much less clear.

Nonetheless, I’ve chosen to focus on Java roughly as found in Sun’s JDK 1.1. I’ve chosen to focus on Sun’s JDK because it is the

most widely distributed implementation of Java, especially when all of the other Java environments derived from it are factored in.

Netscape’s Java virtual machine is based on Sun source code, for example. Even virtual machines that were written independently

such as Roaster Technologies’ Roaster VM for the MacOS use Sun’s JDK class library with a few modifications.

I’m focusing on Version 1.1 because it’s the most current version of Java at the time of this writing. Even though right now 1.0.2

VMs are built into most Java-aware browsers, the life span of Java software is considerably shorter than the life span of Java books.

The only way to avoid getting drowned by the fast-moving Java tidal wave is to stay as close to the front of the wave as possible. I

expect that by the time you’re reading this, Java 1.1 will be in common use everywhere, and I hope that any further developments

won’t make too much of what’s described here obsolete.

During the four months I spent writing this book, Sun’s Java JDK went through three beta releases and two release versions (1.0.2,

1.1b1, 1.1b2, 1.1b3, and 1.1), and this doesn’t even count any of the many releases by third parties. This has given me some practical

experience at gauging what is and what is not likely to change. Surprisingly, I’ve discovered that the undocumented parts of Java

change far more slowly than the documented parts.

Between 1.0.2 and 1.1, the .class file format and the virtual machine barely changed at all. The sun packages were expanded and

some bugs were fixed, but very few classes were deleted or changed in incompatible ways. To the best of my knowledge, nothing in

the sun classes was marked as deprecated, compared to many extremely common methods like action() and readLine() in the java

packages. In fact, some of the sun classes appear to have been unchanged, aside from recompilations, since the 1.0 pre-beta. They

probably would have lasted even longer had not changes to the language specification between alpha and beta broken more or less all

of the existing source code. It does not appear that anybody is actively working on many of these classes. It therefore seems unlikely

that they’ll change suddenly and unexpectedly.

Some Objections

Even the idea of Java SECRETS disturbs some people. Java is not supposed to need a book of secrets. It is supposed to be a truly

open system that anyone can implement from freely available, well-documented specifications. It is supposed to provide everything a

programmer needs. This is only partially true, however.

Previous Table of Contents Next

Java Secrets

by Elliotte Rusty Harold

IDG Books, IDG Books Worldwide, Inc.

ISBN: 0764580078 Pub

Date: 05/01/97

Buy It

Previous Table of Contents Next

Java is supposed to be platform independent

If I had to pick one issue in this book that I think is most controversial, it would be platform-dependent applications. From what I

read on the newsgroups and in the press, I think that many programmers agree with me. As you’ll see in Part III, I myself am quite

torn about the whole idea.

Much of this concern is misguided, however. If Java is to fulfill its promise as a full-powered environment for developing

applications, then it cannot be hobbled by requirements that are intended for applets on Web pages. Only by taking advantage of

undocumented packages and the native API can Java programmers level the playing field with their C and C++ counterparts and

produce commercial-quality applications.

The advent of Java-based network computers only extends the problem. On a network computer, anything you want to do must be

done in Java. You cannot drop out to a native method in C. Therefore it is even more important to have full access to all the

capabilities of Java.

What went wrong? What happened to the dream of applets moving transparently and easily between platforms? The answer is that

Java succeeded. In fact, it succeeded wildly, much faster and far beyond the expectations of its designers. What was a simple

language for consumer electronics has become the most rapidly adopted programming language in history. It is being used for

applets on Web pages, for database front ends, for numerical analysis, for multi-player networked games, and for much, much more.

It is no wonder that many of these programmers need capabilities and knowledge that were not originally planned for Java.

Why aren’t these things documented?

A question may occur to the inquiring mind: If these classes and methods aren’t documented, is there perhaps a good reason for that?

Maybe these are things human beings were not meant to know.

Poppycock. Given the relatively few people working on Java, especially in its early days, combined with the large size of the API,

it’s surprising that there aren’t more undocumented features. Indeed, there are many methods in the allegedly documented Java

packages that literally qualify as undoc-umented by virtue of their poor documentation, but they are not discussed in this book.

There are four main reasons that certain parts of Java were left undocumented. The first and the most important for Java

programmers to remember is that not all implementations of Java can be guaranteed to support these features. What works in

Netscape may not work in Internet Explorer. Even more likely, what works in the appletviewer or HotJava may not work in

Netscape. This is sometimes a problem for applets, but it is a fully surmountable problem for applications.

The second common reason why a Java class is undocumented is that the source code is in rather poor shape. Many parts of Java are

held together by bubble gum and bailing wire. Java is full of quick fixes to unexpected problems pieced together by overworked

programmers with insufficient resources. The Java team was simply not prepared for the stunning success of Java, and Javasoft has

been desperately trying to catch up to itself. There simply hasn’t been enough time to whip the source code into shape while

simultaneously fixing bugs, writing documentation, negotiating licensing agreements, adding features, and planning for the future.

Some classes that were undocumented in Java 1.0, such as sun.net.MulticastSocket, became documented in Java 1.1, just as soon as

Javasoft had time to do it. This code is nonetheless useful now, and it is available to you even if it’s not documented.

The third and related reason why these features are undocumented is the fear that making them public hinders future modifications.

In many cases, JavaSoft may clean up the messy classes and quick fixes in the future and document them. Until then, however, they

would rather not get tied to their original ad hoc solutions that were never properly thought out. It is believed that Java is in a much

剩余767页未读，继续阅读

worixiaoguang11

粉丝: 0
资源: 4

深入探索Java隐藏特性

Undocumented_Secrets_of_MATLAB_Java_Programming.part3

Undocumented_Secrets_of_MATLAB_Java_Programming.part2

Undocumented Secrets of MATLAB-Java Programming .part1.rar

java如何调用Google Slides的api

用JAVA实现diffie-hellman算法

springboot 整合AWS

SQLConfigDataSource替代

Centos7配置其jdk环境并安装最新版本Jenkins

发送AWS Secret manage

aes加密如何生成密钥

最新资源