Mick Jordan of Sun released a paper which discusses a comparison of various persistence alternatives for Java. His paper defines a set of criteria, and uses that set to evaluate JDBC, JDO, EJB, and even Serialization.

Abstract

Access to persistent data is a requirement for the majority of computer applications. The Java programming language and associated run-time environment provide excellent features for the construction of reliable and robust applications, but currently these do not expand to the domain of persistent data. Many mechanisms for managing persistent data have been proposed, some of which are now included in the standard Java platforms, e.g. J2SE and J2EE.

This paper defines a set of criteria by which persistence mechanisms may be compared and then applies the criteria to a representative set of widely used mechanisms. The criteria are evaluated in the context of a widely-known benchmark, which was ported to each of the mechanisms, and include performance and scalability results.

Read the paper: A Comparitive Study of Persistence Mechanisms for the Java Platform

NOTE: There are popular persistence mechanisms missing of course ;)

Yet another persistence comparison:

This article is NOT a comparison of persistent alternatives for the Java platform - it is a comparison of persistence alternatives under a very restrictive set of criteria.

The most restrictive of which is that it completely disregards the ability to query over the persisted objects as a factor in the comparison. How many enterprise-level persistent mechanisms are chosen without reference to how easy running queries is.

Also not considered in the ability of a non-Java application to also access the persistent data (for eg. reporting reasons), or even separate VMs from accessing the persistent state. How many people are happy with their persistence choice tying themselves into a programming language?

I'm not slagging off anyone here, but this paper is pretty irrelevant for anyone choosing persistent mechanisms for genuine enterprise applications.

I wrote a blog on a providing a guideline to select a persistence solution
  What Persistence Solution Should I use today ?

regards
Debu

I think that Mr Jordan is still angry because his JSR 20 was rejected by the Java Community in 1999. This JSR wanted to add Orthogonal Persistance to the Java Platform.

http://jcp.org/en/jsr/detail?id=020

In Conclusion section, this Sun paper says ".. acceptable EJB performance is un-atinable .... "
This is news to Sun only.

As Cameron predicted in #6 in another thread, it's true!

The "other missing" popular persistance framework give you access to externalized SQL strings, making your designs tuneable for large systems.

.V

Why in the world would one want to traverse the entire object graph? I understand that it measures raw performance, which provides a good data point, but to draw conclusion about scalability from it feels a bit forced to me. Whether I'm using JDI, JDBC or EJB, I wouldn't want to traverse the whole object graph. does anyone actually do that in a "real" production system?

I blogged a bit on the use of persistence layers and uneccessary aggregate object models. The blog starts out with application vs business requirements, but finishes off with some of thoughts on wasteful persistence.

http://hookom.blogspot.com/2004/12/corporate-developer.html

that should be JDO not JDI. Even in cases where a process requires calculating aggregates, I generally try to avoid traversing a complex graph. Usually, it's better to flatten the data the model and index the data to make aggregations easier. Is there really a business case for traversing an entire object graph?

Is there really a business case for traversing an entire object graph?

In my blog, I hit on the idea of using JDO/Hibernate to leverage simple, case by case data models. Aggregation isn't really a business case, but an application case-- when do we need an account id vs an account object is dictated by the application layer.

