TL;DR: The Java Language Specification, Second Edition is the definitive technical reference for the Java programming language and provides complete, accurate, and detailed coverage of the syntax and semantics of the Java language.
Abstract: From the Publisher:
Written by the inventors of the technology, The Java(tm) Language Specification, Second Edition is the definitive technical reference for the Java(tm) programming language If you want to know the precise meaning of the language's constructs, this is the source for you
The book provides complete, accurate, and detailed coverage of the syntax and semantics of the Java programming language It describes all aspects of the language, including the semantics of all types, statements, and expressions, as well as threads and binary compatibility
TL;DR: AspectJ as mentioned in this paper is a simple and practical aspect-oriented extension to Java with just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns.
Abstract: Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.
TL;DR: This book discusses the evolution of Layers in Enterprise Applications, Concurrency Problems, and Object-Relational Behavioral Patterns, as well as some Technology-Specific Advice.
Abstract: Preface. Who This Book Is For. Acknowledgements. Colophon. Introduction. Architecture. Enterprise Applications. Kinds of Enterprise Application. Thinking About Performance. Patterns. The Structure of the Patterns. Limitations of These Patterns. I. THE NARRATIVES. 1. Layering. The Evolution of Layers in Enterprise Applications. The Three Principal Layers. Choosing Where to Run Your Layers. 2. Organizing Domain Logic. Making a Choice. Service Layer. 3. Mapping to Relational Databases. Architectural Patterns. The Behavioral Problem. Reading in Data Structural Mapping Patterns. Mapping Relationships. Inheritance. Building the Mapping. Double Mapping. Using Metadata. Database Connections. Some Miscellaneous Points. Further Reading. 4. Web Presentation. View Patterns. Input Controller Patterns. Further Reading. 5. Concurrency (by Martin Fowler and David Rice). Concurrency Problems. Execution Contexts. Isolation and Immutability. Optimistic and Pessimistic Concurrency Control. Preventing Inconsistent Reads. Deadlocks. Transactions. ACID. Transactional Resources. Reducing Transaction Isolation for Liveness. Business and System Transactions. Patterns for Offline Concurrency Control. Application Server Concurrency. Further Reading. 6. Session State. The Value of Statelessness. Session State. Ways to Store Session State. 7. Distribution Strategies. The Allure of Distributed Objects. Remote and Local Interfaces. Where You Have to Distribute. Working with the Distribution Boundary. Interfaces for Distribution. 8. Putting it all Together. Starting With the Domain Layer. Down to the Data Source. Data Source for Transaction Script. Data Source Table Module (125). Data Source for Domain Model (116). The Presentation Layer. Some Technology-Specific Advice. Java and J2EE. .NET. Stored Procedures. Web Services. Other Layering Schemes. II. THE PATTERNS. 9. Domain Logic Patterns. Transaction Script. How It Works. When to Use It. The Revenue Recognition Problem. Example: Revenue Recognition (Java). Domain Model. How It Works. When to Use It. Further Reading. Example: Revenue Recognition (Java). Table Module. How It Works. When to Use It. Example: Revenue Recognition with a Table Module (C#). Service Layer(by Randy Stafford). How It Works. When to Use It. Further Reading. Example: Revenue Recognition (Java). 10. Data Source Architectural Patterns. Table Data Gateway. How It Works. When to Use It. Further Reading. Example: Person Gateway (C#). Example: Using ADO.NET Data Sets (C#). Row Data Gateway. How It Works. When to Use It. Example: A Person Record (Java). Example: A Data Holder for a Domain Object (Java). Active Record. How It Works. When to Use It. Example: A Simple Person (Java). Data Mapper. How It Works. When to Use It. Example: A Simple Database Mapper (Java). Example: Separating the Finders (Java). Example: Creating an Empty Object (Java). 11. Object-Relational Behavioral Patterns. Unit of Work. How It Works. When to Use It. Example: Unit of Work with Object Registration (Java) (by David Rice). Identity Map. How It Works. When to Use It. Example: Methods for an Identity Map (Java). Lazy Load. How It Works. When to Use It. Example: Lazy Initialization (Java). Example: Virtual Proxy (Java). Example: Using a Value Holder (Java). Example: Using Ghosts (C#). 12. Object-Relational Structural Patterns. Identity Field. How It Works. When to Use It. Further Reading. Example: Integral Key (C#). Example: Using a Key Table (Java). Example: Using a Compound Key (Java). Foreign Key Mapping. How It Works. When to Use It. Example: Single-Valued Reference (Java). Example: Multitable Find (Java). Example: Collection of References (C#). Association Table Mapping. How It Works. When to Use It. Example: Employees and Skills (C#). Example: Using Direct SQL (Java). Example: Using a Single Query for Multiple Employees (Java) (by Matt Foemmel and Martin Fowler). Dependent Mapping. How It Works. When to Use It. Example: Albums and Tracks (Java). Embedded Value. How It Works. When to Use It. Further Reading. Example: Simple Value Object (Java). Serialized LOB. How It Works. When to Use It. Example: Serializing a Department Hierarchy in XML (Java). Single Table Inheritance. How It Works. When to Use It. Example: A Single Table for Players (C#). Loading an Object from the Database. Class Table Inheritance. How It Works. When to Use It. Further Reading. Example: Players and Their Kin (C#). Concrete Table Inheritance. How It Works. When to Use It. Example: Concrete Players (C#). Inheritance Mappers. How It Works. When to Use It. 13. Object-Relational Metadata Mapping Patterns. Metadata Mapping. How It Works. When to Use It. Example: Using Metadata and Reflection (Java). Query Object. How It Works. When to Use It. Further Reading. Example: A Simple Query Object (Java). Repository (by Edward Hieatt and Rob Mee). How It Works. When to Use It. Further Reading. Example: Finding a Person's Dependents (Java). Example: Swapping Repository Strategies (Java). 14. Web Presentation Patterns. Model View Controller. How It Works. When to Use It. Page Controller. How It Works. When to Use It. Example: Simple Display with a Servlet Controller and a JSP View (Java). Example: Using a JSP as a Handler (Java). Example: Page Handler with a Code Behind (C#). Front Controller. How It Works. When to Use It. Further Reading. Example: Simple Display (Java). Template View. How It Works. When to Use It. Example: Using a JSP as a View with a Separate Controller (Java). Example: ASP.NET Server Page (C#). Transform View. How It Works. When to Use It. Example: Simple Transform (Java). Two Step View. How It Works. When to Use It. Example: Two Stage XSLT (XSLT). Example: JSP and Custom Tags (Java). Application Controller. How It Works. When to Use It. Further Reading. Example: State Model Application Controller (Java). 15. Distribution Patterns. Remote Facade. How It Works. When to Use It. Example: Using a Java Session Bean as a Remote Facade (Java). Example: Web Service (C#). Data Transfer Object. How It Works. When to Use It. Further Reading. Example: Transferring Information about Albums (Java). Example: Serializing Using XML (Java). 16. Offline Concurrency Patterns. Optimistic Offline Lock (by David Rice). How It Works. When to Use It. Example: Domain Layer with Data Mappers (165) (Java). Pessimistic Offline Lock (by David Rice). How It Works. When to Use It. Example: Simple Lock Manager (Java). Coarse-Grained Lock (by David Rice and Matt Foemmel). How It Works. When to Use It. Example: Shared Optimistic Offline Lock (416) (Java). Example: Shared Pessimistic Offline Lock (426) (Java). Example: Root Optimistic Offline Lock (416) (Java). Implicit Lock (by David Rice). How It Works. When to Use It. Example: Implicit Pessimistic Offline Lock (426) (Java). 17. Session State Patterns. Client Session State. How It Works. When to Use It. Server Session State. How It Works. When to Use It. Database Session State. How It Works. When to Use It. 18. Base Patterns. Gateway. How It Works. When to Use It. Example: A Gateway to a Proprietary Messaging Service (Java). Mapper. How It Works. When to Use It. Layer Supertype. How It Works. When to Use It. Example: Domain Object (Java). Separated Interface. How It Works. When to Use It. Registry. How It Works. When to Use It. Example: A Singleton Registry (Java). Example: Thread-Safe Registry (Java) (by Matt Foemmel and Martin Fowler). Value Object. How It Works. When to Use It. Money. How It Works. When to Use It. Example: A Money Class (Java) (by Matt Foemmel and Martin Fowler). Special Case. How It Works. When to Use It. Further Reading. Example: A Simple Null Object (C#). Plugin (by David Rice and Matt Foemmel). How It Works. When to Use It. Example: An Id Generator (Java). Service Stub (by David Rice). How It Works. When to Use It. Example: Sales Tax Service (Java). Record Set. How It Works. When to Use It. References Index. 0321127420T10162002
TL;DR: This paper recommends benchmarking selection and evaluation methodologies, and introduces the DaCapo benchmarks, a set of open source, client-side Java benchmarks that improve over SPEC Java in a variety of ways, including more complex code, richer object behaviors, and more demanding memory system requirements.
Abstract: Since benchmarks drive computer science research and industry product development, which ones we use and how we evaluate them are key questions for the community. Despite complex runtime tradeoffs due to dynamic compilation and garbage collection required for Java programs, many evaluations still use methodologies developed for C, C++, and Fortran. SPEC, the dominant purveyor of benchmarks, compounded this problem by institutionalizing these methodologies for their Java benchmark suite. This paper recommends benchmarking selection and evaluation methodologies, and introduces the DaCapo benchmarks, a set of open source, client-side Java benchmarks. We demonstrate that the complex interactions of (1) architecture, (2) compiler, (3) virtual machine, (4) memory management, and (5) application require more extensive evaluation than C, C++, and Fortran which stress (4) much less, and do not require (3). We use and introduce new value, time-series, and statistical metrics for static and dynamic properties such as code complexity, code size, heap composition, and pointer mutations. No benchmark suite is definitive, but these metrics show that DaCapo improves over SPEC Java in a variety of ways, including more complex code, richer object behaviors, and more demanding memory system requirements. This paper takes a step towards improving methodologies for choosing and evaluating benchmarks to foster innovation in system design and implementation for Java and other managed languages.
TL;DR: The Extended Static Checker for Java (ESC/Java) is introduced, an experimental compile-time program checker that finds common programming errors and provides programmers with a simple annotation language with which programmer design decisions can be expressed formally.
Abstract: Software development and maintenance are costly endeavors. The cost can be reduced if more software defects are detected earlier in the development cycle. This paper introduces the Extended Static Checker for Java (ESC/Java), an experimental compile-time program checker that finds common programming errors. The checker is powered by verification-condition generation and automatic theorem-proving techniques. It provides programmers with a simple annotation language with which programmer design decisions can be expressed formally. ESC/Java examines the annotated software and warns of inconsistencies between the design decisions recorded in the annotations and the actual code, and also warns of potential runtime errors in the code. This paper gives an overview of the checker architecture and annotation language and describes our experience applying the checker to tens of thousands of lines of Java programs.