Ari Zilka has posted "Since when did the 'P' in POJO come to stand for 'Pretend'," a blog entry discussing at length what defines a "Plain Old Java Object." It's an interesting definition, pointing out that if a.equals(b) && a!=b, you don't really have a good POJO.
So let's walk through the reasoning on that bit of code.
If a.equals(b), by definition the "important" properties of a are the same as the "important" properties of b. That said, there are some real issues of class instantiation here; a.equals(b)==true && b.equals(a)==false is perfectly reasonable if b.getClass() extends a.getClass(). Secondly, a point raised by Ari can be expressed in a sort of Groovy-like pseudoscript:A a=new A(1);
A b=new A(1);
assert a.equals(b); // true
assert b.equals(a); // true
assert a==b; // false
b.setValue(2);
assert a.equals(b); // false
assert b.equals(a); // falseWith this as his example, Ari says that a POJO's definition centers primarily about object identity.
But that's not enough: object identity is a tricky subject all on its own. So he helpfully walks through a full definition of what a POJO should be, including

A rule corresponding to Occam's Razor for POJOS: In order to be a POJO, a class must support strict object identity by operating directly on heap, cannot operate on system resources, and cannot expose system concerns.
One note from the discussion:

Note that Hibernate fails this test, but that is okay. We want it to. We are not working with plain Java objects but intentionally working with database rows; they happen to be abstracted as Java objects. As for Hibernate's attempt to simplify the database, it absolutely succeeds.
Spring passes the POJO razor due to the fact that dependency injection of POJO's into other POJO's implies that all those objects operate only on heap. When a non-POJO framework such as an O/R-mapper or a clustering library like JGroups or a JMS queue gets injected into application, the fact that the exposed system concerns spill into my application code cannot be avoided. This is because the framework / library / queue does not operate on heap but on system resources such as sockets. The non-POJO nature comes from the framework and not from dependency injection itself.

A software test harness - Ari's point here is easy to understand if you read it but difficult to summarize. Basically, a POJO should be able to be cleanly synchronized among multiple instances of an application (multiple JVMs, perhaps, or multiple instances of access). There's a lot of ground here to cover - and it's suggested you read Ari's actual discussion for it, because summarizing it loses most of its essence.

Ari's summary, cleverly disguised as the fourth part of the POJO definition, is pretty informative:

The value of POJO is in simplicity, and control. When the developer is in control of his object graph, from data types through object passing and references, he is in control of his domain model. Any framework that calls itself a “POJO framework” does so to connote simplicity and control. In the example above, Hibernate gave us control of our data types but we couldn't pass object references around. We needed to allow Hibernate to maintain the relationship between Departments and Inventory. In the example above, Spring gave us a way to factor out the impacts of serialization on our code, but we still could not pass objects by reference. We had to rely on dependency injection and Spring Beans to do the heavy lifting for us. And, when writing clustering code by hand, the code began to look nothing like its original form and we fear the long term maintainability and extensibility of that code base.
Without passing judgement on the value behind or the validity of any framework, most frameworks are not POJO because most frameworks fail the razor. Most frameworks are, however, trying to copy Spring's success in the market and assert that they help deliver cleanly factored code. The reality is that most frameworks that help factor out infrastructure and operational concerns do so with a combination of Spring and Hibernate, both of which fail the razor. Frameworks that use Spring or Hibernate do not produce any greater POJO-ness in applications than Spring or Hibernate themselves can. Quite the contrary. Spring makes non-POJO and otherwise leaky framework abstractions appear to be as POJO as any other Spring application.

One of the takeaways of this discussion centers around Terracotta, for whom Ari works: one of DSO's strengths is distributing a POJO (according to the definition Ari uses here, which is a strong definition) across multiple JVMs. It's an interesting technology, and a strong one.
What do you think of Ari's definition of a POJO?

The three rules of POJOs:
1. If you have to define it, it's not a POJO.
2. If you are actually trying to make a POJO, then it's not a POJO.
3. If you have to read someone's blog to figure it out, then it's not a POJO.
Sorry Ari, but arguing about what is or is not a POJO isn't helping you ;-)
Peace,
Cameron Purdy
Oracle Coherence: The Java Data Grid

What a ridiculous and arbitrary definition!
The whole article comes from one person's dislike of
Object.equals()
not that there isn't lots to dislike. :-)
According to this definition
java.lang.String or java.lang.Boolean
aren't POJOs, but boolean and int are?
What he has defined is PRIMITIVE Old Java Objects
not PLAIN Old Java Objects. :-)

