About lock-in

[raul.arabaolaza]

Hi,

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 (http://blog.springsource.com/2009/06/18/roo-part-3/) 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.

Conclusion

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

[jtan]

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.

[raul.arabaolaza]

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

[jtan]

Raul,

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.

HTH

[Ben Alex]

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

[raul.arabaolaza]

@jtan:

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