The idea is using domain objects only at the application layer to support application requirements, this is only where aggregation takes place, otherwise "DataObjects" use a flat model for simplicity at the business layer. e.g. AccountData and OrderData are only associated by an ID in the business data model, it's up to the application's requirements to dictate fetched associations on a case by case basis. Plus, for the most part, flat DataObjects are a truer representation of the database model and thereby promote reusability (it's sometimes hard to reuse objects that have lots of aggregate relations).

In conclusion, it is clear that the impact of persistence on application code covers a wide spectrum,
as does the performance of the resulting system. OPJ has shown that it is possible to deliver
very competitive performance if support is added at the VM level. At the other extreme, acceptable
EJB performance seems unattainable at present unless dramatic changes are made to the application
object model to avoid fine-grain objects when mapped to EJB. While this approach is
now reflected in standard design patterns for EJB, the extra effort that it implies is disturbing
from the overall application design perspective. In contrast, JDO manages to achieve reasonable
performance at much lower impact on application design, while remaining agnostic to the nature
of the external data store. Therefore, at this time, JDO would seem to offer the best overall persistence
mechanism for demanding, object-oriented, applications. Note, however, that at the time
of writing, a new specification for entity bean persistence [Sun04] was being proposed for EJB
3.0 that would bring it much closer to JDO in spirit.

It is also nearly meaningless to compare performance results of one JDO 1.0 implementation with another, because the vast majority of the performance-impacting design decisions have nothing to do with the API. The underlying object-relational mapping, SQL statement generation, and caching strategies are what matter. (Ignoring non-RDBMS data stores is deliberate.) Those things have little or nothing to do with the JDO 1.0 API.

I recommend ignoring the performance testing section of that document altogether. The particular implementations that were tested are unlikely to be useful to you. Drawing conclusions about other implementations, based on some surface resemblance to any of the ones tested would be a fatal mistake, in my opinion.

Disclosure: I work for Xcalia (http://www.xcalia.com), makers of LiDO, a commercial JDO implementation.

I recommend ignoring the performance testing section of that document altogether.

I concur. Persistence performance is something that you need to test for yourself in your own environment. The more transparent the persistence solution, the easier it will be to test. That makes JDO, Hibernate, and other transparent solutions quite easy to test, as their impact on source code and container requirements are minimal to none. EJB 2.1 had so much source code-level intrusion that you essentially had to make your choice before choosing :) Beware of solutions like this.

--matthew

At the other extreme, acceptableEJB performance seems unattainable at present unless dramatic changes are made to the applicationobject model to avoid fine-grain objects when mapped to EJB.

IMO:

You should go for the coarse-grain architecture with remote interfaces

You should go for the fine-grain architecture with local interfaces

There is not almost any technical reason to use the remote interfaces between your serlvet and EJB containers. So you do not need to split servlet and EJB containers from same JVM and you can go with out any problems for the fine-grain architecture. The EJB object proxy overhead is relatively small and proxies are used probably by other frameworks also for e.g. transactional and security support ...

In contrast, JDO manages to achieve reasonable performance at much lower impact on application design, while remaining agnostic to the natureof the external data store. Therefore, at this time, JDO would seem to offer the best overall persistencemechanism for demanding, object-oriented, applications.

SUN's implements the EJB2.1 by JDO ...

EJB 3.0

It is interesting that EJB 3.0 is so well accepted (Hibernate3 will implement EJB3), but differences between EJB 2.1 and EJB 3 are IMO relatively minor:

- interfaces are gone
- bloated API is gone
- better query language
- support for the OO rich domain model
- annotations

IMO:
- performance of EJB 2.1 and 3 will be similar
- developer productivity with EJB 3 will be higher, but not twice. I believe just about 10-20%. I will not just implement couple of patterns (e.g. ServiceLocator) and some utility classes (e.g. implementation of EJB APIs, which are not used)

So I do not understand too much the hatred against the EJB 2.1 and almost absolute happiness about Hibernate, Spring and EJB3.

Your comments are welcomed.

DF

Hibernate3 will implement EJB3

Will it? EJB 3.0 compliance means also supporting older versions of EJB. Will Hibernate implement EJB 2.x? Will Hibernate implement Session beans?

I would expect that a combination of Hibernate AND JBoss will implement EJB3, but not Hibernate alone.

This kind of apparent misunderstanding is why I feel that the EJB 3.0 POJO persistence should have been a separate JSR.

So it's like having an anchor arround you neck.

1st step is to see if your project is not simple or not small. If it's small and simple then O/R is a choice.

Else, for more realistic proejcts, find a DAO that is E/R or ANSI SQL based. If you try it once, you won't go back to limits of O/R.

.V

1st step is to see if your project is not simple or not small. If it's small and simple then O/R is a choice.

IMO if you have small and simple app it does not matter. You can use O/R mapping DAO, JDBC DAO, XML DAO, file DAO, ... . Scalability and performance are not an issue

Else, for more realistic projects, find a DAO that is E/R or ANSI SQL based. If you try it once, you won't go back to limits of O/R..V

IMO for big huge scalable app you should go for a combination of all persistence technologies, because they have different +/-

O/R mapping DAO - DB cache; small amount of data accessed more then once

JDBC DAO - large amount of data; accessed once; usually big different searches

stored procedure DAO - stuff, which is slow or inefficient by JDBC; but keep in mind we want to move as much work as possible from DB to app server

On other side I am not also big friend of the rich OO domain model and I still believe that good ERD (E/R) is good ERD

Also you usually spend more money for Oracle than for your app server, so IMO it makes sense to try to use all DB features, because a probability you will go from the Oracle to DB2 or vice versa is usually small, if it is not defined by a project itself

DF

So it's like having an anchor arround you neck.1st step is to see if your project is not simple or not small. If it's small and simple then O/R is a choice.Else, for more realistic proejcts, find a DAO that is E/R or ANSI SQL based. If you try it once, you won't go back to limits of O/R..V

I would say its the exact opposite. For a very small project that might not need much modification or support, in may be appropriate to use ANSI SQL and simple DAO. For larger projects which need to be maintainable, have a longer lifespan and may require deployment on more than one DB, or future migration, O/R mapping can have huge benefits.

I would say its the exact opposite. For larger projects which need to be maintainable, have a longer lifespan and may require deployment on more than one DB, or future migration, O/R mapping can have huge benefits.

Steve, I do not think you can back that up. It sound like "Marketing Oriented Design." so don't belive the ads.
The ratings are at TPC.org, feel free to review scalability. One tuning aproach for a slow system is to remove O/R in favor of a better DAO. I have practical experience on large Terabayte systems.
.V
ps: What's the diff btwn a computer sales person and a used car sales person?
The used car sales guy knows he is lying to you.

Hi Vic,
i disagree with you about larger projects.
It doesn't make any sense to waste time for mapping 4 classes to 4 tables.
"Marketing Oriented Design" isn't really cool ;)

I'm a customer, expert in hibernate and dealing with 800 classes projects.
We are talking about "large" projects whith is not exactly the same as big data volume apps.

When talking about Terabytes System, for sure you must take advantage of any strong db features and a DBA is recommended.
But no matter, advanced ORM like Hibernate (surely JDO implemention does too) allows you to map optimized SQL and stored procedures instead of tables.

People have to forget the past ejb1 and 2, lets look at the present and future.

With ORM, big projects are easier to code, easier to maintain, i think more secure since all db access are under control of powerfull core.

And for the 1% of use cases which need specific db functions, there are solutions, DAO pattern also exists to mix ORM methods with JDBC methods.

Anthony

Annthony,
w/ respect, I think you are wrong.

People have to learn from the past, not keep doing it over and over. SQL is important, very mathematical and accrate way to represent graphs, trees, master/detail, group by having, set operations, etc.
800 classes is big? Anything that fits on a laptop is not big. Design mistakes become more acute on VLDB. It's a row boat in a harbor vs Ocen Tanker in the ocean. You turn a bit diferent.

People that only know one tool, they can only use one tool. (To a hammer everything is a nail). But learning SQL will help.

For example, lets say you want high performance in C :You go straigt for the record set and cache it. Not an Array[] of "Doors".
CRUD?

Set operations in SQL are much faster than row operations for one.
Use case: "give all customers that have purchased more than once in December a 10% gift cert". Say you have 10ns of millions of customers.
As a *set* operation inside of DB it is much more effecient than row by row. Ven diagrams, eh. Unions, intersections.

SO I urge people to learn SQL, such as "SQL for Smarties" by Celko. Even silly MS is basing Longhorne file system on DB trees. or try ADO.net.
O/R is a myth sold to people that are new to only one langage. But no skin of my back.
I wish you luck,

.V

Annthony,w/ respect, I think you are wrong. People have to learn from the past, not keep doing it over and over.

Part of my job is to correct past projects which have gone badly wrong by developing in obscure hand-coded db-specific SQL, which has hindered maintenance and prevented upgrading and migration. I am re-implementing using O/R, and the resulting new code is a fraction of the size, fast, and highly portable.

SQL is important, very mathematical and accrate way to represent graphs, trees, master/detail, group by having, set operations, etc.

Just the same as any powerful query language - like those used in modern O/R systems.

800 classes is big? Anything that fits on a laptop is not big.

Well, only a few years back, my 1GB memory latop with 80GB disk would have seemed very, very big indeed!

Set operations in SQL are much faster than row operations for one. Use case: "give all customers that have purchased more than once in December a 10% gift cert". Say you have 10ns of millions of customers.As a *set* operation inside of DB it is much more effecient than row by row. Ven diagrams,

Why do you assume that all O/R systems only work row-by-row? Good O/R will optimise, batch and combine actions expressed in terms of objects into minimal and efficient SQL. Modern query languages in O/R systems have comprehendsive set expressions.

... developing in obscure hand-coded db-specific SQL, which has hindered maintenance and prevented upgrading and migration.
... O/R will optimise, batch and combine actions expressed in terms of objects into minimal and efficient SQL.

There are is plenty of clients for us all.
;-)

