Category Archives: effectiveness

7 Tips to Speed Up Eclipse

About a month ago, I blogged about my love/hate relationship with Eclipse. I was asked by a few people to share my tips on how I was able to speed it up so here we go… As a side note, this article is not about comparing IDEs, please refrain from displaying your hate for the IDE or your preference for another…  This post is just about optimizations that help Eclipse run faster for those who use it. I’ve described each tip for Windows, Linux and MacOS users. Once you have gone through all the optimization tips, Eclipse should start within 10 seconds and run much smoother than before.

[edit]: most of those tips will speed up your Eclipse experience, not just the startup time. Classes will open faster, jumping from one definition to another will be faster. Viewing method javadocs will be faster… Unfortunately, none of that can be timed precisely so there is no specific benchmark about the actual speed gains for each tip.

Note: I assume that you already have an SSD and at least 8Gb of RAM. If not, look no further for performance boosts…

Tip 1 : Always run the latest JDK and Eclipse.

More often than not, every new JDK and Eclipse version includes fixes and optimizations from previous versions. Make sure that you are using the 64 bits version of Eclipse and of the Oracle JDK. For any web development, you will want to use Eclipse for Java EE and not Eclipse for Java.

Oracle JDK : http://www.oracle.com/technetwork/java/javase/downloads
Eclipse : https://eclipse.org/downloads/

Place Eclipse and your code on your SSD.

Time to launch Eclipse.

Tip 2 : Tune Eclipse Preferences

  • General > Startup and Shutdown : remove all plugins activated on startup
  • General > Editors > Text Editors > Spelling : Disable spell checking
  • General > Validation > Suspend all
  • Window > Customize Perspective > Remove stuff you don’t use or want (shortcut keys are your friends), same for Menu Visibility (how many times have you printed a source file…)
  • Install/Update > Automatic Updates > Uncheck “Automatically find new updates”
  • General > Appearance > Uncheck Enable Animations
  • Stay with the default theme. Unfortunately, anything else makes it really laggy and slow.

I personally turn off autosuggestions so that they don’t slow down my typing. Instead, I manually trigger the auto suggestions using Ctrl+Space when needed. This is done through:

  • Java > Editor > Content Assist > disable Enable Auto Activation. Advanced > Remove all unwanted kinds

Tip 3 : Keep your JDK on a RAM Disk

A RAM disk is a virtual disk or hard drive that is stored into the computer’s memory. It boosts the I/O performance on anything that is on it. Creating a RAM disk uses your RAM even though it just appears as a drive on the computer. Because the memory used will be reserved for the disk and become unavailable for other programs, we will only be putting the JDK on there. 300MB will be enough.

Warning: Don’t put anything permanent on the RAM Disk we will create as it will be erased/recreated at each reboot.

Step by Step for Linux users:

Everything is described here already

Step by Step for Mac Users:

The RAM Disk is created with the diskutil tool:

1. Create a new batch file, for example: ~/tools/batch/ramdisk.sh
Replace x, y, and z with the JDK version you have installed on disk:

#!/bin/bash 
diskutil erasevolume HFS+ 'JDK RAMDISK' `hdiutil attach -nomount ram://614400`
cp -r  /Library/Java/JavaVirtualMachines/jdk1.x.y_z.jdk /Volumes/JDKRAMDISK

(Note that diskutil expects the number of 512 bytes sectors to be allocated: for 300MB, 300 * 1024 ^ 2 / 512 = 614400)

2. Save your file and make it executable:

chmod 755 ~/tools/batch/ramdisk.sh

Now run ramdisk.sh to create the Ram Disk:

$ ramdisk.sh 
Started erase on disk4
Unmounting disk
Erasing
Initialized /dev/rdisk4 as a 300 MB case-insensitive HFS Plus volume
Mounting disk
Finished erase on disk4 JDKRAMDISK

