Setup Lombok with STS/Eclipse based IDE

For those of you who haven't heard about boilerplate code, you can check this link
Now that you already know what's that we found this little library

You can add it to your Maven projects easily, however adding it to your Eclipse is a challenge, especially if you are not using barebones Eclipse like me, who happens to use STS and initially it didn't work:

Why it doesn’t generate getter and setter like in the video? I already installed that thing like 3 times and nothing :(

Well, the solution for me was this:

Paste the JAR manually into MacOS folder

Add the option
-vmargs -javaagent:lombok-1.16.16.jar to the file STS.ini

Finally you NEED to close the STS/eclipse and start again. (Restart doesn’t take effect)

Once you’ve done close and start STS. You’ll see the getter and setter is autogenerated.
In case you see any compilation errors, just clean and build your project.

Voila!

How to speed up Eclipse on Mac OS X

Or Pimp my Eclipse

If you’ve been experiencing horrendous performance of Eclipse on OS X, or maybe you even did not know that Eclipse actually can run very fast, you’d be surprised to learn that apparently it is very easy to make Eclipse run 4-5 times faster on OS X with proper settings to your eclipse.ini file.

Working with Eclipse on OS X felt horrendously slow! I had already noticed this nuance in the past and I thought that the Eclipse is just not meant to fly on Mac's (oh well…), especially when there are so many different distributions for OS X, it signals that the project is in a shifting phase basically (it is shifting from Carbon to Cocoa) and that you should expect all kinds of problems.

I bet many people not having experience with Eclipse on other platforms would think this is normal. It’s Java, so it is supposed to be slow and they just go and hate it and sing how X-Code is great. The thing is, they probably never experienced the full potential of Eclipse – a pity. Hopefully this post can change your mind and help you experience the wonderful world of Eclipse (ok, I am being a little dramatic here). Ok, let’s dive into that.

Since I am pretty heavy user of Eclipse the slowness of Eclipse quickly grew on me and I started looking for ways to try and do something about it.

In the past while experiencing slowness with Eclipse on Windows, I played with the memory allocation within it to increase the memory cap and this usually helped a bit. Being desperate, I decided to try that and off I went to try that. But, that was not so easy. I wandered a bit around the eclipse folder looking for the location of the eclipse.ini but it was nowhere to be found. So I tried searching for it – nop, no luck there as well.

Apparently eclipse.ini is packaged inside the eclipse app so what you need to do is to get inside the eclipse.app package

OR you can use this command:

vi $ECLIPSE_HOME/Eclipse.app/Contents/MacOS/eclipse.ini

after that edit eclipse.ini which you will find in Contents->MacOS folder and increase the memory limits for the following directives (on my case I used these values):

--launcher.XXMaxPermSize
2048m
...
-vmargs
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Dosgi.requiredJavaVersion=1.6
-Xms512m
-Xmx850m
-XX:PermSize=512m
-XX:MaxPermSize=1024m

While this is good, this is NOT what will actually make your Eclipse fly. The most important part here is the:

-Dosgi.requiredJavaVersion=1.5

now, you have to switch that to 1.6 and make it

-Dosgi.requiredJavaVersion=1.6

Now THAT will make your Eclipse really shine! Just make sure you actually HAVE the JDK 1.6 installed. You can validate this by running “java -version” in the terminal. If you got 10.6 – Snow Leopard though, you are most likely covered.

Also I still have two more tricks that might be useful:

-Xverify:none

Which will skip the class verification stage during class loading. Using -Xverify:none disables Java class verification, which can provide a 10-15% improvement in startup time. However corrupted or invalid class data is not detected when this option is specified. If corrupt class data is loaded, the Java Virtual Machine (JVM) might behave in an unexpected manner, or the JVM might fail.

-XX:+UseParallelGC

Which is known as The parallel scavenge collector. Which is just an improved version of the parallel copying collector (Enabled using -XX:+UseParNewGC), but the algorithm is tuned for gigabyte heaps (over 10GB) on multi-CPU machines.

If you already had that in the eclipse.ini file – well, unfortunately this already has been optimized for you and the only thing you can try from there that we know of is to play with the memmory limits.

Also, I've discovered other options, which I'm not 100% sure how they work together (because I haven't researched them too deep :P), however they might help you out:

-XX:CompileThreshold=5
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=70
-XX:+UseFastAccessorMethods
-XX:+CMSIncrementalPacing
-XX:+UseG1GC
-XX:+UseFastAccessorMethods

Just don't mix them with -XX:+UseParallelGC

Debugging App Server Remotely

When I was working with an external/existing jBoss App Server Instance, I had an issue and I needed to debug something, so I had 2 options in my head:

1. Create an internal instance (managed by my IDE: Eclipse) and do all the work there, for example like in Spring Source Tool Suite aka STS (which has its own App Server Integrated) or IBM RAD (which has its own version embedded of WebSphere)
2. Put a bunch of DEBUG's on my Log4'j config and trace them through my Console

And then playing around with my IDE, I found something really cool on the Debugging perspective of my Eclipse:

Click on Debug Configurations and you'll see a window like this one (Bind this configuration to your project)

Then, go to Remote Java Application, create a new Configuration
On the Connect tab, give a name select the Standard Connction type and in the Connection Properties give the location of your server and the "debugging" port (on my case is 5005)

Why port 5005? Well, on my jBoss setup I found this option on its configuration:

JAVA_OPTS="$JAVA_OPTS -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"

By doing this, you'll enable debugging port on your JVM :D (Cool isn't it?)


On "source tab", select Add your project (the one which is running on your App Server)
And in "common tab" check the Debug option, finally, Apply and you're ready to rock!

Now, after you'd started your App Server you can debug your current (running) App in your Eclipse by clicking on Debug Icon and selecting the configuration we just created!

Good luck and have fun!