.V

i think we should stop this topic here since Steve and i are happy with ORM and you Vic are ok with full SQL, we are ok that's excellent ;)

It seems you are not against ORM but simply against object mind.

Datastore is, of course, an important piece of an app but it is not 100% of an application, behind you have a lot of things to do.

OO model are done because they are easier to maintain, to reuse, to factorize code ... i can continue during one hour.

Full SQL apps are, de facto, static, more difficult to maintain since one modified column _may_ impacts several sql queries, and this is just one example.

Your first arg is about querying "give all customers that have purchased more than once in December a 10% gift cert":
  - first i can do it in HQL avoiding n+1 select if i want (you should read about this, n+1 problem can be solve easily today)
  - if i'm lazy, i just ask my dba to give me the SQL and use it with SQLQuery Hibernate API (many ORM may have the same feature), returned Customer will be persistant instances

And then? what if i decide to change customer properties, or customer.getMother().getDog() properties? you'll tell me that you're going to write a good "update" sql? of course.
I'll nothing to do, my ORM will detect if my instances have been modified, check for versionning, manage the cache, check major integrity in the java side without having to hit the database,... and much more.

Persistence is not only query.

Just about complex query, the following example works great and it is oo, the SQL generated is a monster but it is optimised:
select order.id, sum(price.amount), count(item)
from Order as order
    join order.lineItems as item
    join item.product as product,
    Catalog as catalog
    join catalog.prices as price
