IntelliJ & Eclipse Dependency Sync plugin

Some time ago I wrote a plugin for IntelliJ developers who work in Eclipse environment.

This plugin synchronizes content of eclipse .classpath file with IntelliJ libraries. It is quite helpful when your colleagues add/remove some new libraries to the project in Eclipse and you suddenly can not build it.

Unexpectedly in few months plugin has been downloaded over 750 times! Some people even requested new features.

Project Facilities

As project was lacking some structure – documentation, discussion forum, source repository I decided to use Google Code and Google Groups to provide all these facilities.

So the mailing group is here and project site here.

Documentation Video

I even made the video showing the plugin in action.

Bugs and Feature Requests

If you would like to request any features please use the issue tracking system.

Enjoy!

IntelliJ and Garbage Collection

I recently read the article about garbage collection (here) and decided to tweak my IntelliJ settings.

I am using IntelliJ 6.0.2 and JDK 1.5.0_08.

I ended up with the following settings:

-Xms256m
-Xmx512m
-XX:MaxPermSize=200m
-XX:MaxGCPauseMillis=10
–XX:MaxHeapFreeRatio=70
-XX:+UseConcMarkSweepGC
–XX:+CMSIncrementalPacing

Let’s explain them:

Heap size

-Xms256m
-Xmx512m

The more the better…

Perm size

IntelliJ likes a lot of memory for caching references and class meta information. That is why we need to make sure that cache is not purged. Cache is stored in “Old Generation” space which size is determined by the following option

-XX:MaxPermSize=200m

200m is good for the size of project I am using. General rule is to observe memory indicator after using find symbol option with include non project files selected. If it doesn’t move you have chosen enough memory.

Maximum Pause

-XX:MaxGCPauseMillis=10

We ask GC to pause the application for no more then 10 milliseconds.

Proportion of free space

-XX:MaxHeapFreeRatio=70

We ask GC to kick off when more than 30% of memory is occupied, so when we start compilation GC will not interfere because it will be enough memory free.

Concurrent Mark-Sweep (CMS) Collector

-XX:+UseConcMarkSweepGC

We want GC to run in parallel with other threads without freezing the application. This option doesn’t stop GC from freezing the application but it reduces it significantly.

Incremental Mode

–XX:+CMSIncrementalPacing

We don’t wont to freeze the application so we do GC incrementally with breaks so the application can take a breath. We use Pacing so GC can learn how to use CPU based on application CPU usage.

Literate testing – extending JMock

I have come across the following post today: http://weblogs.java.net/blog/tomwhite/archive/2006/05/literate_progra_1.html

I think it is a great idea to use natural language to simplify unit testing. I even wrote couple of similar extensions to JMock lately. I will share them soon

JMock vs EasyMock

Many developers choose EasyMock over JMock. The main argument is “JMock tests are not easy to refactor because method names are passed as a string”. I am not going to comment on that as many people already proved that good IDE can handle it easily.

What people do seem to forget is:

• JMock uses literate API,
• JMock tests are much more consistent comparing to EasyMock (you can clearly see what the expectations are)
• In JMock you can easily differentiate between expectations and stubs
• In JMock you can easily show which parameters are insignificant using ANY-like
• EasyMock produces very ugly code when expected methods declare exceptions
• EasyMock produces ugly code when expected method doesn’t return the value

Probably there is more…

Let me know what you think!

Friday School of Refactoring – Extract Method – video

People still don’t use refactoring!

Some time ago I realized how many developers still don’t use simple refactorings like Extract Method or Replace Temp with Query etc. Many of them don’t know how excellent the development tools are these days. Simple one-click/keystroke operation can make their code much prettier and simpler.
I even heared once the opinion that “tools can not be trusted” as they can break the code while refactoring.
I don’t think it is the case especially with IntelliJ and Eclipse. These editors are quite smart and if used well can almost write the code for you I know, I know I went too far…

Friday school of refactoring

I decided that I have to do something to change it. I started posting a weekly refactoring guide to my team-mates. Every week I pick some example from our system and make it simpler, prettier, easier to maintain – I refactor it. You could see one of the examples in my post Refactoring – conditionals.

Video

But reading emails full of code seems to be a bit boring, so this week I made a movie.
It shows the following refactorings:

1. Extract Method
2. Inline Variable/Replace Temp with Query
3. Rename Variable

Show it to your team mates!
We can change the world together

Disclaimer:

I know that movie has a bug – extract method takes one line at the top too much…
I am too lazy to fix it… and not too many people spotted it

@Configurable without Spring in 10 minutes

Why

I was asked recently to remove Spring from my project… I know, I know one step forward two steps back… I wasn’t happy at all. It was because Eclipse was crashing when two plugins had its own copy of spring library… Good excuse to remove Spring…

Problem

We are heavily using @Configurable and AspectJ so we needed some mechanism which could replace spring aspect in injecting dependencies.

How

Just look below:

 1 @Aspect()
 2 public class ConfigurableHackAspect {
 3     private static Map<String, Object> beanMap = new HashMap<String, Object>();
 4
 5     public static void registerBean(String id, Object bean){
 6         beanMap.put(id, bean);
 7     }
 8
 9     @After("@within(com.xyz.common.ConfigurableHack) && execution(*.new(..))")
10     public void afterConstructor(JoinPoint jp){
11         for(Field f : getAllFields(jp)){
12             if (f.isAnnotationPresent(InjectDependency.class) && beanMap.containsKey( f.getName())){
13                 try {
14                     f.set(jp.getTarget(), beanMap.get(f.getName()));
15                 } catch (IllegalAccessException e) {
16                     throw new RuntimeException(e);
17                 }
18             }
19         }
20     }
21
22     private Field[] getAllFields(JoinPoint jp) {
23      return jp.getTarget().getClass().getFields();
24     }
25 }

Example usage

 1 class XYZ{
 2     …
 3     @InjectDependency public IMarketDataSupplier marketDataSupplier;
 4     …
 5 }
 6 

Summary

It is not perfect as it requires injected field to be public, but it does the job and is good enough for 10 minutes…