A couple of weeks ago I wrote a short note mentioning you can use CDI and JSF in Liferay portlets at last.
The good news
And it’s true! It’s hard to believe for someone like me who has been waiting two years for it. But every CDI core feature my team and I tried works flawlessly in the Liferay portal server. Continue reading
Today I’ve been debugging a method that uses an aspect woven around it. AspectJ confused me a lot: it made me believe the aspect wasn’t woven around the method at all. But it was woven indeed, as I realized a couple of hours later. Let’s look at the caveat, and why it exists.
A couple of posts ago I mentioned the incompatibility between Lombok and the AspectJ Eclipse plugin. Of course, JUnit tests also suffer from the incompatibility. Today I’ve been looking for a solution to that problem.
Many people claim AspectJ is slow, and rumors have it that this is caused by AspectJ copying the aspects code into every method that uses the aspect. Eclipse’s debugger also behaved strangely at my office PC, indicating that this theory might be true. Theese days I had a closer look at the byte code to verify or falsify this.
Both lombok and AspectJ can simplify your java code by removing or reducing mindless code repetitions. The first one allows you to get rid of most of the getters and setters (and other methods), whereas the latter makes it easier to include cross cutting concerns to your code.
Unfortunately, the corresponding Eclipse plugins are incompatible.
Theese days I’ve been asked about my experiences with AspectJ. What about your application’s performance, they asked me. Isn’t it bogged down by AspectJ?