where order.paid = false
    and order.customer = :customer
    and price.product = product
    and catalog.effectiveDate < sysdate
    and catalog.effectiveDate >= all (
        select cat.effectiveDate
        from Catalog as cat
        where cat.effectiveDate < sysdate
    )
group by order
having sum(price.amount) > :minAmount
order by sum(price.amount) desc
(see hibernate doco)

Last word, do you think that coding a 3000 days app in 4 months, with 60 developpers in parallel is easy? Not it isn't but it is the real world, it is also very difficult to have 30 SQL experts, if you manage to have 40 advanced java developpers + 20 beginners you are lucky.

I don't need luck, i need productive solutions.

We have differents POV and both manage to do our job, there is no problem so.

coding a 3000 days app in 4 months, with 60 developpers in parallel.

My PoV is that... if the desing was normalized (Codd) ... you might have less work to do. E/R would help this project and the 800 classes person.

Using O/R does not make your project OO. That is a myth, by people that are not quite sure why/what OO is. For example PowerBuild is OO, but it does not do O/R. Etc.

it is also very difficult to have 30 SQL experts

Yes! VERY!
For example, what do I get if I do show plan or explain SQL on your example? How many can read that output and know if it's good or bad? Or know what optimizer is doing? (If you do a large web site... it's key. There is only one thing that will give you good results when it's in somone else's hands; and it has nothing to do w/ computers)
My main point is... more Java people should MASTER SQL. Slowest part of J2EE is data access.
Code genraters like you said that generate DAO / View based on columns are nice for marketing. Somone on the team better know what goes on.

We have differents POV and both manage to do our job, there is no problem so.

AGREE.
.V

Yes! VERY! For example, what do I get if I do show plan or explain SQL on your example? How many can read that output and know if it's good or bad? Or know what optimizer is doing? (If you do a large web site... it's key. There is only one thing that will give you good results when it's in somone else's hands; and it has nothing to do w/ computers)My main point is... more Java people should MASTER SQL. Slowest part of J2EE is data access.Code genraters like you said that generate DAO / View based on columns are nice for marketing. Somone on the team better know what goes on.

We have differents POV and both manage to do our job, there is no problem so.

AGREE..V