You should now see in Finder the new device called JDKRAMDISK containing your JDK. You can remove the RAM Disk and free its memory by clicking on the Eject button:

Note that if you follow this tip, you will always need to have the RAM Disk in order to launch Eclipse (otherwise you will see the error “A Java Runtime … must be available in order to run Eclipse”). You can configure your system to run the ramdisk.sh script automatically upon startup using Automator or using a launchtl daemon.

Step by Step for Windows Users:

1. Download and install the utility called imdisk 

2. Create a new batch file, for example: C:/tools/batch/ramdisk.bat
Replace x, y, and z with the JDK version you have installed on disk:

@echo Placing JDK on Virtual Disk N:/
@echo off
sc config imdisk start= auto
net start imdisk
imdisk -a -t vm -s 300m -m n:
format n: /q /Y
call xcopy C:\<path_jdk>\jdk1.x.y_z N:\jdk1.x.y_z\ /S /E /Y /Q
label n: JDK RAMDISK

By running ramdisk.bat, you will have created a new disk N: labeled “JDK RAMDISK” that will contain your JDK.

3. Make sure the file is run as an Administrator. Right click on the file, go into Properties and check Run as Administrator.

Note that if you follow this tip, you will always need to have the RAM Disk in order to launch Eclipse (otherwise you will see the error “A Java Runtime … must be available in order to run Eclipse”). You can configure your system to run the ramdisk.bat script automatically by placing the script into your Startup folder.

In order for Tip 3 to work, you will need to add the -vm setting in eclipse.ini (see next section)

Tip 4 : Tweak your eclipse.ini

This is one of the most confusing areas of Eclipse optimizations. There are thousands of online articles preaching different configurations… I’ll just describe the way I tweaked my options and add more to the existing confusion 🙂

Location your eclipse.ini file:
Windows/Linux: located in $ECLIPSE_HOME
MacOS: located in $ECLIPSE_HOME/Eclipse.app/Contents/MacOS

Understanding what’s going on…

Eclipse.ini contains 2 types of properties: properties relative to the Eclipse application and properties relative to the JVM. Those options are different depending upon your version of JDK or Eclipse. Here is the most up-to-date list I was able to find online.

To understand those options require just a bit of vocabulary on Oracle’s JVM. Basically, the JVM memory is divided into multiple memory pools where objects reside with time:

  • The Eden Space (heap) provides the memory for most initial objects. The Garbage Collector passes often through this space containing objects of “young generation”. It removes any objects that hasn’t been used for a while. 
  • The Survivor Space (heap) contains the objects that have not been destroyed after 2-3 passes of the GC in the Eden Space. They are still part of the “young generation” but have moved to a much safer place where they have less chances of being destroyed: the Garbage Collector passes much less often there (it assumes from past experience that objects are used more frequently).
  • The Tenured Space (heap) contains the objects that have been in the Survivor Space for a while.
  • The Permanent Generation (non-heap) contains all the metadata about of the JVM, such as the class properties, methods, enums, etc. Because that data can be shared accross multiple JVMs, the permanent generation has read-only and read-write areas.
  • The Code Cache (non-heap) provides the memory used for compiling and storing code.

In case you are interested, Oracle wrote a great article about garbage collection tuning, detailing all those spaces and roles

The sizes for all those memory pools can be tweaked in eclipse.ini. I have 16Gb of RAM, but these settings will work fine with 8Gb of RAM. 

use the JDK stored on the RAM Disk (use the version according to what you did in Step 3):

-vm
/Volumes/JDKRAMDISK/jdk1.x.y_z.jdk/Contents/Home/
-vm
N:/jdk1.x.y_z/bin

disable bytecode verification (risky)

-Xverify:none 

This basically skips the verification of class files (described in http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.10), meaning that the JVM won’t be able to detect the authenticity of the class files you are using. This poses a security threat if the compiled files have been altered. Use at your own risk. (I use that option for hobby projects but not at work)