Thanks for the insight Cameron. It reminds me of a Dangerfield quote: "he really seems to care. About what, I have no idea." :P
Seriously I contemplated hard just making the whole blog entry more akin to "I will know it when I see it" which a friend pointed out as his definition.
For those who are commenting about the focus on object identity, I suggest you read the original blog entry (http://blog.terracottatech.com) because the entry focuses on the razor's edge and not identity. I absolutely agree that failing .equals() is not, in and of itself lack of POJO-ness. I also do think several of your definitions below line up with the razor.
Thanks,
--Ari

I suggest you read the original blog entry (http://blog.terracottatech.com) because the entry focuses on the razor's edge and not identity. I absolutely agree that failing .equals() is not, in and of itself lack of POJO-ness. I also do think several of your definitions below line up with the razor.

Thanks,

--Ari

I did read it. Do you not define the 'razor' with this statement:
"In order to be a POJO, a class must support strict object identity by operating directly on heap, cannot operate on system resources, and cannot expose system concerns."
The other two items are restrictions (see my post above.)
Please explain how this is not focused on Object identity or please clarify what the 'razor' is.
The biggest problem I have with this is what appears to be quoting (or paraphrasing) attributed only to a friend.
"Here is the problem - how can two separate distinct heap objects be "equal" as in the sense of equals? What the does that mean. For example, if a.equals(b) && a != b is true, then we have some kind of mysterious object here."
What's mysterious about it? It's the difference between physical identity and logical identity. It's no more mysterious than if a.compareTo(b) == 0 && a != b is true.

If I call a.set(foo) does that mean that a.equals(b) continues to hold?

It depends on whether equals is defined in terms of foo or not. Let's assume for argument that the answer is no. Why is this unexpected? I agree that it is, in practice, often problematic build equals in terms of modifiable properties but this is not the same as saying that equals must be equivalent to ==. They are not the same concepts. There are also many cases where this can be useful, such as in a container object (such as a List).

Or has it now flipped from being true to being false??!?

Even with 100 question marks and exclamation points, this is not a novel question.

For "true" objects that it continues to hold, I would argue that the programmer expectations were met, but for ones where it is not held, then programmer expectations are horribly broken."

What programmer are you talking about. This seems way out of whack with reality. My experience is that a lot more programmers (especially those new to Java) expect == to be a shorthand for .equals() i.e. do a logical comparison, not the other way around: that .equals() is a long way to write ==.

I suggest you read the original blog entry (http://blog.terracottatech.com) because the entry focuses on the razor's edge and not identity. I absolutely agree that failing .equals() is not, in and of itself lack of POJO-ness. I also do think several of your definitions below line up with the razor.

Thanks,

--Ari

I did read it. Do you not define the 'razor' with this statement:

"In order to be a POJO, a class must support strict object identity by operating directly on heap, cannot operate on system resources, and cannot expose system concerns."

The other two items are restrictions (see my post above.)

Please explain how this is not focused on Object identity or please clarify what the 'razor' is.

Ah, I see. Very good point. The reason I defined the razor this was was to make it in terms of heap...not so much, object identity. I started with an arguably naive definition around JDK-only classes or no-imports but that is just wrong. First by example: JTA is in the spec and transactions don't seem POJO to me. In spirit: I think its about the system resources and concerns that leak back into our code.
You are right. I shouldn't have phrased the razor in such a way as to imply precedence on identity as opposed to what I meant which is identity as a test of system-dependencies.
With Terracotta I feel it is simple: applications that run on top of Terracotta will run identically on the single node if you remove our software. That implies a lack of restriction on programming model that I think is a good thing, no?

With Terracotta I feel it is simple: applications that run on top of Terracotta will run identically on the single node if you remove our software. That implies a lack of restriction on programming model that I think is a good thing, no?

That does sound like a good thing. If the point is that a framework that requires that Object are crafted in a special way is not a POJO framework, then I agree wholeheartedly. But I think the heart of 'POJO' is that is the framework's problem. The user of that framework should be able to make his/her objects as complicated as they need to be. This may be unrealizable.
Personally I think this POJO stuff has gone too far. The original point was to question the long list of things that we were not allowed to do in EJB 2. It was not to create an new list of things were are not allowed to do.

What programmer are you talking about. This seems way out of whack with reality. My experience is that a lot more programmers (especially those new to Java) expect == to be a shorthand for .equals() i.e. do a logical comparison, not the other way around: that .equals() is a long way to write ==.

Those programmers need to step away from the keyboard and be sent to a class on Java...one that includes a scored test so you can know if they actually learned anything.
BTW - I'm not calling them stupid, only ignorant. I came to Java from C++, and the whole "there are no pointers in Java," "everything is passed by value," and "==" on two semantically equivalent objects that were separately created return false confused the heck out of me. Ignorance can be overcome with education and/or experience. If/when that fails, then I'll call them stupid.

Those programmers need to step away from the keyboard and be sent to a class on Java...one that includes a scored test so you can know if they actually learned anything.

I'm not arguing that this should be the case. All I'm saying is that I don't agree that the average developer expects the .equals() method to always compare Object identities. Why would the method even need to exist?
Having said all that, there are some serious issues with how the equals method is used in Java libraries and code. We really need an Equalator in the JDK. The only reason I've ever seen out of Sun for not adding it are: 'it is the way it is and therefore should be that way' and 'it's too hard, waaaa waaaa waaaa'.

"In order to be a POJO, a class must support strict object identity by operating directly on heap, cannot operate on system resources, and cannot expose system concerns."

The other two items are restrictions (see my post above.)

Please explain how this is not focused on Object identity or please clarify what the 'razor' is.

The biggest problem I have with this is what appears to be quoting (or paraphrasing) attributed only to a friend.

"Here is the problem - how can two separate distinct heap objects be "equal" as in the sense of equals? What the does that mean. For example, if a.equals(b) && a != b is true, then we have some kind of mysterious object here."

What's mysterious about it? It's the difference between physical identity and logical identity. It's no more mysterious than if a.compareTo(b) == 0 && a != b is true.

James, Ari has been feverishly whipping this same one trick pony since he introduced the Terracotta thing. Terracotta replicates an object graph, so it maintains references. That's it. That's the whole thing.
Compare that to having two transactions going with Coherence -- each one will see a different copy of an object, which therefore (if you wish hard enough) can't be POJO.
The corporate blog entry linked to here is just marketing silliness disguised as technology.
Peace,
Cameron Purdy
Oracle Coherence: The Java Data Grid

Hello Cameron,
I want to point out to you that there is a O/R mapping tool which passes the constraint that article impose "In order to Be has POJO, has class must strict support object identity by operating directly one heap, cannot operate one system resources, and cannot exposes system concerns."
It acts of Oracle TopLink (your new colleagues of work) because all of read opreations use the same object instance (heap identity) contrary to hibernate.
In addition, i find damage that this advantage of Toplink is ignored so much so that much people end up thinking that the principles of "Identity Fields" used by Hibernate, Open JPA and the others are impossible to circumvent and that have is obliged to waste memory by making systematic copies of the objects!
T.albi

If I have a 100% POJO class and annotate it with e.g. the Annotations of Guice, will it remain a POJO?
If not then I do no longer care about this POJO zealotism. I dont want to have dumb code just to be able to look in the mirror and say "I only use POJOs, clean POJOs, I wont go to hell".

If I have a 100% POJO class and annotate it with e.g. the Annotations of Guice, will it remain a POJO?

If not then I do no longer care about this POJO zealotism. I dont want to have dumb code just to be able to look in the mirror and say "I only use POJOs, clean POJOs, I wont go to hell".

Damn straight. The whole "POJO" thing got started as a way of saying:
"We need a simpler, more practical component model that lets us express ourselves more naturally and doesn't get in the way of testing."
"POJO" was a reaction against the ideologues of the time who wanted to force impractical programming models down our throats. Picking a four-letter acronym was a clever marketing trick to put the more relaxed, loosely-defined "plain Java" programming model on an equal footing with competing component models like EJB(1/2).
Several years later, those of us who originally championed "POJO" frameworks and programming models don't even recognize the religious zealotry and downright impracticality that has now become common among people who use the term. According to folks in this thread, a POJO can't have any imports apart from java.util. WTF? This is antithetical to what POJO was originally about! The idea was to make programmers freer to implement things in natural, idiomatic Java. Not to force them into a different silly, arbitrary straitjacket.
I stopped using the word about 2 years ago. Occasionally, it still slips out, but most serious developers I know agree that the idea has outlived its usefulness. We need fresh thinking if we want to progress beyond the current stagnated state of enterprise Java development. Some fresh thinking can be found here:
http://code.google.com/p/google-guice/
and here:
http://labs.jboss.com/jbossseam
These new projects (the third-generation component models for Java) are about providing practical solutions to real problems that minimize code and minimize ideology. They are about getting back to work after the "POJO" hangover from drunken nights of EJB2.

If I have a 100% POJO class and annotate it with e.g. the Annotations of Guice, will it remain a POJO?

If not then I do no longer care about this POJO zealotism. I dont want to have dumb code just to be able to look in the mirror and say "I only use POJOs, clean POJOs, I wont go to hell".

Why not? Annotations are great, they don't force you to change your design, they just decorate your objet. Nothing wrong with that. In fact, annotations are a really great replacement to the old way "implements this interface", "extend this class", ...

I don't like it. Object identity is just a technical artifact of the JVM...a leaky abstraction. Defining object equality is hard, but I think if it is equivalent to identity then you haven't really defined a domain object. Domain objects should have a meaningful definition of equality.

I think it's filled with some highly flawed logic. The equals() method is a simple comparison method. It has nothing to do with == other than that is the default implementation. The idea that == and equals are inherently tied is just assumed. I don't see much of anything that really convinces me that this must be the case.
And I find this statement very ironic: "All these components amount to breaking down POJO into "plain" meaning just the Java language [u]without restrictions on its use[/u]"
Question: Is disallowing a customized equals() method a restriction of the use of the Java language? I think it *might* be. How about the following from the "list of components of the definition of POJO that should matter".
* No proxies
* No identity fields
* No Manager
Maybe I'm crazy but these sound like restrictions to me.
I also don't really follow why overriding equals means I can't pass references around.
I think there are some decent ideas here but I get a bad taste in my mouth from these apparently illogical statements. Maybe it's just these bad coffee beans I bought.

Think I hadn't seen such a philosophical view on POJO's either.
My three rules of POJOs:
1. If it doesn't have any import statements, its a POJO.
2. With the exception of import java.util.* and I would believe any other class in Java SE, then it would be sort of a POJO, since it doesn't have any dependencies on external APIs.
3. If you need to import anything else, its definitely not a POJO.

2. With the exception of import java.util.* and I would believe any other class in Java SE, then it would be sort of a POJO, since it doesn't have any dependencies on external APIs.

3. If you need to import anything else, its definitely not a POJO.

So if I introduce a dependency w/o using an import statement it's a POJO, but if I use a import statement to saving typing, it's not a POJO?
I certainly understand the need to manage dependencies, but doesn't striving for zero external dependencies really reduce the possibility of code reuse? What if I want my POJO to do some math, do I have to code it by hand instead of using Commons Math?

2. With the exception of import java.util.* and I would believe any other class in Java SE, then it would be sort of a POJO, since it doesn't have any dependencies on external APIs.

3. If you need to import anything else, its definitely not a POJO.

So, it it uses just Standard Java libraries then it might be a SPOJO. If it use "enterprise" libs then it is a EPOJO. If it uses third party libs then it is a TPOJO (don't pronounce that with anyone in front of you).

2. With the exception of import java.util.* and I would believe any other class in Java SE, then it would be sort of a POJO, since it doesn't have any dependencies on external APIs.

3. If you need to import anything else, its definitely not a POJO.

So, it it uses just Standard Java libraries then it might be a SPOJO. If it use "enterprise" libs then it is a EPOJO. If it uses third party libs then it is a TPOJO (don't pronounce that with anyone in front of you).

2. With the exception of import java.util.* and I would believe any other class in Java SE, then it would be sort of a POJO, since it doesn't have any dependencies on external APIs.

3. If you need to import anything else, its definitely not a POJO.

This is how you create a struct that pretends to be an Object. I'm quite sure that this is not what Martin Fowler meant when he came up with the term POJO. His point was that Java developers should be able to write code in Java with all it's features and not some subset of the language or restricted arbitrary design constraints. What you are saying here is the exact opposite of that. I think he was actually thumbing his nose at concepts like this.

This is how you create a struct that pretends to be an Object. I'm quite sure that this is not what Martin Fowler meant when he came up with the term POJO. His point was that Java developers should be able to write code in Java with all it's features and not some subset of the language or restricted arbitrary design constraints. What you are saying here is the exact opposite of that. I think he was actually thumbing his nose at concepts like this.

I agree 100%. A POJO != a domain object, devoid of any behavior at all. It's a true, fully-featured object, the kind we all pictured in our heads when we first started learning the OOA/D.
Object identity is an interesting question, but has very little to do with the "definition" of a POJO. At least for me, I can't remember the last time I coded a bug related to object-identity outside of contrived OOP course exercises that were really just testing knowledge of the JVM. And that was years ago.

It can be a DTO/VO as well to push the point. Sometimes POJO's are just helper objects.
Domain objects can have some behaviour. A colour object may return an RGB, CMYK or another representation as a possible example.
POJO is more a classification that may or may not be applied to any useful object and your philosophy of how a project works. I'm sure everyone's Venn diagram of such would differ.

And I guess its ok to have imports for packages on your own Domain Model. I simply couldn't care less on the definition of pojo, for me anything that isn't restricted by an specification or interface contract.

A POJO to me, is just an object whose design is not influenced or forced by any framework or library. POJOs matters because as the Spring team say, OO is more important than any implemetation or technical constraints. Beeing free of those constraints is the only way to build an effective and powerful domain model representing your business domain. Of course, this is the ideal world, your objects always have to respect some minor constraints as with Hibernate (constructors, collections, ...) or Spring (JavaBeans properties).
The best example of a framework not POJOs friendly is EJB 2 : your objects have to implements some interface, entity beans don't support inheritance, session beans force your methods to throw remote exceptions, ... There are also some less obvious examples in the standard java libraries, for instance implementing the comparable interface (a abstraction meanlingless to the business domain) in order to use the Collections methods.
It doesn't have anything to do with your import declarations but just about the degree of freedom you have when designing your objects.

There are also some less obvious examples in the standard java libraries, for instance implementing the comparable interface (a abstraction meanlingless to the business domain) in order to use the Collections methods.

It doesn't have anything to do with your import declarations but just about the degree of freedom you have when designing your objects.

If an Object implements an interface, it's no longer a POJO? How many restrictions can we come up with in the name of eliminating restrictions. Interfaces are part of the Java language, why shouldn't a POJO be able to implement them?
On a side note, I would also disagree that a Comparable implementation is necessarily meaningless to the Business Domain. If it is meaningless and you have no ordering for your objects, I don't see why you would implement the interface. If you needed to use sorting that was not based on anything in the business domain (I'm not sure what that would look like), use Comparators instead.
To me the term POJO should mean: Just write the code that makes sense for your design. To say that interfaces are now forbidden is dogma that is almost as bad as the EJB dogma. Java is not SmallTalk and it never will be. Interfaces are the king of Java abstractions.

On a side note, I would also disagree that a Comparable implementation is necessarily meaningless to the Business Domain. If it is meaningless and you have no ordering for your objects, I don't see why you would implement the interface. If you needed to use sorting that was not based on anything in the business domain (I'm not sure what that would look like), use Comparators instead.

Duh...
Let's say a Quarter is one of your domain objects (as in 1/4 of a year). Quarters are quite naturally ordered. I would say that is fairly fundamental to the domain model.

On a side note, I would also disagree that a Comparable implementation is necessarily meaningless to the Business Domain. If it is meaningless and you have no ordering for your objects, I don't see why you would implement the interface. If you needed to use sorting that was not based on anything in the business domain (I'm not sure what that would look like), use Comparators instead.

Duh...

Let's say a Quarter is one of your domain objects (as in 1/4 of a year). Quarters are quite naturally ordered. I would say that is fairly fundamental to the domain model.

But we should create our own ordering interface in order to remain POJO. Or we could use reflection and pull off a method with a specific name to avoid an interface at all. It's much better to have the required method buried in documentation than in your code. Or if we could only see the value of the pointer, we could use that for ordering. I suppose the identityHashCode could suffice. Lastly, we could use magic to order our objects. I'm not sure that magical objects are POJOs though...
;-)

On a side note, I would also disagree that a Comparable implementation is necessarily meaningless to the Business Domain. If it is meaningless and you have no ordering for your objects, I don't see why you would implement the interface. If you needed to use sorting that was not based on anything in the business domain (I'm not sure what that would look like), use Comparators instead.

