tag:blogger.com,1999:blog-18834385.post5587545153850381045..comments2022-12-05T06:43:29.943-05:00Comments on The Programming Delusion: An AJO is not a POJOBJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-18834385.post-27865431463082722212008-08-28T21:40:00.000-04:002008-08-28T21:40:00.000-04:00I would disagree. It is still a POJO. The annota...I would disagree. It is still a POJO. The annotation doesnt make the POJO dependant on the framework. The annotation merely lets external consumers of the POJO know how to apply extra features, which are irrelevant to the POJO within its Object boundary (the specific business logic it provides), albeit not necessarily irrelevant to its interaction with other POJOs in the same system.Steven Pehhttps://www.blogger.com/profile/01554995090079123022noreply@blogger.comtag:blogger.com,1999:blog-18834385.post-84144228281790512582008-05-07T23:44:00.000-04:002008-05-07T23:44:00.000-04:00Totally agree.Java standard annotations or impleme...Totally agree.<BR/><BR/>Java standard annotations or implementing Serializable (which is basically part of the language) don't affect the plainness of a Java class.<BR/><BR/>Hoever, 3rd party annotations are just a veiled form of dependency. It is easier on the eye, and they can even be ignored/ineffective during runtime, but they are still intrusive.Rafael Chaveshttps://www.blogger.com/profile/07323946296491587467noreply@blogger.comtag:blogger.com,1999:blog-18834385.post-45472221470557237482008-05-07T16:12:00.000-04:002008-05-07T16:12:00.000-04:00I agree BJ, you tell 'em.I agree BJ, you tell 'em.Chris Aniszczyk (zx)https://www.blogger.com/profile/14067673601779593093noreply@blogger.comtag:blogger.com,1999:blog-18834385.post-7463377659331021292008-05-07T09:50:00.000-04:002008-05-07T09:50:00.000-04:00@ed merks: Using @Override, which is part of the s...@ed merks: Using @Override, which is part of the standard Java now, does not alter the plainness of the Java object. But when you use annotations which are specific to particular framework infrastructure, for example @EJB, your source is no longer plain. The infrastructure details begin to litter your source code. As John Hurst said in a <A HREF="http://www.theserverside.com/news/thread.tss?thread_id=44593#229172" REL="nofollow">TSS thread</A>: "A class full of 3rd party annotations isn't a POJO any more -- it has dependencies on 3rd party framework code." This is my point exactly.BJ Hargravehttps://www.blogger.com/profile/02289107040084648957noreply@blogger.comtag:blogger.com,1999:blog-18834385.post-34500386216300922702008-05-07T05:49:00.000-04:002008-05-07T05:49:00.000-04:00hey, let's not get too postmodern about the defini...hey, let's not get too postmodern about the definition of POJO, shall we? :) <BR/><BR/>conceptually, an annotated pojo is a pojo with touches of aspects that hint managed environments as to how to treat the object. the separation between java se and java ee runtimes shouldn't apply for annotation jars, I think, although that's a whole different issue. anyway, one of the deeper meanings of POJOs to the world of JEE is that the distinction between client and server runtimes is made fluid, much thanks to OSGi. Extensible POJOs is more like it, in my view. how about EOJOs?צְבִיקַ'הhttps://www.blogger.com/profile/06574092551885873890noreply@blogger.comtag:blogger.com,1999:blog-18834385.post-83406506970658890822008-05-07T04:59:00.000-04:002008-05-07T04:59:00.000-04:00I've always wondered if there is a clear cut defin...I've always wondered if there is a clear cut definition of what makes any old Java object (AOJO) stop being plain and old? I.e., where is the AOJO/POJO boarder? You're suggesting that as soon as an annotation appears, the plainness disappears. But clearly an @Override won't be a concern, so even here the dividing line seems less that clearly spelled out.<BR/><BR/>Another example to consider is java.io.Serializable support. If my framework requires all objects to support that API, does my framework support POJOs? I would think not. In any case, it certainly doesn't support AOJOs, so one might argue that an AOJO that's Serializable isn't a POJO. But that seems kind of illogical as well.<BR/><BR/>It seems to me that POJOness might well be a thing like beauty: a fleeting ill-defined thing that exists primarily in the beholder's eye...Ed Merkshttps://www.blogger.com/profile/08767888750692843294noreply@blogger.com