Please excuse me, but I am going to be persistent [sic] about my point here, and this may well be irritating to some people.

I have heard the same arguments put forward here about using and tuning SQL as I used to hear about using assembler decades ago. I remember the arguments about the adoption of C++ - that it would always be too slow, that hand-coded assembler was necessary for performance, and that a detailed knowledge of the register set for a processor was required.

Ok, it's not quite that bad, and I do feel that a knowledge of basic SQL (and relational theory) is certainly a good idea for Java coders, but I have to protest about your comments about the quality of SQL code generators. A HUGE investment has been put into O/R systems to ensure that the generated SQL is both high performance and tuned to the specific DB (just as in C++ compilers, a huge amount of work is put into optimising the resulting assembler).

I have a strong (and often unpopular) view that if you sit down in front of a specific DB and start to code a large project in SQL tailored for that DB you are storing up huge problems for the future.

First, suppose the next release of the DB has some dialect changes that improve performance. You are going to have to go through all your code and tweak it to handle the new features. If you use a quality O/R product, new releases of that product will have up-to-date knowledge of the DB and will deal with most of the optimisation automatically, and there will be minimal work for you.

Secondly, suppose the licensing scheme for the DB changes, (or company policy on tendering changes) and you are asked to provide a strategy for migrating your large application to an alternative supplier. Using an O/R product can mean that the migration could take only days or weeks as against months or years.

Thirdly, suppose you have to deal with a mixed supplier situation in which there are a variety of DBs installed. If you don't use an O/R, you will have to gain detailed experience of each DB. You can even have a heterogenous cluster of servers with different DBs.

Finally, using an O/R has the same sort of advantages as using Java: You can develop a product, and then allow the client to decide later on which platform and DB they wish to deploy. It's not going to be quite this simple, but to a large extent, this is true.

Note that using ANSI SQL is not a satisfactory solution, as you will not be able to use DB-specific features to gain performance. A quality O/R will know about, and use, these features.

So what is the answer? First, find out what modern O/R is really like - don't make out-of-date assumptions about how they work or about performance. Then, try out a high-quality O/R system, like Hibernate or one of the better JDO systems. Put work into tuning it, and learn the techniques to get the best from the product. Unlike with SQL, this experience is highly transferrable between different DBs. Only when you end up with very specific and serious performance problems, resort to direct SQL (most O/R systems allow this).

Please excuse me, but I am going to be persistent [sic] about my point here, and this may well be irritating to some people

Yes, me too, but it can be fun so indulge us.

I think your argument Steve comes down to that if you know Java, you don't need to know SQL.
That O/R will write better SQL than DBA's; that we don't need DBA's.
That production system full of data can be migrated easily to another vendor.
That Java will out live SQL.
There are all so hypotetical; to me it is all marketing.
Overall, I think that is a homogenous view. We live in hetrogeonous wourld, where SQL skills are needed.