Duh...

Let's say a Quarter is one of your domain objects (as in 1/4 of a year). Quarters are quite naturally ordered. I would say that is fairly fundamental to the domain model.

But we should create our own ordering interface in order to remain POJO. Or we could use reflection and pull off a method with a specific name to avoid an interface at all. It's much better to have the required method buried in documentation than in your code. Or if we could only see the value of the pointer, we could use that for ordering. I suppose the identityHashCode could suffice. Lastly, we could use magic to order our objects. I'm not sure that magical objects are POJOs though...

;-)

Well Comparable was introduced in Java only because the language has no concept of closure. The only way to circumvent the problem at the moment, would be to implement a sort() method asking for a method sorting name as a parameter or using an inner class. So in order to make things more simple, Sun made this minor trade-off. However, the truth is that Comparable forces your domain model to a certain design and we should try to prevent it as much as it is possible. As I said there will always be implementations constraints to deal with but those should be a exception when there is no easy solution.

Well Comparable was introduced in Java only because the language has no concept of closure.

That's really neither here nor there. If the Comparator were a closure, it would still have the same structure.

The only way to circumvent the problem at the moment,

What's the problem exactly?

would be to implement a sort() method asking for a method sorting name as a parameter or using an inner class.

So you'd require that the objects have a sort() method. How would you specify this requirement?

