Foreword
| When I first heard about Java Data Objects' (JDO) development back in 2000, I was absolutely thrilled. I was thrilled that the Java industry would finally have a standard and easy way to transparently persist object models. I saw JDO not just as a tool to solve the problem of persistence but also as a catalyst that would encourage Java projects to adopt object-oriented development paradigms . I began my own career in enterprise development in 1998. Prior to that, I read some great books that set my first impressions of how large-scale systems should be designed. Reading books like Peter Coad's Java Design , Scott Ambler's Building Object Applications That Work , and then being lucky enough to have friends who were from a Smalltalk and Gemstone background, convinced me that building object models was the best and most accepted way to build enterprise systems. But, when I started actually working on enterprise projects and saw what people were saying on TheServerSide.com, I was shocked. Most J2EE developers were not building object-oriented systems and there wasn't even an easy way for them to do so if they wanted to. The only alternatives were to build your own persistence layer or lock yourself into a proprietary O/R mapping product or object database. Building your own persistence layer was a very complex and poorly understood subject ”there was virtually no published material on this subject. Entity Beans were an option if you were working with an application server, but entity beans are a component persistence technology that isn't suitable for persisting complex, fine-grained object models. There really weren't that many options, which is why I was a very strong defender of entity beans because it was the only standard in the java universe that addressed persistence in somewhat of a transparent way. However, when JDO was announced, I knew that this technology would enable developers to easily write their applications to object-oriented paradigms, allowing them to complete their projects faster, make their applications more maintainable , and overall increase the quality of Java software projects in the industry as a whole. The possibilities that JDO represented were just too attractive for the community to ignore, which is why JDO has been so popular at the grassroots level. Today, JDO has significant industry support. There are now dozens of thriving commercial products and open source projects that support JDO and transparent persistence. Microsoft decided to include the JDO-like ObjectSpaces technology in the .NET 2004 framework. JBoss 4 is expected to be the first application server with transparent persistence (and JDO) built right into it. JDO has become a viable option to enable transparent persistence and is continuing to grow in importance. However, the development practices being applied in the industry are still behind. The lack of a standard way to transparently persist object models has been a barrier to the maturity of J2EE development practices. This is why JDO is so important, and why this book is so important. Core Java Data Objects is a great book and it represents the combined expertise of a group of very qualified authors (consisting of JDO expert group members and JDO users) as well as thousands of J2EE professionals and JDO enthusiasts on TheServerSide.com, where the book's early chapter drafts were publicly reviewed. It is difficult to find such book as this that was carefully crafted and tuned by so many people. For developers looking to understand and apply JDO technology, this book is a must have. Floyd Marinescu |
EAN: 2147483647
Pages: 146