Talk:Plain old Java object

Untitled

My opinion is that any general restriction or requirement other than those forced by the Java Language Specification on the java objects to be used in a program makes those objects not POJOs and those programming environments not strictly POJO compliant. In the case of annotations, requiring the existence of certain annotations is a restriction much like requiring the existence of certain methods. In addition, it also rules out the use of older versions of the JVM, including 1.4, which is still widely used in enterprise environments. —Preceding unsigned comment added by 124.87.141.114 (talk • contribs)

---

I guess we can debate the meaning of 'restriction'. At the very least, however, we should make it clear that the restriction placed by annotations is different from that placed by interfaces and base classes. While it may be (to quote you) 'much like requiring existence of certain methods', it is not the same.

The crucial difference is that annotations place no runtime dependencies: if they did, annotated POJOs would be no more lightweight than implementing marker interfaces.

Please redo my change and/or update it to your liking to emphasise this distinction.

Kennardconsulting 01:50, 21 August 2007 (UTC)

AfD discussion

Wikipedia:Articles for deletion/Plain Old Java Object  (aeropagitica)  (talk)  22:50, 21 April 2006 (UTC)

Please denote vernacular usage

This nomencalture is not part of a standard or specification. Please denote in the body of the article that such nomenclature should not be used in general and certainly not used in technical tests. (Common guys, you are going to crash planes with this stuff.) —Preceding unsigned comment added by 75.25.4.73 (talk • contribs)

Notability missing

Where is notability demonstrated for this subject?-- Mumia-w-18 20:21, 1 November 2007 (UTC)

A search on Google for "Plain Old Java Object" (in quotes - that exact phrase) gave 41,400 hits; the same search on Google Scholar gave 146 hits. I think that the latter at least constitutes 'presumed notability'?-- Richard Pawson —Preceding unsigned comment added by Rpawson (talk • contribs) 09:14, 2 November 2007 (UTC)

EJB3 is not POJO

I do not understand how anyone can say this.

-> I need the javax.persistence imports to compile -> The EJB3 annotations have runtime retention policy

EJB3 IS INVASIVE, not a DI POJO component model. If you can live with this go ahead, but don't tell its POJO. It does not even have dependency injection, it is a dependency lookup through annotations.

[1]

[2] —Preceding unsigned comment added by 89.244.186.7 (talk) 10:25, 20 November 2007 (UTC)

What?

"All Java objects are POJOs, therefore ideally speaking a POJO is a Java object ..."

What does this mean? Does POJO mean the same as 'java object' or not? I assume they do mean something different which means that not all java objects are POJOs. —Preceding unsigned comment added by 75.73.19.85 (talk) 16:49, 4 December 2008 (UTC)

Well, unless not all POJOS are java objects, but that doesn't make sense. —Preceding unsigned comment added by 75.73.19.85 (talk • contribs)

Special Object

The second sentence adds little to explanation of POJO. Merely saying that is it not a special object while not explaining what a special object or what it lacks that doesn't make it special doesn't clarify much to the reader:

"The name is used to emphasize that the object in question is an ordinary Java Object, not a special object, and in particular not an Enterprise JavaBean (especially before EJB 3)"

—Preceding unsigned comment added by 207.171.180.101 (talk • contribs)

Also you could call Special Objects "SPEJO", instead of SoJO, where the oh seems to come from nowhere, but whatever; this just crossed my mind and probably nobody uses SPEJO anyways.

Pupitetris (talk) 19:51, 15 July 2015 (UTC)

JavaBeans are not POJO. "Contextual variations" chapter misleading?

I have objections as to JavaBeans being listed as a "variation" of a POJO object. The definition in the first section says The term "POJO" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks. By that definition, a JavaBean is not a POJO object (or a variation of it), since it introduces coding convention. I suggest the entire chapter is removed as it only causes confusion. — Preceding unsigned comment added by Nilzor (talk • contribs) 10:29, 15 May 2013 (UTC)

Transparently adding services

The title is not clear. What does it mean: "the services that are adding transparently", "the transparent process of adding services", or something else?

Definition

The Definition section outlines 3 things a POJO should not do:

1. Extend prespecified classes.
2. Implement prespecified interfaces.
3. Contain prespecified annotations.

What is the source for these requirements? Also, in what sense is "prespecified" being used? What makes an annotation prespecified as such - does it mean a requirement imposed by an external framework? jon (talk) 20:57, 20 December 2015 (UTC)