So in order to make things more simple, Sun made this minor trade-off. However, the truth is that Comparable forces your domain model to a certain design and we should try to prevent it as much as it is possible.

Well Comparable was introduced in Java only because the language has no concept of closure.

That's really neither here nor there. If the Comparator were a closure, it would still have the same structure.

I'm discussing the Comparable interface here. I have nothing against implementing a new Comparator (in fact this is what I do most of the times using an inner class), I just find it cumbersome.

The only way to circumvent the problem at the moment,

What's the problem exactly?

Well if you don't want to write a Comparator, some classes in your domain model have to implement Comparable, a technical interface meaningless to your domain model. If it wasn't of the Collections class, would you have implemented this interface? As I said this is still a very minor constraint and you shouldn't worry too much about it but I do think that you should be aware that you are twitching your design to respect some implementation details. The key is to not go too far, *cough*EJB 2*cough*.

would be to implement a sort() method asking for a method sorting name as a parameter or using an inner class.

So you'd require that the objects have a sort() method.

No, I said you could have something like that Collections.sort(Collection collection, String sortingMethodName)

So in order to make things more simple, Sun made this minor trade-off. However, the truth is that Comparable forces your domain model to a certain design and we should try to prevent it as much as it is possible.

How does it force a certain design? What does it force you to do?

It forces your class to implement an external interface, an abstraction that isn't derived from your domain model and has nothing to do with your business. And I'll say it again, this is probably not a problem in most cases but you have to be aware that you are modifying your design solely based on some implementations reasons, which is not good once you cross a certain point. Annotations or closures would be a much better solution here since they don't have any effect on your design. Add more interfaces as Comparable and your code will become more bloated and harder to understand.
My point was that what we call POJOs aren't actually most of the time 100% real POJOs even though they are very close to it. Depending of the framework you use, your design still has to respect some rules. Of course, those are really minimal nowadays compare to the EJB 2 days thank to good open source solutions as Spring and Hibernate.

Well if you don't want to write a Comparator, some classes in your domain model have to implement Comparable,
Why do you 'have to implement Comparable'? Specifically. I actually want you to explain what necessitates implementing this interface.

a technical interface meaningless to your domain model. If it wasn't of the Collections class, would you have implemented this interface?

If I didn't need to order the Objects I would not. If I need to order the Objects, I have to tell the sorting code how to do it in some way.

As I said this is still a very minor constraint and you shouldn't worry too much about it but I do think that you should be aware that you are twitching your design to respect some implementation details.

Whether the Objects sorted or not and how they are sorted 'is' part of my design. Why do you think it is not?

No, I said you could have something like that Collections.sort(Collection collection, String sortingMethodName)

Why is this better? What Object would sortingMethodName refer to? This is exactly what Comparator accomplishes. You can do this now and not implement Comparable which is exactly what I pointed out already.

It forces your class to implement an external interface, an abstraction that isn't derived from your domain model and has nothing to do with your business.

If your objects don't have a natural sort order, why are you implementing this? You are not forced by the JDK to do so, even if you want to use built in sorting functionality.

And I'll say it again, this is probably not a problem in most cases but you have to be aware that you are modifying your design solely based on some implementations reasons, which is not good once you cross a certain point. Annotations or closures would be a much better solution here since they don't have any effect on your design.

Comparator, Comparator, Comparator.

Add more interfaces as Comparable and your code will become more bloated and harder to understand.

My point was that what we call POJOs aren't actually most of the time 100% real POJOs even though they are very close to it.

We are discussing what POJO means. You are assuming that your definition is correct. Specifically, I am questioning your definition.
If a framework requires you implement Comparable, then yes, it's not a POJO framework. But if I want to implement Comparable or any other interface for my own reasons, it doesn't mean I'm not using POJOs. Actually it's the essence of POJOs as stated by Fowler: using the full scope of the language to create Objects.

I think Camerons hit the nail on the head. ObjectGrid also worries about transactions and a transaction implies a copy to isolate different threads against half committed changes.
ObjectGrid allows programmers to disable copies if required which provides a more non transactional view from an isolation angle. This provides more performance by disabling the copy but you can't rollback now (you changed the original copy) and any changes made are immediately visible to other threads. The transaction is still used to bracket changes together from a replication viewpoint but this kind of optimisation isn't for the feint of heart.
Another angle here is simply supporting graphs of objects. ObjectGrids EntityManager APIs allow each object to be a map and ObjectGrid automatically manages relationships between those objects/maps which is a simpler than dealing with it all using the old style Map APIs but there is a performance cost to doing this form of bijection. Nothing is free.
Billy

Well if you don't want to write a Comparator, some classes in your domain model have to implement Comparable,

Why do you 'have to implement Comparable'? Specifically. I actually want you to explain what necessitates implementing this interface.

