Announcement Announcement Module
Collapse
No announcement yet.
Is Annotated POJO a POJO ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is Annotated POJO a POJO ?

    This is a topic which has been discussed extensively in Guice forums recently. Since Guice makes use of @Inject annotations for DI, many users complain that using annotations that do not belong to native JDK takes the POJOness out of the POJO. Adrian Coyler, once mentioned in his blog that

    If you're writing say a retail application, and your POJO uses some retail annotations from your business domain, then that's still a POJO in my book. But if your retail application uses annotations specific to say the MegaServ application server, then that's not a POJO anymore (even if those annotations would be 'harmless' outside of the MegaServ environment). For one thing, it won't compile without the MegaServ libraries around. The compiler is a pretty good test of coupling.
    I would like to know what is the opinion of the Spring community on this topic. In the context of the survey thread regarding demarcation of Transaction limits in Spring, many people have opined against using @Transactional since the annotation makes the code dependent on Spring. While this is true, but does the usage of @Transactional make it a non-POJO ?

    Would love to hear what the community has to say ..

    Cheers.
    - Debasish

  • #2
    That is really a good question. I think I agree with what Adrian wrote and like to remark that I consider a POJO using annotations provided by Java itself also as a POJO. At least when it is about Java SE annotations.

    Regards,
    Andreas

    Comment


    • #3
      Hmmm interesting. So if you have any imports that are outside the project and non-java, you aren't dealing with a POJO?
      Last edited by karldmoore; Aug 29th, 2007, 11:38 AM.

      Comment


      • #4
        Does that make a POJO with @Transactional or @Inject a non-POJO ?

        Comment


        • #5
          Originally posted by debasishg View Post
          Does that make a POJO with @Transactional or @Inject a non-POJO ?
          According to Adrian's article and a few other things I've just had a look at then yes, it wouldn't be a POJO.
          http://en.wikipedia.org/wiki/POJO
          Last edited by karldmoore; Aug 29th, 2007, 11:38 AM.

          Comment


          • #6
            Originally posted by karldmoore View Post
            Hmmm interesting. So if you have any imports that are outside the project and non-java, you aren't dealing with a POJO?
            Well, at least it isn't that plain old anymore . Strictly speaking it wouldn't be a POJO anymore (in my opinion).

            Comment


            • #7
              I have to confess, I've never really thought about this before. The idea of dependencies in the code is unappealing at best generally. As such I try and avoid if it all possible, I guess most of the objects there are therefore POJOs anyway.
              Last edited by karldmoore; Aug 29th, 2007, 11:37 AM.

              Comment


              • #8
                Originally posted by Andreas Senft View Post
                That is really a good question. I think I agree with what Adrian wrote and like to remark that I consider a POJO using annotations provided by Java itself also as a POJO. At least when it is about Java SE annotations.
                +1.

                Maybe something Java 7 (or 8 if too late in the game for 7?) could do (instead of pouring all the syntactic sugar ) is to change the way annotations are handled - to something similar to XML namespace handlers, i.e., not requiring an explicit import.

                If that's not possible, I say at least standardize the most-used annotations - like @Transactional, @Required, etc.

                Comment


                • #9
                  I wouldn't consider a domain object using @Inject a POJO... It has to be "plain"...

                  Comment


                  • #10
                    Well a EJB2 bean is just a POJO that extends some stuff

                    Personally I think the question is just an academic knee-jerk reaction (although an interesting question). In practice very few classes (mostly VOs?) have no dependencies outside the java class libraries and other business classes.

                    OTOH, I don't see why POJOs couldn't have annotations. I prefer to see all class-related configurations in context than having to wade through 4-5 different XML-files. Most (all?) annotations have their XML conterparts anyway so if I have to reuse the classes, moving out the configuration can be done with some mechanical work. A Plainish Old Java Object.

                    Sure, there will always be purists but I prefer stuff that simplifies development (as long as the lock-in can be removed in a predictable manner). Then there is the question if a POJO is a POJO if the class gets bytecode manipulated. Or does the POJO term only apply to source level?
                    Last edited by Nik; Apr 13th, 2007, 12:35 AM.

                    Comment


                    • #11
                      Originally posted by karldmoore View Post
                      I have to confess, I've never really thought about this before.
                      Me, too. Until this thread

                      Originally posted by karldmoore View Post
                      The idea of dependencies in the code is unappealing at best generally. As such I try and avoid if it all possible, I guess most of the objects there are therefore POJOs anyway.
                      +1

                      Besides that I haven't had much to do with annotations, since I had to stick with Java 1.4.x most time.

                      Comment


                      • #12
                        Looking at the resposne, I think most of the people agree to the fact that using annotations like @Transactional, @Inject etc. which do not belong to native JDK make an object a non-POJO. The immediate sideeffect that these annotations bring into the codebase are :-

                        a) Dependency on third party frameworks
                        b) Make the classes difficult to unit-test (u need these frameworks for unit testing)
                        c) The classes are Java objects but definitely NOT *plain*

                        This brings us to the next question ..

                        If we go the XML way in Spring (Guice has no other option :-( ), then do we solve any of the above problems ?

                        For (a), we move the dependency for the class to somewhere else (the XML or the Groovy script).

                        For (b), we do not actually solve the problem, since we still need Spring for unit testing (Spring needs to process the XML and build up the factory).

                        For (c), the classes become free of third party annotations - very true.

                        But overall, do we gain much as far as unit-testability (possibly the most important criterion for POJOness) is concerned ?

                        And finally, isn't XML also part of my codebase ? True they are externalized, but still we need to process them using Spring.

                        Cheers.
                        - Debasish

                        Comment


                        • #13
                          Originally posted by debasishg View Post
                          For (b), we do not actually solve the problem, since we still need Spring for unit testing (Spring needs to process the XML and build up the factory).
                          Not necessarily. One can also wire the classes under test programmatically. Actually that is what I mostly do. The point holds however for integration tests. But integration testing usually involves more infrastructure to be necessary.

                          Originally posted by debasishg View Post
                          For (c), the classes become free of third party annotations - very true.
                          Indeed.

                          Originally posted by debasishg View Post
                          But overall, do we gain much as far as unit-testability (possibly the most important criterion for POJOness) is concerned ?
                          I think a bit pragmatism is not bad. Just because strictly speaking an annotated class might not represent a POJO does not mean that we shall refrain from using it. I think using things like @Transactional has its worth. Important is just that one knows what he does and understands the implications.

                          Originally posted by debasishg View Post
                          And finally, isn't XML also part of my codebase ? True they are externalized, but still we need to process them using Spring.
                          This is true, but due to the externalization I always have the possibility to realize the wiring in another way (e.g. programmatically) without changing the codebase.

                          Regards,
                          Andreas

                          Comment


                          • #14
                            Originally posted by debasishg View Post
                            For (b), we do not actually solve the problem, since we still need Spring for unit testing (Spring needs to process the XML and build up the factory).
                            We don't use Spring in our unit tests... It's not much trouble to handwire them. And this allows another developer to clearly see the dependencies that need to be satisfied for the object to work when he/she looks at the unit test. In a sense, the unit test becomes closer to be a spec...

                            - Yagiz Erkan -
                            http://blog.decaresystems.ie

                            Comment


                            • #15
                              Ok, strictly speaking, annotated classes are not POJOs, they become PAJOs (Plain Annotated Java Objects.

                              Concerning annotation usage - there are annotations and annotations ...

                              In my opinion some annotations like @Transactional or @Required are parts of the class contract. Moreover, transactionality (against popular misbelief) is a part of the business semantic. So information that such annotation carry truly belongs to the source code and should not be externalized. It's really pitty that current realisation of annotations in Java requires insertion of direct depndency on specific implementation of these concepts. Such annotations would do better if they become part of the language itself (in form of "standard annotation" - yet not existing feature - or even as keywords).

                              Some other annotations (like @Configurable) just express somedeveloper's wishes and are not part of class contract by any means(as object has no way to know was it configured by Spring or manually) and clearly and intentionally introduce dependencies on specific technology.

                              BTW, my overall opinion about Java annotation mechanism (as it exists now) is very low. It need big, if not radical, improvments to be really usable.
                              E.g- annotations that are not inherited from interfaces - in my opinion it is complete nonsense.

                              Regards,
                              Oleksandr Alesinskyy


                              Originally posted by Andreas Senft View Post
                              ..................
                              This is true, but due to the externalization I always have the possibility to realize the wiring in another way (e.g. programmatically) without changing the codebase.

                              Comment

                              Working...
                              X