I put forth my example application in Struts + iBatis that has 10MM members as example of E/R w/ 1 terabyte in proudction. ( http://wiki.apache.org/struts/PoweredBy)

Key point you forget is that applications move to where they are more efficient and effective.
If it's more expensive to operate O/R than E/R; they will fade, Darwin allways kills of organizations that are in-effective.
For example LAMP applicaitons.... no O/R here. Just good DB data model. J2EE w/ O/R is less efective(expensive to operate and maintain) than LAMP, they are more effective.

Theory-shmeory, it must pan out.

.V

I think your argument Steve comes down to that if you know Java, you don't need to know SQL.
That O/R will write better SQL than DBA's; that we don't need DBA's.
That production system full of data can be migrated easily to another vendor.
That Java will out live SQL.
There are all so hypotetical; to me it is all marketing.
Overall, I think that is a homogenous view. We live in hetrogeonous wourld, where SQL skills are needed.

No, I did not say these things. Perhaps you should read my post again more carefully, and reply to what I actually wrote, not what you think I wrote!

I did not say that you don't need to know SQL, on the contrary, I said:

I do feel that a knowledge of basic SQL (and relational theory) is certainly a good idea for Java coders,

Nowhere did I say that an O/R will write better SQL than DBAs, or that we don't need DBAs. I said that an O/R will save huge amounts of time as it will contain knowledge about specific DBs. This means it will hugely reduce the amount of work (especially coding) a DBA as to do.

I did NOT say 'That production system full of data can be migrated easily to another vendor.'. This is never easy! I simply said that it is faster to migrate a production system full of data from one vendor to another if you use an O/R for most of your application. Whatever your opinion of O/R, this is a pretty obvious statement.

I never even mentioned whether or not Java would outlive SQL, as this is totally irrelevant to the matters being discussed.

I totally agree that we live in heterogeonous world, where SQL skills are needed. It is good that a Java developer should understand SQL and relational theory, as these skills can be important in the design of a good object model in O/R, and also for coding SQL (if necessary) to optimise O/R. It's also important to be able to access and manipulate the data store beneath the O/R.

I can't understand why you insist on repeatedly saying that this is hypothetical and marketing. While you say this, thousands of developers are reaping the productivity and portability benefits of O/R in real applications. I am one of them.

Sorry .. but I could not let this pass:

J2EE w/ O/R is less efective(expensive to operate and maintain) than LAMP, they are more effective

I can follow why someone who does not understand O/R can assume that LAMP is easier to code than J2EE + O/R, but to say that J2EE + O/R is more expensive to operate and maintain than LAMP is just nonsense. I have implemented high-volume JSP+Servlet+JDO websites hosted on Tomcat + PostgreSQL. Once set up, the operation and maintenance costs have been close to zero. Why on Earth should my use of JSPs, JDO and PostgreSQL in place of PHP + MySQL involve any more costs? I also fail to see how they can be any more or less 'effective'.

Incidentally, I'm currently trying to install a large open-source PHP application, and it's taking some time because many of the packages don't include the specific SQL for PostgreSQL, and I'm having to code the scripts myself. In contrast, I have recently installed a very widely-used Java application that uses Hibernate. Installation on PostgreSQL was simple.

I can't follow why someone who does not understand O/R ....

.... I'm currently trying to install a large open-source PHP application ...

1. I know O/R and have used it. BUT... that is not the only DAO approach I know. In Java you can make choices, so you should know a SQL based on, such as iBatis, in adition to the _oQL.

2. There is a lot of people converting LAMP/PHP like you are. (ex: http://www.opensourcecms.com/index.php?option=content&task=view&id=388 ). Note that there is nothing that PHP can do that Java can't. It's just the choices made. After you master the SQL and E/R aproach, only then then can you add that to your bag of tricks in Java or C# or wherever.
If O/R proves to be in-effective, you can then try the other aproach and see if that gives your more sucess.
I have replaced O/R systems in the past, with iBatis and similar and had good results; that was my experience. You can know that it works since I gave you a large public site based on it.

Theory-shmeory, what's in production!

.V

I can't follow why someone who does not understand O/R ........ I'm currently trying to install a large open-source PHP application ...

1. I know O/R and have used it. BUT... that is not the only DAO approach I know. In Java you can make choices, so you should know a SQL based on, such as iBatis, in adition to the _oQL.2. There is a lot of people converting LAMP/PHP like you are. (ex: http://www.opensourcecms.com/index.php?option=content&task=view&id=388 ). Note that there is nothing that PHP can do that Java can't. It's just the choices made. After you master the SQL and E/R aproach, only then then can you add that to your bag of tricks in Java or C# or wherever. If O/R proves to be in-effective, you can then try the other aproach and see if that gives your more sucess.I have replaced O/R systems in the past, with iBatis and similar and had good results; that was my experience. You can know that it works since I gave you a large public site based on it. Theory-shmeory, what's in production!.V

There are LOTS of JDO/Hibernate/TopLink etc. ORM apps in production!!

I would say its the exact opposite. For larger projects which need to be maintainable, have a longer lifespan and may require deployment on more than one DB, or future migration, O/R mapping can have huge benefits.

Steve, I do not think you can back that up. It sound like "Marketing Oriented Design." so don't belive the ads.The ratings are at TPC.org, feel free to review scalability. One tuning aproach for a slow system is to remove O/R in favor of a better DAO. I have practical experience on large Terabayte systems. .Vps: What's the diff btwn a computer sales person and a used car sales person?The used car sales guy knows he is lying to you.

I am certainly not a marketer, and I also base my comments on actual experience. Certainly, badly implemented O/R can have real problems scaling, but well implemented O/R can speed development dramatically and greatly enhance maintainability and portability. Good O/R systems (such as Hibernate and quality JDO implementations) perform very well indeed - they can produce very optimised SQL tailored to the specific database engine (no need to stick with ANSI SQL as you might want to if you were hand-coding).

Hibernate3 will implement EJB3

Will it? EJB 3.0 compliance means also supporting older versions of EJB. Will Hibernate implement EJB 2.x? Will Hibernate implement Session beans? I would expect that a combination of Hibernate AND JBoss will implement EJB3, but not Hibernate alone.This kind of apparent misunderstanding is why I feel that the EJB 3.0 POJO persistence should have been a separate JSR.

Hibernate3 will implement the O/R persistence aspect of the EJB3 spec (check out Hibernate 3.0beta1 and Hibernate Annotations 3.0alpha1). JBoss will implement EJB3 on top of Hibernate3.

yes, I was not precise enough ...

DF

For the last 6 years, Sun has ignored or abandoned the Forest project (OPJ) with the fastest means of object persistence, electing instead to support one (EJB) which is inherently slow and overly complicated.

For the last 6 years, Sun has ignored or abandoned the Forest project (OPJ) with the fastest means of object persistence, electing instead to support one (EJB) which is inherently slow and overly complicated.

Perhaps that is because most large companies are not going to be in any way interested in a persistence mechanism that is single-VM, Java-specific and might instead want a portable, database-using, database-agnostic persistence solution with query, transaction (+rollback) capabilities.

Can you think of any project that needed persistence which considered both Serialization and EJB as viable alternatives? This paper is entirely academic - Sun is not as interested in developing an academic solition to an academic problem as it is in solving real-world problems where lots of money is on the table.

We should all give up on Java, design patterns and all this high level stuff. Let's go back to assembly, that will improve job security.

Sarcasm aside, the more I think about the article, the more I feel it has nothing to do with real world applications.

The paper itself may not be of much value to make any good judgements except if someone is looking for a comparison of the few products across the exact features that are compared. But look at the bright side.. Sun might after all be realizing and accepting publicly that EJB is bloated!

Right from the initial release of J2EE spec. (or for that matter with any 'enterprise' frameworks), the problem is one of perception. Why do most people think that they are all or nothing solutions? It was relatively hard to find anything on the internet (Sun J2EE tutorials/ documentation/ documents by others etc.) that is related to J2EE but does not talk about EJBs! The ratio of hits that you would see in Google between "J2EE" and "J2EE -EJB" was ridiculous to say the least! :-) I am sure there are others that would agree! But there were and are people who use J2EE minus EJB extensively! Same is the case with any other framework. None of them is a "one size fits all" and people who successfully use one framework for one project should come out of the "inertia" to use it again in their next project before looking at its needs and analyzing them!

Anyway, I digress! :-) I would have loved to see some research from Sun/IBM or one of those companies that have cultivated a large set of "corporate sheep" that listen to whatever they say, that could have boldly stated, "Do not use EJBs" or "Use them at your own risk" etc. when the spec first came out! But everyone was so drunk with the coolaid that people and organizations had to realize the shortcomings of EJBs only after using them and hitting the rock bottom of utter despair!

Then started the anti-EJB era and is growing ever since! So even though EJB 2.1 and 3.0 are 'better' than the initial monumental screwups, people now have a 'non-EJB' inertia that will stay for some time. Support for the spec from JBoss/Hibernate etc. will make this community a bit more acceptable with the latest versions. And even in the current specification, there is so much bloat.. if not for anything.. just for legacy compatibility sake! Which is not good and I dont think that Sun / IBM etc. would ever come out and say.. 'Dont use this subset of stupid features.. they are only for backwards compatibility'. So the viscious cycle might still go on!

And most of these alternate persistence frameworks (open-souce/commercial/home-grown etc.) have grown and matured out of the sheer frustration with something that came packaged with the 'J2EE enterprise framework'.. EJBs. And their success already proves the point that there is no 'one solution'.

So understand your needs in terms of your business application, look at all these comparisons (I can think of at least a dozen good comparisons on the net that cover at least a couple dozen good frameworks), then make a wise decision! And maybe EJB3.0 is the best solution for you, at the end of the day! Just use it wisely! :-)