Because you want to sort your objects... Of course, sorting is part of your business logic, that's not what I'm saying. But actually are your caring about your objects being comparable or how? Every objects can be compared and more importantly in more than one way. This is the problem I have with Comparable. It only tells you that an object is Comparable but not in what way. Actually telling if an object is Comparable or not is a Collections concept. What would you say about a date, that a String is shorter than another one or that compared to this other String, it comes before?
And I have never said I don't want to write Comparator, I said that Comparable is putting some constraints on your model.

a technical interface meaningless to your domain model. If it wasn't of the Collections class, would you have implemented this interface?

If I didn't need to order the Objects I would not. If I need to order the Objects, I have to tell the sorting code how to do it in some way.

Well in my case, the method would be isBetter() or isShorter() because Comparable only convey the information that this object can be compared in some ways. See my answer above. I still think this has no business meaning, it's a method imposed by the Collections class.

As I said this is still a very minor constraint and you shouldn't worry too much about it but I do think that you should be aware that you are twitching your design to respect some implementation details.

Whether the Objects sorted or not and how they are sorted 'is' part of my design. Why do you think it is not?

Exactly, how they are sorted is part of your model not that they are comparable. Telling if an object is comparable is a collection concept.

No, I said you could have something like that Collections.sort(Collection collection, String sortingMethodName)

Why is this better? What Object would sortingMethodName refer to? This is exactly what Comparator accomplishes. You can do this now and not implement Comparable which is exactly what I pointed out already.

Stop bringing the Comparator, I never said it is not doable using a Comparator. In fact, as I said in my previous post, most of the time I use Comparator. I just pointed out that java objects implementing Comparable are not pure POJOs to me. You may not agree but the point is not about if it doable or not using a Comparator.

It forces your class to implement an external interface, an abstraction that isn't derived from your domain model and has nothing to do with your business.

If your objects don't have a natural sort order, why are you implementing this? You are not forced by the JDK to do so, even if you want to use built in sorting functionality.

Your object may have more than one natural sort order. For instance, a String can be sorted by length, alphabetically, ... The name compareTo() just tell you that the object can be compared

And I'll say it again, this is probably not a problem in most cases but you have to be aware that you are modifying your design solely based on some implementations reasons, which is not good once you cross a certain point. Annotations or closures would be a much better solution here since they don't have any effect on your design.

Comparator, Comparator, Comparator.

Seriously, you should learn to be a little more polite.
I said many times Comparator is the best solution out there at the moment but it can be a little bit cumbersome sometimes. Defining an inner class just to order some objects can be annoying at moment, well it is to me. Actually, I was just pointing out that closures and annotations could be good non invasive solutions.

Add more interfaces as Comparable and your code will become more bloated and harder to understand.

My point was that what we call POJOs aren't actually most of the time 100% real POJOs even though they are very close to it.

We are discussing what POJO means. You are assuming that your definition is correct. Specifically, I am questioning your definition.

I don't assume my definition is correct, I am just writing my opinion on the subject...

If a framework requires you implement Comparable, then yes, it's not a POJO framework. But if I want to implement Comparable or any other interface for my own reasons, it doesn't mean I'm not using POJOs. Actually it's the essence of POJOs as stated by Fowler: using the full scope of the language to create Objects.

Well you implements Comparable to use Collections services. If it wasn't of Collections, your object would never implements Comparable. Personally, I would have method named isBefore(), isShorter(), isAfter(),...

Well if you don't want to write a Comparator, some classes in your domain model have to implement Comparable, a technical interface meaningless to your domain model

How on Earth is Comparable meaningless to your domain model? Ok, I don't know your domain model, so maybe it is, but some things have a natural ordering. Ordering is a very fundmental concept. Having interfaces like Comparable allows such concepts to be clearly expressed across class hierarchies.
Comparable makes the domain model easier to understand.

Well if you don't want to write a Comparator, some classes in your domain model have to implement Comparable, a technical interface meaningless to your domain model

How on Earth is Comparable meaningless to your domain model? Ok, I don't know your domain model, so maybe it is, but some things have a natural ordering. Ordering is a very fundmental concept. Having interfaces like Comparable allows such concepts to be clearly expressed across class hierarchies.

Comparable makes the domain model easier to understand.

Well I'll agree that ordering is fundamental and that's part of the domain model but Comparable is still a technical interface to me. Actually, in the real word do you say that two date are comparable? Of course they are, every objects is comparable and in more than one way. Actually, what matter to your domain is how they are comparable? So I rather have a method called isShorter() or isBefore() than a method called compareTo(). It's a lot more talkative to me.
And what happens if an object doesn't implement Comparable, does it mean that it can be ordered? Some object don't implement Comparable just because they can be ordered in more than one way. For instance, let's say I am extending the String class and I want to be able to sort String alphabetically or by length. So what ordering should I implement in a compareTo() method? I would say it's much better to have two different functions, isShorter() and isBefore().

Actually, what matter to your domain is how they are comparable? So I rather have a method called isShorter() or isBefore() than a method called compareTo(). It's a lot more talkative to me.

Because it unifies the concept of ordering into a single interface. When you implement Comparable you are expressing a concept that transcends your domain model. Using a single interface to express the concept unifies it. Using object-specific names obfuscates the higher-level concept. "isBefore" is a nicer tree, but "compareTo" fits better into the forest. Besides, there's no reason why you can't have both. isBefore, equals, and isAfter could all be implemented in terms of compareTo.

And what happens if an object doesn't implement Comparable, does it mean that it can be ordered?

It means that there isn't a single natural ordering. Most objects probably don't have one. In the case of objects with several equal orderings, I would define several singleton comparators for achieving those orderings and put them on the class (to make it obvious they are the orderings, and encourage reuse). If there is one major natural ordering, and several far lesser, I would implement comparable with the major means, and provide comparators for all of them.
If an object has no natural ordering, I would neither implement comparable nor provide comparators.
In the event someone has their own, creative ordering, then they can write their own comparator.
The key is that there is a dominant, natural ordering. Otherwise I would not implement comparable.

For instance, let's say I am extending the String class and I want to be able to sort String alphabetically or by length. So what ordering should I implement in a compareTo() method? I would say it's much better to have two different functions, isShorter() and isBefore().

equals() must test object identity (it returns true iff the two objects are the "same", whatever "same" means).
The type of identity (content based or instance based) is a feature of the particular class.
In this respect the noted example
a.equals(b) == true
with the possibility to have
b.equals(a) == false
I think it is a non-sense.
So, object identity testing should always be performed using equals() method.
== operator should be used to test object references (pointer, just to start another flame about Java/C++) equality.
Guido

