• • • • • Table of Contents Reviews Reader Reviews Errata Academic Hardcore Java By Robert Simmons, Jr Publisher : O'Reilly Pub Date : March 2004 ISBN : 0-596-00568-7 Pages : 344 Hardcore Java is an advanced book that focuses on the little-touched but critical parts of the Java programming language that expert programmers use We're not talking about trivial things; we're talking about difficult but extremely powerful and useful programming techniques like reflection, advanced data modeling, advanced GUI design, and advanced aspects of JDO, EJB and XML-based web clients This unique book reveals the true wizardry behind the complex and often-mysterious Java environment • • • • • Table of Contents Reviews Reader Reviews Errata Academic Hardcore Java By Robert Simmons, Jr Publisher : O'Reilly Pub Date : March 2004 ISBN : 0-596-00568-7 Pages : 344 Copyright Preface Audience Typographical Conventions Code Samples Using Code Examples Acknowledgments Tools Comments and Questions Chapter 1 Java in Review Section 1.1 Core Concepts Section 1.2 Syntax Issues Section 1.3 Access Issues Section 1.4 Common Mistakes Chapter 2 The Final Story Section 2.1 Final Constants Section 2.2 Final Variables Section 2.4 Final Collections Section 2.6 Final Classes Section 2.8 Conditional Compilation Section 2.3 Final Parameters Section 2.5 Instance-Scoped Variables Section 2.7 Final Methods Section 2.9 Using final as a Coding Standard Chapter 3 Immutable Types Section 3.1 Fundamentals Section 3.2 Immutable Problems Section 3.3 Immutable or Not Chapter 4 Collections Section 4.1 Collection Concepts Section 4.2 Implementations Section 4.3 Choosing a Collection Type Section 4.5 Collection Gotchas Section 4.4 Iterating Collections Chapter 5 Exceptional Code Section 5.1 Two Types of Exceptions Section 5.2 When to Use Exceptions Section 5.3 Finally for Closure Section 5.4 Exceptional Traps Chapter 6 Nested Classes Section 6.1 Inner Classes Section 6.2 Limited-Scope Inner Classes Section 6.3 Static Nested Classes Section 6.5 Nested Classes in Interfaces? Section 6.7 Nested Class Rules Section 6.4 Double Nested Classes Section 6.6 Nested Interfaces Chapter 7 All About Constants Section 7.1 Substitution Constants Section 7.2 Bit Fields Section 7.3 Option Constants Section 7.5 Constant Encapsulation Section 7.4 Constant Objects Chapter 8 Data Modeling Section 8.1 The Requirements Document Section 8.3 Aspects of Well-Designed Data Models Section 8.5 Persistence Section 8.2 Natural Language Modeling Section 8.4 Reusable Data Constraints Chapter 9 Practical Reflection Section 9.1 The Basics Section 9.2 Reflection and Greater Reflection Section 9.3 Applying Reflection to MutableObject Section 9.5 Reflection + JUnit = Stable Code Section 9.4 Performance of Reflection Chapter 10 Proxies Section 10.1 What Is a Proxy? Section 10.2 Two Kinds of Proxies Section 10.3 Proxy Gotchas Chapter 11 References in Four Flavors Section 11.1 The Problem Section 11.2 Java Reference Concepts Section 11.3 The Java Reference Classes Section 11.5 A Weak Listener Section 11.4 Practical Applications Section 11.6 When to Use References Chapter 12 Tiger: JDK 1.5 Section 12.1 New Language Features Section 12.2 Generics Section 12.3 Other Improvements in Tiger Colophon Copyright © 2004 O'Reilly Media, Inc Printed in the United States of America Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472 O'Reilly & Associates books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://safari.oreilly.com) For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly Media, Inc The Java Series, Hardcore Java, the image of a lion, and related trade dress are trademarks of O'Reilly Media, Inc Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries O'Reilly Media, Inc is independent of Sun Microsystems, Inc Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks Where those designations appear in this book, and O'Reilly Media, Inc was aware of a trademark claim, the designations have been printed in caps or initial caps While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein Preface Studying a computer language is a career-long process Many developers make the mistake of thinking that they have learned enough They get caught in the corporate cycle of build-anddeploy and don't seek to expand their knowledge However, we can hardly blame them for that For one, the build-and-deploy cycle is intensive and carries with it a substantial amount of political pressure: managers don't want you to spend days reading a book or trying out code snippets when bugs and deadlines are looming However, developers should take the time to experiment and learn more When you expand your skills as a developer, there is some initial time investment However, this will rapidly pay off in increased productivity and quality Instead of spending hundreds of hours debugging, you can implement coding standards that block bugs and spend a fraction of that time implementing new features In the end, everyone wins; your company gets higher-quality code and quicker feature turnaround, and you get to spend more time playing Frisbee with your dog The second problem that the corporate developer has to deal with is that the majority of computer books are often not appropriate for the intermediate to advanced developer When looking at my rather impressive computer book library, much of it from O'Reilly, I notice that my books tend to fall into two categories: many are introductions to concepts and most of the others are references to concepts Although these books are very useful, there is a distinct lack of books that target the intermediate to advanced programmer However, there is one shining exception in my library In a dusty corner of my desk is a book I bought several years ago Secrets of the C++ Masters by Jeff Alger (Academic Press Limited) is absolutely essential for an intermediate C++ developer It begins with the assumption that you know the language and then expands from there The result is a book that can really transform a developer from the intermediate level to a true guru That is the goal of this book with regards to the Java™ language Most of the material is meant to help you avoid many common mistakes made by Java developers We will also cover nuances of Java, idiosyncrasies of the JDK, and advanced techniques With luck, this book will increase your productivity and your enjoyment of Java development Audience This book is for the intermediate to advanced Java programmer With that in mind, we can concentrate on the knowledge and techniques that go into some of the most advanced Java software available Prerequisites and Assumptions Functional proficiency with Java I will largely gloss over entire areas of Java I assume that you understand JavaBeans™, bound properties, JDBC, and other basics Familiarity with basic computer science I generally won't spend a lot of time on concepts such as scoping, logic operations, inheritance, and algorithm construction These and similar concepts will be the basis for more detailed discussions Familiarity with UML The Unified Modeling Language is the best way to express object-oriented engineering concepts in a manner that is familiar to all programmers, regardless of what language they speak Most of the code diagrams in this book incorporate UML Familiarity with the JDK and the virtual machine You should be familiar with the JDK and with how to compile a program and use its various tools in the JDK However, expertise in all packages isn't necessary can all take a single String parameter The First method can take a String because a String can be a parameter to Type The Fifth method can take a String because a String can be converted to an Object The Sixth method specifically declares that it takes a String The compiler will choose to call the Sixth method because the Sixth method is the most specific to the given parameters Another example illustrates this behavior even more clearly: someMethod(new Integer(5)); In this example, the compiler has two options: the First and Second methods Since the compiler chooses the most specific method, it will pick the Second method because a generic type with a bounds constraint of extends Number is more specific than a generic type with no bounds constraints This also works for primitives: someMethod(5); In this example, the compiler picks the Second method because the int parameter can be autoboxed into an Integer 12.2.5.2 Masking methods with inference There are some circumstances in which resolving the correct type is impossible: someMethod(new C( )); In this case, there is no specific method that accepts a parameter of type C Therefore, the compiler looks for methods that can take a variable of type Object and finds two: First and Fifth Since it doesn't have enough information to make a decision, the compiler gives up and issues an error stating that the call is ambiguous Similarly, the following would fail: someMethod(new Object( )); This is a major problem with inference In fact, the First and Fifth methods can never be called in this code It would be beneficial if the compiler could tell you this with an error message such as "Method x and method y mask each other and can never be called." Unfortunately, it doesn't issue this error, but persistently issues errors on the attempts to access the Fifth method However, this applies only to methods that work with the type Object If you try make this type of masking declaration with another type, such as Comparable, you would get a different compiler error: /** Seventh */ public static void someOtherMethod(fi /** Eighth */ public static void someOtherMethod(final Comparable num) {} This would cause the compiler to complain that both types have the same erasure This error is a little bit more intuitive than the previous error involving the masked methods 12.2.5.3 Inference based on return type One interesting example of inference occurs when there are no parameters to a generic method, such as with the Fourth method in Example 12-2: /** Fourth */ public static List someMethod( ) { List result = new ArrayList( ); System.out.print(" Fourth==> "); System.out.println(result.getClass( ).getComponentType( )); return result; } If you call this method, the type of the return value of the method is used to determine the type in the list: List listOne = someMethod( ); listOne.add(new Integer(5)); In this situation, listOne is a list of Integer objects Therefore, the Type parameter to Fourth becomes the type Integer The method returns a List parameterized with Integer that can subsequently be filled Similarly, you can make the method return a List of String objects with similar syntax: List listTwo = someMethod( ); listTwo.add(new String("Hello")); In this example, the call to someMethod( ) produced a list of strings because the return type is a List of Strings Taking this idea further, what would happen if you didn't give a list as a return type: Object listThree = someMethod( ); System.out.println(listThree.getClass( )); //listThree.add( ); // Can't put anything into this list Although this call will return the expected ArrayList, you can't actually place anything in the ArrayList, not even null In a way, it's an orphaned parameterized type 12.2.5.4 Generic parameter-based inference In addition to using inference with normal types, you can use it with parameterized types Here is the Third method of the InferenceDemo class: /** Third */ public static Type someMethod(final Type obj, List System.out.print(" Third==> "); System.out.println(obj.getClass( )); for (Type element : list) { System.out.println(element); } return obj; } In this method, the type of the list has to be inferred from the types embedded in the parameterized type passed to the list For example, you can call the method with the following syntax: someMethod(5, new ArrayList( )); In this call to the method, Type is inferred to be an Integer because an Integer can be used to autobox the literal number Also, the parameter list will be of type Integer because the Integer type is used to parameterize the ArrayList that is passed to the method However, just because Type appears in both parameters doesn't mean they have to be the same type: // Make some lists -List listOfA = new ArrayList( ); listOfA.add(new A( )); List listOfA = new ArrayList( ); listOfB.add(new B( )); someMethod(new B( ), listOfA); In this example, Third is called with two different types The type of obj is B, but the type of list is List This works because B objects can always be demoted to A objects However, opposite presents a different situation: someMethod(new A( ), listOfB); Since an A object is not necessarily a B object, the compiler can't choose either to use for the inference, so it infers Object for both types It then calls the method that infers Object and a List for the parameter types 12.2.5.5 Context-sensitive inference In some situations, inference is based on the context of the call to another method For example, consider the following calls: someMethod(5, someMethod( )); someMethod("Hello", someMethod( )); In both of these calls, the Fourth method is called to produce a list that can be passed to the Third method In the first call, the Fourth method produces a List of Integer objects, but in the second call, the Fourth method produces a List of String objects The Fourth method makes a decision based on the needs of the Third method Since the Third method needs a List of the type of the first parameter as the second parameter, the Fourth method gives it back a List of the first parameter's type 12.2.5.6 Avoiding inference through explicit declaration The specification for generics says that ambiguities in method calls can be cleared up with the following syntax: A value = SomeClass.someMethod(new B( ), new ArrayList( ) This says that the compiler should treat the B object as an A object and explicitly demote it This syntax can be used to clear up ambiguities in which one or more types could fit the bill You have to use the class name for a static method or the keyword this for an instance method before the , or the code won't compile: A value = someMethod( ); //