Home
Download
Philosophy
The term Java Enterprise Software started to make it's way into the consciousness of Java developers after the introduction of EJBs. This was to become an industry standard for developing "enterprise software", however it quickly became a pejorative term among developers, and it's quite easy to see why. First, you had to read a 300 page document to "get started", and to know what you were up against (and "against" is meant literally). You had to create configurations redundantly, you had to write more boilerplate code than business logic (most of the time), it was slow, required a separate server (Application Server) in addition to the Web Container to run, it was a pain to debug, trivial things like "listing objects", "searching for objects" were very difficult to implement, etc.
A lot of people saw that this complexity was not helping developers, and in fact was increasing the cost of development substantially. So today's most used software like Hibernate, Spring Framework, Java Server Faces, EJB 3, Struts Framwork, etc. are trying to be simpler and more usable than their predecessors, but are they succeeding? Why is it, that verbose and redundant XML configuration is still "in"? Why is it that Java can't be used for prototyping?
The problem is the philosophy of Java development has not changed significantly enough. Most of these libraries and frameworks still just implement features and technical solutions, instead of going the other way around and determine in advance what the library will be used for, and how to make the most common use cases easy to realize, while still allowing for some uncommon things.
BeanKeeper's first rule is simple things must be easy to do. This rule means, that saving, searching objects are simple operations, so they should be easy to learn and do with BeanKeeper. You mostly have to read 1 page of a tutorial to get started, and you don't have to configure anything. Second rule is, that features are only good, if they don't get in the way of the simple things, which means features are only added, if the first rule is preserved without compromise.
Conclusion is, that with this philosophy, with reducing the complexity, BeanKeeper is able to reduce the frustration and cost of development, which in turn increases the "joy factor" of developing Enterprise Software.
Implementation
So how does all this philosophy stuff translate to a persistence software library? The library is not only supposed to handle all low-level database operations transparently, but also some of the more high-level functions. This must be done in order to enable the developer to concentrate only on writing logic. So BeanKeeper offers the following key features:
- Simple usage, which is possible with learning only 3 methods, and reading the tutorial.
- Zero-configuration. Nothing needs to be configured, only the database url is needed for the library to initialize.
- Scalability. The library is capable of distributed operation, for redundancy and load-balancing your applications.
- Relations like references to other objects, Lists, Maps, Sets, Collections are handled 100% transparently by the library.
- Large result sets are automatically paged! Paging is 100% transparent, so a million-record result list can be given directly to the presentation layer, without caring for memory usage and database load!
- Transactions are always 'serializable'. Meaning: during a transaction nothing can influence the result of queries from outside the transaction. This means running the same query twice inside a transaction (no matter how long the transaction takes) will always produce the exact same result, except if the transaction itself changes the objects in the result.
- Full (transparent) polymorphism support ensures that (most of the time) the library does not get in the way of the programmer. The model is persisted just in the way the programmer expressed through inheritence, and is recalled with all the attributes of polymorphism.
- A custom, object oriented query language ensures, that no complicated SQL needs to be written.
- Scalar query support enables view-centric, more efficient data recall.
- Real portability between databases. BeanKeeper hides all database specific behaviour from the programmer, like: null value handling, empty strings (oracle), case sensitive and insensitive searches, reserved names, etc. That means, one can switch between database implementations, and can assume that (with the exception of a few documented cases) the software build upon the library will continue to work.
Openness
Our goal is to make Java programmers' life easier, and to prove, that Java does not have to be complex, just because it's Java. The library is licensed under the LGPL. This means, that you can use it, for anything you like unmodified, free of charge. But because we want this to be a community effort, and expect a lot of people to help (with feedback, code, tests, experiences), you are forbidden to take the code, modify it, and keep the changes for yourself. If you distribute the modified program, you must supply the code for your modification too. You can also use this library in commercial software free of charge.
We hope, that other programmers can benefit from this work too, and the unique philosophy and purpose of this library makes it attractive enough to ensure a place amongst the widely used solutions.