turn on performance compiler optimizations

-XX:+AggressiveOpts

increase permanent generation space (where new objects are allocated)

-XX:PermSize=512m
-XX:MaxPermSize=512m

increase min and max heap sizes (which includes young and tenured generations)

-Xms2048m
-Xmx2048m

increase heap size for the young generation

-Xmn512m

set stack size for each thread

-Xss2m

tweak garbage collection

-XX:+UseParallelOldGC

And finally, here are some other options that you may see online… Personally I didn’t notice much of a boost by using any of them so I’m just stating them for info. You can look at the doc reference to know what they correspond to and then play with them:

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

Finally, remove all the duplicates as well as launcher.XXMaxPermSize which is useless with the option XX:MaxPermSize.

Tip 5: Get your anti-virus outta here

If you have an anti-virus, make sure that it doesn’t interfere with your code folders. Add the JDK folder, the Eclipse folder, your .m2/jar repositories, and your code folders to the antivirus whitelist.

Tip 6: Keep SVN and GIT out of Eclipse

This is really a matter of personal preference. Some will like the Eclipse integration with the collaborative team tools. Personnally I find them slow, I’d rather have Eclipse concentrate on the dev task than try to do too many things at once… I’m also a sucker for the SVN/GIT CLIs… Anyways,  I removed the integration with Eclipse and found it much more responsive.

Tip 7: Use your keyboard

One of the perks of Eclipse is the trumendous amount of keyboard shortcuts it offers. You can remap them if you are used to other schemes. I usually remap my debugging keys for ex. so that they match the ones in VIsual Studio &  Chrome Dev Env. Take some time to learn them. The less your hands leave your keyboard, the faster your Eclipse experience will be!

I won’t go into details about which shortcuts to know but you can easily find that information online. Just thinking about it, a few must-know shortcuts come to mind:

Ctrl+Shift+R : jump to resource
Ctrl+Shift+T : jump to class
Ctrl+. : jump to next error
Ctrl+Shift+G : search for references
Ctrl+Shift+P : select matching bracket
Alt+Arrows : go forward / backwards
Ctrl+Space : autocomplete
Ctrl+Shift+F : format source
Ctrl+Shift+O : organize imports
Ctrl+D : delete line
etc.

This pretty much wraps it up! Without comparing Eclipse to any other tool out there, I find that it can be a very powerful and fast tool to write java code with.

If you have any other tips, I’d love to hear about them!

Coding Alone In The Dark

“Code Smell” is an expression given when glancing at some code and seeing right away potential issues with the way it is designed. Martin Fowler describes it as “a surface indication that usually corresponds to a deeper problem in the system”. It is often tied with the notions of pasted code, anti patterns, over complexity, etc. I personally like the image of the expression: One barely needs to look at the code to know that there might be something wrong with it. Today, there are hundreds of articles that talk about how to detect code smells. There are tools that spit out metrics letting you know what could be improved. You get the idea…

Today I want to talk about another type of code smell : code that has been entirely designed and produced by a single person, code which has never been seen or reviewed by others peers, code that has been produced in the dark is almost always a code smell. (By definition, this excludes anything that is open source). This doesn’t mean that it is bad code, but most likely that it can be improved and perfected if viewed by and discussed with others. Even though there may be some exception to the rule, I have personnally never seen this theory fail once in all my years as a software developer. If you are doing it alone, you are doing it wrong. 

When you are aware that your code will not be seen by others, it takes an extreme amount of self discipline to not take shortcuts. Documentation will be sparse, routines will not be optimized, refactoring might not be complete. You might produce code that works, but if you honestly ask yourself the question: “is there anything I would change if my code was to be open sourced to thousands of developers tomorrow?”, chances are you will come up with a bunch of TODOs.

