Announcement Announcement Module
No announcement yet.
About lock-in Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • About lock-in


    For what I read in the forums it seems that many people are afraid of using Roo due to vendor lock in. The use of AspectJ and ITDs and the Roo* annotations are the most controversial points. More and more people asks about how to push in and getting free of the ITDs and annotations.

    First time I use Roo I was afraid too, I work in a very rigid enviroment I canīt deploy any piece of software with any library not previously aproved by the IT team (ok, iīm part of the IT team, but triying to convince IT people about technollogys is like triying to make a father say his daugther is not the most beatifull girl in the world (mine is ).

    But most of this concerns are not concerns at all, Ben and Stefan have been very busy explaining how easy is to get rid of Roo in your project, and Benīs posts about Roo explain very well Rooīs motivations and internals, but maybe there are in a dificult place to find for new Rooīs users, I will try to explain why the vendor lock in is not really a problem when using Roo.

    DISCLAIMER:All that I say here is only my opinion and you are free to disagree, also Iīm not part of SpringSource or Rooīs team, so I may be wrong. Ben, Stefan, please feel free to edit/remove this post any way you want.

    Now that all legal issues have been adressed letīs begin with the lock in issue...

    Use of ITDs makes my application AspectJ dependant

    Ok, ok, so most of Rooīs generated code is on ITDs, ITDs need AspectJ... So my application will need AspectJ?.

    Thatīs false, AspectJ need ends when you compile your application, you can think on Rooīs ITDs like java code in a separate file, Aspects are used only to introduce that java code into your application, but your application WILL NOT use any aspect (unless you want it) so your application WILL NOT need aspectJ in any diferent way a usual Spring application will need it for using Spring Roo.

    Think in the ITDs as a tool, the same as Eclipse, you can develop with Eclipse and generate code with it, but the generated application will be completely eclipse-free, the same thing happends when you use ITDs to generate code.

    Rooīs projects handle ITDs transparently, so users donīt need to know anything about weaving, the generated mavenīs pom for the project uses AspectJ compiler to weave ITD, you can be ignorant of all aspectj related stuff and use Roo at full power, the same way you can ignore how eclipse makes all that funny refactors it have but use it all the day. You need AspectJ in your compile time classpath, thatīs true, but you will not need it once you have compiled your application.

    The only real problem with ITDs are that some IDEs donīt have a decent AspectJ support, and itīs possible that things like code completion could not work. In a world full of Free IDEs I donīt see it like a very big problem, moreover Rooīs projects are Maven (ant planned too) based, so you should be able to use it on any IDE. Personally I use STS, Netbeans, and Eclipse depending on the project without many problems, I donīt believe in the "One IDE to Rule them All" mantra.

    Use of annotations

    Ok, ok, so I donīt need AspectJ, but my classes have things like @RooToString, moreover I have some nasty org.springframework.roo... imports in my classes, and a roo annotations jar file on my classpath. What about this, eh??

    Annotations could create dependencies, thatīs true, JPA for example makes your entities JPA dependant, but unlike JPA, Rooīs annotations have a SOURCE retention policy so there are not in the generated .class file.
    That means, I can use any Roo annotation I want, but my compiled classes WILL NOT have any Roo annotation so I donīt need any roo annotaions jar in my appīs classpath. So my app donīt depends on Roo.


    When I use Roo to generate any kind of application I will have a generated application WITHOUT ANY ROO DEPENDENCY, I will have dependencies at compile time, that is I will need Roo to generate the distributable format of a Rooīs application, but this is not a dependency or a lock in risk, itīs simple what happends when you use a tool, if I want to use a hammer I will need a hammer, so if I use Roo to generate an application I will need Roo at build time only.

    I know many people are not comfortable with AspectJ, donīt be afraid of it, Rooīs ITD are simply java code in a separate file, that code will be in your java file and you will not need to configure anything to make it happend

    The need to get Rid of Roo appears only when you need to change your toolset for example if you want to bootstrap a project and after that use something like EMACS, in that case you could have a problem with Rooīs ITDs and annotations, and in that situations is where it makes sense to use Push in refactor and say "goodbye Roo". But thatīs true for mostly everything in java: i.e maven, eclipse, ant, jpa... with the diference that other technollogys donīt usually give you something like push in refactor

    HTH, Raúl
    Last edited by raul.arabaolaza; Sep 30th, 2009, 05:35 AM. Reason: wrong formatting

  • #2
    In our situation, the vendor lock in is not the issue. We have a good architecture to ensure that it is "plug and play", "swapping" to a better tools whenever they become available.

    Our main issue is not all developers know AspectJ. I have to admit that I have been using AspectJ for a while now and never have any issue with it. I like it a lot and just wish I know everything about AspectJ. The learning curve is a bit steep compared to Java, just my subjective opinion. My previous team, I have only one developer that knows AspectJ and we didn't have a full support from the top management for AOP not to mention AspectJ. So it is kind of difficult to develop in environments that do not support AOP or have the same level of appreciation about AspectJ in this respect.

    The "push in" feature is cool, I have not seen any tool that has this capability yet.
    Last edited by jtan; Sep 30th, 2009, 08:34 AM.


    • #3
      Hi Jtan,

      I think the problem is that people thinks that to use Roo you have to use or know about AspectJ, my point in the previous post is that using Roo donīt mean you need to use or know about AspectJ.

      I agree you can have problems with your partners or your boss, but in my opnion itīs matter of show them that actually you are NOT using AspectJ, Roo is using it for you.

      I think the best aproach is not saying, "hey Roo uses aspectj but you can get free of it" but "hey try it, donīt worry whatīs under the covers before trying it"

      Do you really think you need to know AspectJ to use Roo? Iīm very used to it so maybe my opinion is biased.

      Regards, Raúl


      • #4

        I think everyone who read this thread deserved an explanation here, thanks for pointing it out. I wrote "learning curve", I meant the appreciation of the technologies behind it not the barrier to be able to use Roo without knowing AspectJ, I agree with you on that. Assume this scenario, if one does not know AspectJ itself or even AOP, the person might wonder what is the *.aj files and what is weaving etc.. Most likely the person will try to hit F3 (say in Eclipse) to look for the Java class but ended up in AspectJ class, right?

        It is the comfort level of working on something that he/she is not familiar with and knowing that there might be a possibility that a deeper troubleshooting might be needed towards Aspects artifacts that I am talking about, not the ability to use Roo without knowing AspectJ.



        • #5
          Thanks for posting this thread, Raúl. It's great to see people value the "no lock in" priority that underpins the Roo philosophy.


          • #6

            I see your point, but personally disagree, let me explain myself. In my opinion Rooīs generated code, that is the code on the ITD, is like any other framework code, you expect it to work and you usually know what it does and what is supposed to do by documentation not by inspecting it. For example when I have problems using Hibernate 100% of time the problem is related to my code not Hibernate code, I need to understand at some degree whatīs Hibernate doing under the covers, thats true, but I donīt need to review Hibernateīs code on my daily work. In my opinion, when one needs (or can manage) such level of detail there should be no problem inspecting .aj files, that files are very very similar to java code, so there should be no problem.

            Take for example Spring AOP and declarative Transacction support, users canīt inspect the generated proxies code but they can use it very easily, of course they need a high level of understanding of whatīs happening, but they donīt need to understand or review the code.

            ITDs are not so diferent that proxies, your classes have some "magic functionality", but you can safely assume that this functionality works.

            However I agree that some tool improvements could make use of ITDs easier and more comfortable, your example in Eclipse is indeed a very good example, but this a tooling support debate on which I suspect we agree, not a debate about ITDs themselves. Think in Maven for example, itīs a decent build system, but for many years was a pain to use it with eclipse or Netbeans, but it wasnīt Mavenīs fault.

            I would love to ear your experience with Roo and ITDs on your team, being a IT guy in my company means that you have much more time to learn new things than your buddys and so your are not in the companyīs "real world".

            @Ben: My pleasure, I think that Rooīs getting to much attention on the blogosphere about the use of ITDs without really knowing what that really means. May I suggest to create a Misconceptions page on the upcoming reference documentation or projectīs web page??

            Regards, Raúl