Per the javadocs, Object.equals() must implement an equalivalence relation. It must be reflexive, symmetric, and transitive.
The idea that equals() should always be equivalent to == is complete crap. You only make that kind of statement if you don't understand equals(). Equals is the canonical equivalence relation for a class as defined by it's designer. It allows you to discover that objects constructed at different times have the same logical identity. He just ruled out all value objects like RGB triples from being POJO's! Um, no.
He states "Proxies break .equals()". No they don't. A proxy may or may not be equal to it's proxy object. It's up to you. Hibernate tools, for example, generates proxies that are equal to their antecedents per the equality definition they generate.
For the record, the correct, entire definition is: "POJO == java bean". Translation to the clue impaired: no arg constructor, serializable, accessors follow the get/set naming conventions (use is instead of get for booleans). End of story. If this guy wants to talk about other concepts, he needs to get his own term.
His complaints about equals are idiotic:

First off, c.set(foo) isn't very POJO like. It probably should be c.setFoo(foo). Second, at the end a.equals(b) may be true or not, depending on what these objects are. If they are colors defined as Red/Green/Foo triples, then this sequence just changed b and c to Blue, which is different from a. On the other hand, if they're people and Foo is their favorite color, then we don't have a new person because they changed their mind about their favorite color! Both are completely reasonable bean/POJO behavior.

Not exactly sure how you came up with the .equals() being the thesis - since it's not (James Watson figured that out 20 responses back...)
What I am not sure I get, and it seems I am in the minority with respect to the entire list of posters on this thread, is that POJO ought to mean PLAIN (nothing fancy in particular nothing "artificial") OLD (non sequitur) JAVA (the Java language) OBJECT (Object oriented), yet the proponents of "POJO" - and most on this list - seem to think Object Identity can, should and is really not a problem if broken.
Now, let me make an example. If I have an account domain object, if I write it as a POJO, I might, for example, write:
public class Account
{
long balance;
...
public synchronized withdraw(long amt)
{
balance -= amt;
}
}
Now, I have done this because presumably I want to ensure that balance doesn't have synchronization errors (a thread race could cause one or more withdrawals to magically disappear (depending on the severity of the race and the number of participants).
But wait a second, when I start using "POJO" frameworks that try to model this, I can no longer rely on synchronization working because the identity of my object has been broken, furthermore, if my object instead looked like:
public class Account
{
long balance;
public synchronized void withdraw(long amt) throws InterruptedException
{
while (balance < amt) {
wait();
}
balance -= amt;
}
public synchronized boolean deposit(long amt)
{
balance += amt;
notify();
}
Now I am really hosed - even if I added some kind of external locking (not shown) because there is no way any of these frameworks enable wait or notify.
In other words, if I am using "POJO" frameworks, I am told I can't use synchronization, and I have to switch to transactions (meaning I MUST use Spring Txns, JTA explicitly, or within a container) or I have to use a frameworks locking mechanism (external code that is certainly NOT POJO) AND worse yet I MUST make sure that nowhere I am holding references (or they will be stale) to objects outside of the locking strategy I am using with that particular framework (Hibernate btw does an excellent job here, as Ari himself points out, of normalizing the process of getting and releasing references, but you still have to get and release)
So getting back to the POJO definition, if it's a Java Object, I should be able to write idiomatic Java which includes synchronization, No?
Incidentally, Ari's blog goes into all of this using real code...

the identity of my object has been broken
What? synchronized uses the actual object. What "identity" has been broken? An object is an object. From the point of view of synchronized you have different objects if you use some form of serializing/deserializing to get . It is too low level to work in a situation where the programmer's semantics dictate two objects (equal in a semantic sense) should act as one.
So, yes, if you want two objects to be treated the same you cannot rely on synchronized. But IMHO as soon as you need to use synchronized or something like it, the objects are no longer "plain" anyway. You want to put the logic you use synchronized for here into external, managing code, wether you roll-your-own or use a framework like Spring.
The "plain" in "POJO" should mean "dumb".

You gotta be freakin' kidding me! You seriously think that customers should actually build apps like that? Wow, that explains a lot ...
OK, let's assume you were just joking. Let's think about something simple. You have an Account object, and it stores a balance. What if you want to transfer money from one account to another? Add a method called transferTo() that takes an account and an amount to transfer, right?

public synchronized boolean transferTo(Account acctTo, long amt)
{
// I assume that if there are "insufficient funds" etc.,
// then this returns false
if (withdraw(amt))
{
// this MUST NOT fail or we lose the money!!!
acctTo.deposit(amt);
return true;
}
else
{
return false;
}

Looks harmless enough, doesn't it?
Nope. You just built a deadlock mechanism!
(For reference, the deadlock is caused when account A transfers funds to account B at the same time that account B transfers funds to account A. Since this is Java, the only way to resolve such a deadlock is to kill the JVM.)
Now you know why engineers build applications on top of transactional systems: the synchronization primitives in the Java language do not support composable transactions.
So the only "identity necessary" example you came up with was some sort of notification hack that would make most engineers wretch, and would serve as a likely future basis for creating deadlocks.
Don't take this personally. The problem isn't the technology; it's with the desire to misapply the technology, or at least to misrepresent it. And the inane arguments about POJOs only serve to highlight that.
Peace,
Cameron Purdy
Oracle Coherence: Data Grid

I wasn't trying to hide the fact that I work for Terracotta, sorry if it came across any other way.

No, I didn't think you were hiding it; I just wanted to make sure you thought to include it, particularly since the topic is related to your work. It helps people reading to understand what your context is (e.g. background, point of reference, set of experiences, etc.)
Peace,
Cameron Purdy
Oracle Coherence: Data Grid

My 20p worth.
As long as;
a). I'm not forced to implement some weird (non-jse) interface or parent-class, and/or
b). I don't have to rely on AOP (or some silly container/ AOP object factory - including Hibernate and Spring), and/or
c). There's no under-the-cover (hidden) AOP going on (including instrumenting the JVM aka Terracotta style)
...to make use of my object, then it's probably a POJO.
Anything else is in no way "plain".
ASIDE: Mind you, who uses the term POJO these days apart from vendors? I mean we see a lot of vendors saying their products support POJO's when really they are massively runtime decorated proxies. ie: You write what you think is a POJO, and then at runtime it is completely murdered. Perhaps we need to clarify the difference between a design-time POJO and it's runtime representation? Perhaps this is all just bonkers?
For me anything else is a CUBIJO - Completely Useless By Itself Java Object.
NOTE: Annotations and bizare definitions of equality rarely changes POJOs into CUBIJOs.
In some ways I like Ari's specification that POJOs must be simple heap objects... but my rule c). means Terracotta POJOs are closer to CUBUJOs. Perhaps for Terracotta they should be CJOs - Clustered Java Objects? Perhaps Ari should create his own *JO like I did with Oracle Data Grid Beans... sure they look like POJOs at design time, but at runtime there's a bit of magic going on. I certainly don't want to imply that DGBs are POJOs ;)
Anyway, now back to reality.
-- Brian
PS: I work for Oracle.