On the other end, coding “in the light” of others only brings positive things. You will be more careful when writing for others than for yourself. You will worry more about small details, such as the way you name your variables. You will make sure that your logic and algorithm are implemented and tested correctly. Your code will be easily readable by anyone. And once your code is out in the open for others to analyze, it will only improve with time. The feedback from others will make you a more humble and a greater coder. This is, I believe, the true gold that is provided by open source development.

At most private companies, designing the code for a feature usually involves multiple people. Code reviews are done prior to features being tested. Everyone knows the ROI of taking that extra step. Yet every so often, because of time concerns, of pride, or even worse because of fear of appearing dumb, code falls through the cracks, burns bridges and ends up being shipped in your software without having been looked at.

While I’ve had many occasions to avoid putting my code in the light, I found that I never had a good, solid reason to do so. Lack of time? Fear of what other devs might say? Lazyness? Pride? I’ve personnally gone through all these feelings many times. Asking for and accepting feedback is not easy. It hurts to realize that what you found great, others found perfectible. It sucks to realize that you have to spend more time refining code you thought complete. Noone likes to be told that he is wrong. Especially not coders, where personal pride and self justification too often come in the way of building greater code.

You’re probably thinking: “well yeah, you’re just stating the obvious: code reviews improve code quality… yadi yada.” Yes, it is obvious. But it’s not a natural thing for developers to do! We coders are mostly cavemen. We like the comfort of privacy, we need to experiment and create on our own. It is not a natural thing to bring our code in the light. I have heard and seen so many times developers who were left alone to create and publish code, in the name of trust and autonomy, only to realize too late that what they had created was awkward, unstable and prone to WTF moments. Just a few weeks ago, I stumbled upon a database schema that had been created by a mercenary who had only stayed a few months at our company. It contained a bunch of 3-letter tables with each 20-30 columns that had 3-letter names… No-one had a clue of which column stored what. The developer had been left alone for 6 months because of his seniority status. He only left behind mysterious, unoptimized and non logical code. Was it his fault for not showing his code to others? The peers’ fault for not asking? When a team cannot work together to produce high-quality code, it’s more a team issue than an individual fault. Coders shouldn’t feel forced to share their code. They should do it out of desire, because they realize the outstanding positive impact that it can have on his/her own coding skills and on the code itself. 

Don’t code alone in the dark. Talk about your code, write about your code. Share it, ask your peers to look at it, to discuss it, to criticize it. Get everyone involved in the process. A junior developer will build confidence when trusted with the opportunity to criticize code produced by his older peers. He will learn from analyzing good code. A senior i’ve-seen-it-all developer has the ability to look at the problem with a renewed eye and can be a trumendous asset. When given the opportunity, take the time to review your peer’s code. Learn from it. Find what could be done better. Outline the great things that you see, discuss the issues that you find and give constructive feedbacks. 

Beautiful code never comes out of the dark, it is always refined through the fire of analysis and criticism.

[edit] : I received a lot of comments on reddit / codeproject about things which weren’t understood the way I intended them to be. I am not meaning to say that code produced by a single person is bad code or “smells”. I am using the terms “doing it wrong” because there is so much more to gain from working on code as a group of individuals than as a solo dev. I have modified the article to reflect that.

The Best IDE in the World

First of all, I apoligize for the lack of recent posts. Brushing up things for the Qualys Security Conference took all my free time away for the past 3 weeks. I really want to get back on “the one quality post per week” rhythm so expect more things coming your way in the future!

One of my most memorable experiences in software development occured to me about 8 years ago when I started working for Airbus. I was fresh out of college, all pumped up with my master’s degree in network engineering. I had been swimming in code for the past 15 years (though it was mostly self-learning and small hobby projects) and therefore thought firmly with boasting over-confidence that I was an amazing coder. The truth is… I was clueless about how to produce great, maintainable code. The main issue with someone that is overcome with pride is that it always finds itself faultless, rejecting any type of failure onto something or someone else. For me, 8 years ago, it was always Eclipse’s fault.

