in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 < 2 > 3 4 5 6 7 8 .. 166 >> Next

Connecting via HTTP with the Classes 126
An Alternative Open Source HTTP Client 137
Item 18: Effective String Tokenizing 140
Item 19: JLayered Pane Pitfalls 146
Item 20: When File.renameTo() Won't 151
Item 21: Use Iteration over Enumeration 157
Item 22: J2ME Performance and Pitfalls 162
Part Two The Web Tier 199
Item 23: Cache, It's Money 200
Item 24: JSP Design Errors 208
Request/Response Paradigm 208
Maintaining State 209
JSP the Old Way 210
JSP Development with Beans (Model 1 Architecture) 214
JSP Development in the Model 2 Architecture 220
Item 25: When Servlet HttpSessions Collide 220
Item 26: When Applets Go Bad 227
Item 27: Transactional LDAPóDon't Make that Commitment 235
Item 28: Problems with Filters 244
Item 29: Some Direction about JSP Reuse and Content Delivery 255
Item 30: Form Validation Using Regular Expressions 261
Contents ix
Item 31: Instance Variables in Servlets 269
Item 32: Design Flaws with Creating Database Connections within Servlets 279
Item 33: Attempting to Use Both Output Mechanisms in Servlets 291
Item 34: The Mysterious File Protocol 297
Item 35: Reading Files from Servlets Web Application Deployment Descriptors 302 308
Item 36: Too Many Submits Preventing Multiple Submits Handling Multiple Submits 312 314 316
Part Three The Enterprise Tier 327
Item 37: J2EE Architecture Considerations 329
Item 38: Design Strategies for Eliminating Network Bottleneck Pitfalls A Scenario General Design Considerations EJB Design Considerations 335 336 336 340
Item 39: I'll Take the Local 341
Item 40: Image Obsession 348
Item 41: The Problem with Multiple Concurrent Result Sets 353
Item 42: Generating Primary Keys for EJB A Simple Scenario A "Client Control" Approach The Singleton Approach The Networked Singleton Approach An Application Server-Specific Approach Database Autogeneration Approaches Other Approaches 359 359 360 362 363 363 363 364
Item 43: The Stateful Stateless Session Bean Message-Driven Beans Entity Bean Stateful Session Bean Stateless Session Bean 365 366 366 368 368
Item 44:
The Unprepared PreparedStatement
x Contents
Item 45: Take a Dip in the Resource Pool 378
Item 46: JDO and Data Persistence 385
Item 47: Where's the WSDL? Pitfalls of Using JAXR with UDDI 398
Where's the WSDL? 404
Item 48: Performance Pitfalls in JAX-RPC Application Clients 417
Example Web Service 418
A Simple Client That Uses Precompiled Stub Classes 420
A Client That Uses Dynamic Proxies for Access 421 Two Clients Using the Dynamic Invocation Interface (DII) 423
Performance Results 427
Conclusion 428
Item 49: Get Your Beans Off My Filesystem! 429
Item 50: When Transactions Go Awry, or Consistent State in
Stateful Session EJBs 433
The Memento Pattern 438
"Sometimes we discover unpleasant truths. Whenever we do so, we are in difficulties: suppressing them is scientifically dishonest, so we must tell them, but telling
them, however, will fire back on us." Edsger W. Dijkstra, "How do we tell truths that might hurt?"
Good programming is difficult. It is especially arduous for new programmers given the pace of change and the ever-expanding size of the software engineering body of knowledge ( that they must master. The authors of this book have found that experience and in-depth understanding are key factors in both programmer productivity and reliable software. The bottom line is that experienced programmers don't stumble around in the dark. They know the lay of the land, they recognize patterns, and they avoid the hazardous areas. This book presents our experience and guidance on 50 discrete topics to assist you in avoiding some of those hazards.
What Is a Pitfall?
The formal definition, given in the first Java Pitfalls (Wiley, 2000) book, is as follows:
"A pitfall is code that compiles fine but when executed produces unintended and sometimes disastrous results."
This rather terse definition covers what we consider the "basic" pitfall. There are many variations on this theme. A broader definition could be any language feature, API, or system that causes a programmer to waste inordinate amounts of time struggling with the development tools instead of making progress on the resulting software.
The causes of pitfalls can be loosely divided into two groups: the fault of the platform designer or the fault of the inexperienced programmer. This is not to cast blame, but rather to determine the source of the pitfall in the construction of a pitfall taxonomy. For the same reason we create a formal definition of pitfalls, we present the pitfall taxonomy in Figure i.1 in order to attempt to better understand the things that trip us up.
xii Introduction
Figure i.1 A pitfall taxonomy.
The categories of pitfalls associated with the system designer are as follows:
Nonintuitive Application Programming Interfaces (APIs). The Java platform has thousands of classes and tens of thousands of methods. The sheer size of the platform has become a complexity pitfall. Some of these classes are well designed, like servlets, IO streams (excluding performance ramifications), and collections. Unfortunately, many APIs are nonintuitive for the following reasons:
Previous << 1 < 2 > 3 4 5 6 7 8 .. 166 >> Next