Talk:Plain old Java object/Archives/2013

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)

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)