In an effort to trend towards open-source usage and cost reduction, Airbus had started shifting most of their software development from C++ and VB/C# to the Java world. Most of the code and testing was also slowly shifting from internal development to outsourcing. I entered Airbus in that period of transition, and downloaded Eclipse for the very first time in 2006.

As an advocate of Microsoft products, Visual Studio was to me the pinacle of the IDEs, making the transition to Eclipse incredibly painful. It was slow: autocomplete would take multiple seconds, it would often freeze… The integration with maven was never working. The layout was awkward. Spell-checking ON but line numbers OFF as defaults?! I was repulsed by it. Everything about it made me feel like it was created at the time when dinosaurs were still on the earth. I hated it with my life. In fact, I hated my job for having to use Eclipse. I was a miserable coder who knew deep inside that it was all Eclipse’s fault. I thought that things would get better with the days, but they didn’t. I kept dreaming about creating the site http://www.ihateeclipse.com/ three years before it was even born.

Two weeks had passed, and then came along Ludo, a whiz kid about 5 years older than me down the hall from me. He had heard me curse at the IDE and asked if he could help. I replied with assurance: “Pff there’s nothing anyone can do about it, it’s just Eclipse who’s being a piece of *junk* once again. I’ll fix it.”. He then asked: “What do you mean once again?” after which I started a 10 minutes whining about how awful Eclipse was and how slow it made me as a coder. I was trying to fix a bug and Eclipse was just throwing random errors.

He listened carefully and then asked if he could take a look at the issue at hand. He picked up a chair and I gave him my mouse and keyboard. Ludo then started typing extremely fast, opening up the preferences, changing a bunch of options, tweaking memory usage, server settings, etc. His hands never left the keyboard. All of a sudden everything on my computer, Eclipse included, seemed so fluid, so fast and so responsive. For each specific action, Ludo knew the exact procedure, the right shortcut. The dialogs would open up and close within seconds. Within a few minutes, he had identified the issue, fixed it, tested it and commited the fix. Before leaving, he said: “Eclipse is just another tool. They are only as sharp as you decide them to be.”

I was blown away and became transformed by that experience. Back with my keyboard and mouse, Eclipse seemed slow again, but now I knew that if I learned how to use the tool well, it could be extremely powerful and fast. And not just Eclipse, but every other tool as well! My OS, my text editor, my browser… Everytime I went back to Ludo’s desk, he was only working through emacs and a linux terminal, something I had never thought possible before. But he had mastered those 2 tools to perfection and was faster at producing efficient code using them than with any other tool.

With the years, I have come to master a small number of tools. For example I know all the shortcuts in Photoshop, I am fluent in Visual Studio, I never use the mouse in Eclipse, I use my own Sublime Text plugins and hand-made extensions in Chrome’s dev console. Just like learning to play an instrument, mastering any tool is hard and requires dedication and a lot of time. I have tweaked Eclipse and Visual Studio in so many ways that not a lot of people can use my instances without feeling that they are a bit awkward. I have modified/treasured the tools in a way that they have become a part of me as a coder. I improved my typing so that I could be fully efficient in both french and english using any type of keyboard layout. And with the years, I have come to the conclusion that one of the best ways to become a better coder is to learn to master the tools that you use. And this is not a learn-everything-in-24-hours type of thing.

Even today we still see a lot of open debates about Eclipse vs Netbeans vs IntelliJ, about .net vs java, about rails vs django vs laravel, the eternal conflict of PC vs Mac, etc. And seeing a title like “the best [insert any word here] in the world” is enough to bring people to frenetic behaviour. To those who seek which tool is better, I want to quote again from the amazing and inspirational coder I met at Airbus 8 years ago: “Tools are only as sharp as you decide them to be”. Now pick an IDE, a browser, an editor that you feel good with, and go master it. Make it your own. Make it the best tool in the world.