Ah... yes. sorry. My fault. Terracotta doesn't change the object representation it mutates the class-class bytecode (right?). So according to my own rules, POJOs in Terracotta are in fact POJOs (damn it I may have stuffed up?).
However, if Terracotta mutates the underlying representation of the classes and we consider classes themselves to be first-class objects (which in most OO languages they are), then it does break my rules. :) I'll leave that to the public to debate (if anyone can be bothered)
This is probably completely off point, but I thought mutating the class representations by overriding/replacing the rt.jar or bootstrap.jar as Terracotta does (if I'm correct) is a violation of the Java License? I do remember in the early days of Java, Sun saying this sort of thing was a big no-no for security reasons. Perhaps they've relaxed those requirements? Mind you, if a system does this it would be an easy way to inject rouge code into the JVM, especially in an open-source project with a custom project build.
But... let me make this completely clear, what Terracotta does is pretty cool. Just not sure I've ever use it - but that's just the types of projects I work on. Certainly given the example code above, I'd probably steer very much away from it.
In summary I contend that in Terracotta you no longer have PJCs (Plain Java Classes), you have TIJCs (Terracotta Instrumented Java Classes). You do have POJOs (according to my own rules) so long as you don't take TIJCs into account.
Of course, now working for Oracle, everything gets it's own acronym.
Have fun.
-- Brian
PS: While I work for Oracle, these are my own thoughts.

However, if Terracotta mutates the underlying representation of the classes and we consider classes themselves to be first-class objects (which in most OO languages they are), then it does break my rules. :) I'll leave that to the public to debate (if anyone can be bothered)

Right a class is meant to be a first class object, but in Java it isn't. This is the problem, Java is not a fully OO language. Hence the re-usability of OO components we were promised has never been realised. Where is the market in third party Java Beans or EJBs? It doesn't exist. But you can get plugins for Rails all over the place.
So what we are left doing with Java is trying to late bind, with a static language. Hence all this messing about with byte code, XML and annotations.
POJOs were meant to be a replacement component model for EJB1/2. But on close inspection POJOs aren't really components. They are objects that are loosely/late-bound to their container through techniques such as DI and runtime byte code manipulation.
You cannot extend and re-use a POJO without the source code. The only real benefit of the whole POJO idea is that due to the decoupling from the container, you can actually test the things without having to dummy up a container first (remember cactus?). This simplifies things no end. Also Spring and Hibernate configuration, although still XML proved a lot simpler and easier then EJB 1/2 descriptors and App Server configuration.
If you want a true component model, then try a late-bound language like Ruby.
Paul.

Cameron,
Firstly, I don't see why you felt the need to synchronize transferTo() when withdraw() and deposit() are both sycnhronized? The deadlock is introduced by the transferTo() method due to unnecessary locking. This could have been avoided by following one of the most basic rules of avoiding deadlocks (avoid nested locking i.e. release a lock before acquiring another one as much as you can and be aware of the ordering - Taylor's code follows these rules). Anyways, maybe it was an honest mistake or maybe it was intentional and necessary to introduce a deadlock to prove a point.
Secondly, IMHO, I don't think anyone's intention here is to post real world production ready code, but to simply pose an argument with a suitable example. E.g. Taylor's example can go into an intermittent wait but he was making a different argument (breaking object identity (==) means you are no longer synchronizing on the same object even if .equals() returns true), so it is OK. The choice of the example can be questioned, but that is besides the point.

if (withdraw(amt))
{
// this MUST NOT fail or we lose the money!!!
acctTo.deposit(amt);
return true;
}

I guess if customers build apps similar to your example, they WOULD lose a lot of money (if acctTo happens to be null).
I personally feel that it is ignorant and egotistical to presume that multi-threaded programming is hard for most engineers and it is just a FUD created by vendors to get engineers to depend on their bloated "transactional systems".
Kunal Bhasin,
Terracotta, Inc.

I personally feel that it is ignorant and egotistical to presume that multi-threaded programming is hard for most engineers and it is just a FUD created by vendors to get engineers to depend on their bloated "transactional systems".

Exactly. I am sure Cameron understands that the community sees that he will be the LAST person to accept Terracotta's approach.
I did want to point out something value-added here though. A few on this thread couldn't quite tell in my original blog that the discussion about == and .equals() was a quote from a friend. I said it, but my MovableType template leaves a bit to be desired in terms of formatting. Sorry about that. The focus of the blog wasn't on object identity but the freedom it enables. The freedom every non-clustering-vendor user on this thread demanded. Something akin to "don't tell me how to write my app!"
The key take away from this thread is not whether one vendor believes in a competitor's approach or not, but that everyone agrees POJO or whatever we call it--the revolution in Java programming is "F* the vendor." I want to write the way I want to write and I want my code well factored and extensible over time and marrying myself to one framework is not always going to get me that.
That's why Spring is so well adopted. Yes, it does unique and kewl things with applications and some of those require interfaces and the like, but it makes code many people are happy with at the end of the day. People here who want to stop having vendors ruling on their code from above should take a look at Terracotta. It really helps simplify enterprise programming.
And, no, it doesn't suffer from the pratfals Cameron is trying to claim. Java is Java and, as Kunal accurately points out, Cameron is trying to convince everyone that Java is TOO HARD and that transactions and O/R-mapping are easier. They are POWERFUL and TOTALLY VALID abstractions, but "easier"? Please.

Firstly, I don't see why you felt the need to synchronize transferTo() when withdraw() and deposit() are both sycnhronized? The deadlock is introduced by the transferTo() method due to unnecessary locking.

The example of a money transfer from one account to another is very popular in computer science precisely because of the set of requirements that it implies.
I had assumed that you would believe it to be "unnecessary", since it is something that Terracotta simply cannot handle.
Peace,
Cameron Purdy
Oracle Coherence: The Java Data Grid

The example of a money transfer from one account to another is very popular in computer science precisely because of the set of requirements that it implies.

And your point is?

I had assumed that you would believe it to be "unnecessary", since it is something that Terracotta simply cannot handle.

Again, if you cared to pay enough attention, the discussion about the "popular computer science" example had nothing to do with Terracotta. But again, your attempt to get the last word in by posting to threads that are month(s) out of date is patently obvious.
The flaw I pointed out in your code is a direct result of some poor programming practices (unnecessary locking, not checking for null etc.). Please care to throw some more light on how this would be any different in a multi-threaded context within a standalone single JVM instance with no clustering (or Terracotta) involved.
The reason I ask is that Terracotta does not change the semantics under which the JVM operates, it extends the existing semantics to a distributed context. Therein lies the simplicity and the power of the technology.
In other words, your example has a bug and will fail whether you use Terracotta or not.
Anyways, the comment makes it glaringly obvious that the poster does not have enough knowledge about Terracotta to make judgment calls on it. It looks more like a vendor potshot.
Regards,
Kunal Bhasin
Terracotta, Inc.

The flaw I pointed out in your code is a direct result of some poor programming practices (unnecessary locking, not checking for null etc.). Please care to throw some more light on how this would be any different in a multi-threaded context within a standalone single JVM instance with no clustering (or Terracotta) involved.

