Part I How Java Works
Chapter 1 Introducing Java SECRETS
There are close to a hundred books about Java program-ming on bookstore shelves today, and at least 70 of them are completely predictable and more or less interchangeable. Its as if they had all been written from the same outline but by different authors. Each book begins with a chapter about whats special about Java and how it differs from other programming languages. Each book shows how to write Hello World and other character mode applications to teach Javas syntax. There is a chapter or two on object-oriented programming, a chapter on threads, a chapter on exceptions, and a few chapters on the AWT.
This book is different. It starts where the other books stop. This book assumes you already know Javas syntax and object-oriented programming basics. This book assumes that youre comfortable with the AWT. Instead of rehashing these topics, this book delves into the parts of Java that are not documented by Sun, that are not generally accessible to anyone with a Web browser, and that are not already covered in a hundred other books.
A Little Knowledge Can Be a Dangerous Thing
I had some reservations about writing this book. I still do. This is a dangerous book. It reveals knowledge that can easily be abused. Improper use of the secrets revealed herein can easily tie Java programs to specific platforms or implementations. As a longtime Mac user, I know the agony of watching all the best software come out on Windows first and the Mac much later, if at all. I do not want to extend this trend to Java-based software.
Nonetheless, I have come to the conclusion that a book like this is necessary if Java is to move out of its niche of creating applets for Web pages and into the broader software development market. There are many applications for which Java is ideal, but that cannot be written without more information than Sun has chosen to reveal. Among other things, this includes stand-alone executable applications. HotJava and javac are such applications, so it must be possible to write them, but until now Sun has not revealed how. This book reveals that secret, among others.
There are other reasons why programmers need to know these details. For example, a programmer writing development tools requires a much deeper understanding of Javas internals than does the average application developer. Programmers merely writing applets dont need to know exactly how and when the ScreenUpdater thread calls the various paint() and update() methods in different components and containers. A programmer adding applet support to a Web browser, however, absolutely has to understand this.
Rationalize though I might, however (and Im quite good at rationalizing, I admit), the real reason why I am writing this book is that it seems like a neat thing to do. I know that the information I present here will be misused. I accept that. Nonetheless, I firmly believe that, in the long run, more knowledge is a good thing, dangerous though it may be, and that secrets are meant to be revealed.
Whats in This Book?
There are three ways that a Java program can become dangerous. It can rely on the internal structure of Java objects; it can use classes that it isnt supposed to know about; or it can be platform-specific. This book covers all three.
Part I: How Java Works
After a brief introduction, Part I begins with seven chapters on Java internals. You will learn how objects and primitive data types are laid out in memory, how arguments are passed to and values returned from methods, what a variable really is, and more. Javas implementation of arrays and strings will be explored. I will discuss and compare different possible models for threads and algorithms for garbage collection, shedding some light on why Java uses the data structures and algorithms that it does and why it sometimes behaves in unexpected ways. Youll learn how a Web browser loads applets and what it needs to provide for them so that you can add applet support to your own programs. All of this is tied to the Java virtual machine and .class file format, so youll learn how to read and disassemble Java byte code.
This section is dangerous because none of it is guaranteed. Tomorrow Sun could change Javas thread model from cooperative to preemptive or make strings null-terminated. Worse yet, it might be one way on one system and another way on another. (In fact, in the case of threading this is already true.) Writing code that depends on implementation issues is always dangerous but sometimes necessary. And it often helps to know whats going on inside a class or method even if you dont explicitly use that information. For example, knowing whether the Vector class is implemented with a growable array or a linked list influences whether or not you would use it in a program that will perform thousands of insertions in the middle of a list.
You can drive a car without knowing the first thing about carburetors or transmissions, but it certainly doesnt hurt to know about them, especially when things go wrong. Knowing what goes on under the hood, but ignoring it when it isnt relevant, is a good technique for both programmers and drivers; it is a very different technique from not knowing at all.
Some may object that this technique goes against the philosophy of object-oriented programming. Objects are supposed to be black boxes into which data is sent and out of which a result flows. You arent supposed to need to know what happens inside the box. Objects arent everything, however, and practical experience shows that sometimes the black box doesnt do exactly what its supposed to, and you need to open it up and fix it. Part I opens up many black boxes to expose their inner workings.
|