|
"Castor JDO": Simply False Advertising
The following is an expert perspective on the Java Data Objects (JDO) name and use issues currently pending in the court of opinion as well as, perhaps, more. This does not necessarily reflect the opinion of O'Reilly & Associates.
|
|
Using Castor JDO for SQL Mapping
Castor is a multifaceted software tool being developed under the auspices of exolab.org, an informal organization involved in the development of open source, enterprise software projects based on Java and XML
|
|
JDO vs. Entity Beans: A Modest Proposal
When Sun introduced the EJB 1.1 spec (including Entity Beans) two years ago, it was a revolution in enterprise computing. Experience revealed, however, that it was not perfect. The remote interface is slow and it makes creation of fine-grained objects difficult, in many cases.
|
|
Flawed Understanding of JDO Leads to FUD
This installment of the Design Techniques column shows how some fundamental software design techniques, like avoiding special data values and minimizing method coupling, apply to Java
|
|
Using Java Data Objects
In a past article on XML Databinding, I showed how you could work with Java objects and have them persist as XML files.
|
|
The Debate Over Java Data Objects
Java programmers like working with objects (I hope!). Applications often, if not always, need us to persist information. Most server-side developers have worked with the JDBC API, which allows us to access databases, and is mainly used to query relational databases. Since we already have our model in our objects, wouldn't it be nice to be able to persist the objects that it makes sense to store? It can be a real pain to write code that jumps from our objects and saves the values away into a database. This can also get tricky when you get into relationships between objects. The Serialization mechanism allows us to take an object and save the graph to a stream, but Serialization is not built to allow multi-user sharing.
|
|
JDOCentral
|
|
Java Data Objects (JDO) Make Persistence Easier
As a part of the javax.jdo package, Java Data Objects (JDO) persistently store programmers' objects without worrying about a couple of traditionally worrisome details.
|
|
The JDO Object Model
|
|
JDO streamlines data access in Java
MAKING CORPORATE DATA accessible to business applications today typically falls into the capable hands of Java developers, who often spend a good deal of time writing code specifically for data access and manipulation. A new standard called JDO (Java Data Objects) promises to simplify the coding of interactions between business applications and data sources by letting developers use transparent, object-based access to those data sources. Simply put, JDO allows developers to work with data using familiar Java constructs rather than having to write database-specific code, such as SQL, to manage data access and manipulation.
|
|
Comming out of the JDO closet
As part of building the infrastructures for a large J2EE project, we've spent the last few months designing and implementing a JDO-based O/R persistency framework. This framework provides our business logic programmers with the following features: an interface-based abstract view of the data-layer with full OO semantics, zero-need knowledge of the object-to-database mapping details, "delta" support, and more. This article presents the persistency framework that we've built on top of JDO, and offers a commentary on the current advantages and shortcomings based on our experience with the JDO specification.
|
|
Java Data Objects (JDO)
|
|
Close-up on JDO: a standard for persistence of Java business objects
In July 2000, Sun came up with a new data access technology which could have a major impact on the way Java applications are created. Standardized under the name JDO (Java Data Objects), this technology will enable real business object modeling to be carried out by automatically managing interaction between objects and resource managers. Traditional development using a specific, non-object access API such as JDBC will now, with JDO, have a standardized alternative.
|
|
KODO JDO
Organizations that leverage object oriented languages like Java often face the object-relational
impedance problems inherent of working in an elegant object-oriented manner
while having to store persistent information in the rows and columns structure of a
relational database. To solve this issue, developers in such organizations face a decision
between internally developing the persistence framework or licensing persistence
middleware software from a third-party vendor.
|
|
JDOQL: The JDO Query Language
In this installment of Design Techniques, I give advice on using runtime class information in Java programs. I talk about the method area of the JVM and the structure of Java objects, upcasting and downcasting, polymorphism and dynamic binding, java.lang.Class and reflection, and -- perhaps most importantly -- I reveal how best to ask a hippopotamus to dance
|
|
The Future of JDO
|
|
Why JDO is a critical component of J2EE
|
|
JDO and J2EE
Java Data Objects (JDO), the emerging Java standard for persisting objects, is creating great interest in
the developer community. But will it live up to its promises and, in particular, how will it fit in to the
J2EE architecture? PrismTech has many years of experience developing persistent object systems and
has made significant contributions to the emerging standard. PrismTech is therefore strongly supporting
this standard and has developed a commercial implementation that was released in November 2001.
|
|
JDO Specification Final Release
|
|
How to implement state-dependent behavior
Doing the State pattern in Java
An object in a program frequently has an internal "state," and the behavior of the object needs to change when its state changes. For example, the acceleration characteristics of a car depend on its current RPM range -- in other words, on its "state." The State pattern takes advantage of polymorphism to implement such state-dependent behavior in an object-oriented program.
|
|
Introduction to "Design Techniques"
This first installment of the new Design Techniques column introduces the column and discusses the larger issues involved in designing Java programs. In addition, we'll examine the software development process in general, describe the role of design within that process, and look at the various and competing goals of a "good" software design
|
|
Implementing Basic Design Patterns in Java
An interface encapsulates a coherent set of services and attributes (broadly, a Role), without explicitly binding this functionality to that of any particular object or code.
|
|
AWT Patterns
|
|
Design for Open Systems in Java
|
|
Java Tip 68: Learn how to implement the Command pattern in Java
Sometimes it's necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request. In procedural languages, this type of communication is accomplished via a callback: a function that is registered somewhere to be called at a later point. Commands are the object-oriented equivalent of callbacks and encapsulate the callback function. This Java Tip demonstrates how to implement the Command pattern in Java.
|
|
Clever Facade makes JDBC look easy
This month's tool saves you some work when dealing with common JDBC operations. You can use the Facade design pattern to encapsulate the most popular JDBC objects, thereby hiding all the tedium of initialization, exception handling, and cleanup.
|
|
Design networked applications in RMI using the Adapter design pattern
Creating a networked application is easy using Java's Remote Method Invocation. However, taking a non-networked class and jazzing it up for the network is definitely not the way to go. This will just lead to mess -- slow, hard to read, and difficult to maintain.
|
|
Best Practices for Object Design
By Bill Veners
|
|
Articles about Java Design
By Bill Veners
|
Appreciate the significance of the object
Objects are for people, not for computers. The point of objects is not to help computers run software, but to help people develop software. Computers are just as happy running assembly language programs as object-oriented programs. But people are happier writing object-oriented programs. OK, if not always happier, then hopefully at least more productive. The main aim of advances in software technology, from machine language to assembly to procedural languages to object-oriented languages, has been to help programmers do their jobs. In particular, objects help programmers manage complexity and change in their software.
By Bill Veners
|
See objects as bundles of behavior, not bundles of data
One of the most basic object-oriented ideas is encapsulation -- associating data with code that manipulates the data. The data, stored in instance variables, represents the object's state. The code, stored in instance methods, represents the object's behavior. Because of encapsulation, therefore, you can think of objects as either bundles of data, bundles of behavior, or both. To reap the greatest benefit from encapsulation, however, you should think of objects primarily as bundles of behavior, not bundles of data. You should think of objects less as carriers of information, embodied in the data, and more as providers of services, represented by the behavior.
By Bill Veners
|
Design Service-Oriented Objects that use their state to decide how to behave
When I was first struggling to understand object-oriented programming, I happened to leaf through a copy of Object-Oriented Design with Applications by Grady Booch. In this book I found a sentence that gave my my first real insight into what an object is.
By Bill Veners
|
Understand the relationship between mutable Service-Oriented Objects and state machines
In Guideline 1, I said that objects are machines. The kind of machine that service-oriented objects resemble, mathematically speaking at least, is the state machine
By Bill Veners
|
Use Messengers to transmit information
Guideline 2 encourages you to think of objects of bundles of services, not bundles of data. This guideline irreverently suggests that sometimes its OK to design objects that are bundles of data.
By Bill Veners
|
Use Messengers to transmit information
Guideline 2 encourages you to think of objects of bundles of services, not bundles of data. This guideline irreverently suggests that sometimes its OK to design objects that are bundles of data.
By Bill Veners
|
Use Flyweights as pluggable nuggets of behavior
This StampDispenser really offers the same service to clients as the StampDispenser in example 1, but through a different interface and with an implementation that is more code-heavy than example 1. Were I to have to implement a StampDispenser, I would do it the way I did in example 1. With example 2, I wanted to show how state machines and service-oriented objects are similar, and I wanted to have a launching point for using the state pattern.
By Bill Veners
|
Use Immutables to represent values of abstract data types
With a mutable object like the StampDispenser in Listing 3-1, identity is important. If I have 3 stamp dispenser machines and I enter a dime in one and a dime in another, I don't get a stamp. I have to insert at least 20 cents in a particular stamp dispenser to get the stamp. The identity of the machine into which I insert that second dime matters -- it has to be the same machine in which I inserted the first dime.
By Bill Veners
|
Use Immutables to represent values of abstract data types
With a mutable object like the StampDispenser in Listing 3-1, identity is important. If I have 3 stamp dispenser machines and I enter a dime in one and a dime in another, I don't get a stamp. I have to insert at least 20 cents in a particular stamp dispenser to get the stamp. The identity of the machine into which I insert that second dime matters -- it has to be the same machine in which I inserted the first dime.
By Bill Veners
|