The least common denominator is that a POJO is an object not derived from a framework class. Especially, POJO is an anti-thesis to Entity Bean. See also the mentioned Wikipedia article (http://en.wikipedia.org/wiki/POJO). In many cases POJO is used synonymous with JavaBean. There will hardly be a consensus beyond that.

A POJO is something is something that you can instantiate out of the blue:
public static void main(..) {
Pojo p = new Pojo();
}
As I remeber it, the whole POJO movement grew from a frustration with EJB, where you need to start a big container with a context, where you deploy some an EAR wrapping a WAR which contains a few JARs, and you lookup and narrow and end up with some sort of remote interface and bla bla bla just to get a friggin' object.

As I remeber it, the whole POJO movement grew from a frustration with EJB, where you need to start a big container with a context, where you deploy some an EAR wrapping a WAR which contains a few JARs, and you lookup and narrow and end up with some sort of remote interface and bla bla bla just to get a friggin' object.

Not necessarily frustration with containers (you _always_ need a container in serverside Java) and not EJBs in general but Entity Beans.

Hi All,
My understanding of POJO is that it was a term used to describe a component model which contrasted significantly with EJB's.
So to me the question is what is a component? Well my understanding is that a component is an abstraction that can be re-used because it has few if any hardwired dependencies on it's context. This is not the case with an EJB2.X component, which could hardly be tested outside the context of a container, never mind re-used without a complaint container. It is the case with a Spring Bean however, which can be used with or without Spring.
In true OO, all objects are components by default and have no hard dependencies on anything including their own class. They achieve this through encapsulation and message passing.
So a POJO is a Java component which does not depend (can have an independent life) on it's container (context). A pure Object takes this concept even further and is an object that is not hardwired to anything at all including it's own implementation (e.g. Class) and can be re-used and extended at will after compile time (e.g. using mixins, slots, open objects, open classes, etc).
So pure Objects are true components and are much more reusable, which IMO is what the component idea is meant to be all about. POJOs are a half way house, but an improvement on EJB2.X.
Just my 2 cents :^)
Paul.

The term "POJO" was coined by Fowler and a couple of other individuals to mean a "regular" Java object, as opposed to a "fancy" object like an Entity Bean. That's it. That's all there is to it.
Now, if you feel like that definition is too vague for you, why don't you come up with your own term ?
Here's one suggestion: a PAJO (Plain Ari Java Object). See if you can get that one to gain widespread acceptance. Good luck.
:-)

The term appeared after the "Bean" term had been sullied with association with J2EE so that when people heard "bean" they thought of enterprise beans instead of objects conforming to the JavaBean specification.
As for Comparable, it is there for objects that have a natural ordering. If you need more than one ordering use one or more Comparators, as others have stated.
(What is wrong is String.compareTo() since you often will want to use a Collator instead.)
And equals() being the same as == would make it worthless: If I get a String over the wire it will be a different object than an interned String constant that I might want to compare it to. Does the blogger's code only relate to data that only lives in one VM?

Hello,
thank you for this very interesting article. I want to point out to you that there is a O/R mapping tool which passes the constraint that you impose
"In order to Be has POJO, has class must strict support object identity by operating directly one heap, cannot operate one system resources, and cannot exposes system concerns."
It acts of Oracle TopLink because all read operations use the same object instance contrary to hibernate.
Could you add TopLink in your comparative table?
In addition, i find damage that this advantage of Toplink is ignored so much so that much people end up thinking that the principles of "Identity Fields" used by Hibernate, Open JPA and the others are impossible to circumvent and that have is obliged to waste memory by making systematic copies of the objects !
Thank you still
T.albi

If you really want a framework to provide strict object equality even after network communication, it is possible to use serialization API and the "readResolve" method.
The idea is to replace the deserialized object from a stream by the original object reference in the local JVM stored in a bean repository. For more information, look at java.io.Serializable javadoc.
So, your "equals" is used to get the right reference and it results into a "==".
That is really useful for enumeration or singleton accross multiple JVM in case of clusterization... But I'm not convinced that POJO must always be singleton.
By the way, Spring and any O/R mapper may easily implement equality that way if there is any gain to expect: you avoid many copies of the same object in memory but you still temporary consume memory at deserialization.
Other advantage: if you also replace "writeReplace" you may only transfer on the network the database identifier of an non-modified object between JVMs and let your O/R mapper resolves it from its cache or from database. It depends if your database is faster than your network ;)
Take care: such a mechanism requires a large set of existing beans in your framework to resolve potentially duplicated objects... so it is a good idea to use week references to let gc does its job.

Here some of my personal views:
There are a lot of different viewpoints in this discussion about what is and is not a POJO, but one characteristic that everyone seems to agree upon is SIMPLICITY. The problem is that simplicity is subjective. Simple for one person may not be so simple for another. So, the overwhelming question that I still see here is "If my POJO is simple enough for me, how does it matter if it maintains referential integrity or object identity (==) or anything else"?
So let me give an example. In a single JVM, what would be your preferred way of achieving communication between threads?
1. Use the existing very simple yet efficient thread communication and concurrency semantics provided by the Java runtime (synchronized, thread safe collections like Hashtable and Vector, java.util.concurrent library).
2. Build a messaging interface to enable thread communication (synonymous to messaging across JVMs a la JMS, RMI etc.).
Now, if you fall in the former category (like me), it does matter that your POJOs don't break object identity. E.g., I may choose to use a Hashtable (which is thread-safe meaning changes made by one thread are isolated and made visible to other threads interested). Now, if a framework breaks this referential integrity and forces me to work on a proxy or a clone, I am being forced to sacrifice on the simplicity and also efficiency that JVM provides. Simplicity because I can no longer get references and make changes and expect other threads to get these changes - the JVM does not guarantee that changes made by one thread will be made visible to another thread unless both threads are working on the same object - here "same" means == should be true. I have to call some external framework specific APIs to ensure that all interested parties see the changes and there is all the associated plumbing logic getting meshed up with my application. Efficiency because the framework is now adding bloat to my simple business objects and it cannot do byte level optimizations that the JVM provides - it has to send entire objects/graphs as against a few bytes when some object is mutated.
If we extend the above argument in a multiple JVM context, Terracotta maintains object identity (==) across multiple JVMs which means it is truly clustering (not just distributing) your POJO and all consumers of the POJO across JVMs feel like they are working on the same object - all JVM semantics including thread coordination are maintained.
Hence Terracotta clusters the JVM state without sacrificing on simplicity (no new APIs) or efficiency (by sending only field level changes and not entire objects on object mutations and only sending these changes to ONLY those nodes where the same object is being referenced - since object identity is not broken).
Anything a POJO can do in a single JVM, Terracotta+POJO can do in multiple JVMs.
The single key take-away that I got from Ari's blog was SIMPLICITY. What is simple for you is for you to decide.
Cheers,
Kunal Bhasin,
Terracotta, Inc.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.