This is gonna be a short series about my impressions of JavaOne 2011.

As always, it is nice to see the town decorated for the event, even though Oracle World gets certainly much higher attention. So the immigration officer as well as the nice guy sitting next to me on a bench at Union Square ask “ah – you are a programmer? Are you here for Oracle World?” “Hmpf…”

Should you ask yourself “what’s in for me”? Here is a first answer: the conference material

The bag is not very practical for a software developer. I guess the selection has been taken by an Oracle employee who assumes that their conference attendees never carry any material themselves in the first place (which may be true for OracleWorld). The jacket is very nice, though.

And, yes, you can rate conference organizers by the badges they produce. Hey, that should not be too difficult, right? Here is what you still can make wrong:

• Printing the delegate’s name so small that it is hardly readable from more than 20 cm away. Now since the badge usually hangs at belly height (if not lower) this can be a bit embarrassing for both involved parties.
• Second, the name belongs on both sides of the badge! Really! How often did you try to read the name only finding that the badge hangs the wrong way around?

Otherwise, the waiting time was not too long. The speakers registration was actually empty when I arrived. The attendees registration was pretty well filled, though. But then everybody has to go to the material pickup which was for me in Moscone West 3rd floor where I waited in line for about 20 minutes and I was very early and the queue grew much longer afterwards.

This made me think about my latest work on highly concurrent producer-consumer scenarios (http://people.canoo.com/mittie/kanbanflow.html) and what it would need to improve the situation.

Otherwise, from studying the program schedule, I found that Oracle has wisely chosen to pretty much always put two Groovy-related talks in parallel as if to make sure that nobody can escape the Groovy (\G) in these time-slots.

I’m eager to see what the week will bring.

Dierk Koenig, @mittie

first of all, it is very helpful to familiarize yourself with your OS-specific keyboard commands for moving the cursor around and with the Shift key pressed, doing a selection. On Mac that is Cmd left/right for begin/end of line and Alt left/right for jumping over words. Of course you can use the mouse for selections but once you master the keystrokes, you will be faster and more precise.

is widening the current selection. That is, if you already have a selection, it expands it to the next enclosing syntactical scope (expression, statement, block). Without a selection, it starts a selection at the caret.

Mac users may expect Cmd W to close the current editor (internal window) as typical for mac applications, but that functionality is mapped to Cmd F4 in the standard keymap (somehow resembles the Windows keystroke).

I use widening most of the time to select a small expression precisely – often for later use in a refactoring. I start in the middle of the code and hit Cmd W repeatedly.

When selecting a larger block, let’s say a method or a whole class body, it’s efficient to place the cursor just after the opening brace and hit Cmd W just once to select the whole block.

surrounds the selection (or current line if there is no selection) with a live template. This features spares you the need for fiddling around with cursor positioning to put some code into an “if” block and the likes. I even made my own templates for surrounding a selection with parentheses, brackets (to make a literal Groovy list), braces (to make a closure or block), single quotes, and double quotes.

Especially putting quotes around a selection is nice since otherwise IDEA sometimes inserts pairs of quotes when it shouldn’t.

when you have a selection and open the context menu (right mouse click) you’ll see a “Compare with clipboard” entry, which opens the internal diffing view. Nice.

yanks out the current line. I use this a lot. It is quicker than selecting and deleting even when yanking many lines, since you can simply press the same keystroke again (remember the discussion about interaction design?).

duplicate the current line (or selection). Again, a much used shortcut for me for making variants of the current line or selection. Some Eclipse converts take issue with this one since they expect a delete action. (It’s worse when you get from IDEA to Eclipse and mistakingly delete a line that you want to duplicate, but then you deserve the pain)

comments the current line or selection with a line comment (//). This has a little gotcha when working with non-english keyboards where you need to press Shift to get to the slash character. With my swiss-german layout the shortcut is actually Cmd . (dot) because the dot is where the slash is on english keyboards (see also http://youtrack.jetbrains.net/issue/IDEA-63779).

join the current line with next line. This shortcut is used by many text-editors. It is worth remembering. Much faster than a manual join.

moves the current line (or selection) one line up or down. This used to have issues in older versions when it tried to be too clever about which lines to jump over, e.g. when you select a whole method, it jumps not per-line but per-method. This makes sense for methods but other blocks are not as easy to support since you may want to nest them. The “intelligent” jumping sometimes led to unexpected results, especially in Groovy code. I haven’t seen any trouble with version X, yet.

the “insert explaining variable” refactoring is something you normally call on a selected expression but when there is no selection, it takes the current line as the expression. Now, this has an interesting effect: in a variable assignment, you never have to write the left-hand side! I learned this from IDEA uber-guru Vaclav Pech himself. It works like this: you don’t type “MyType myRef = expression” but only “expression” then strike Cmd Alt V. Try this and enjoy the effect.

helpful selection modes and type inference

Please note that this is for Groovy and Grails development on Mac OS X with Swiss-german keyboard layout and default keymap, so the keybindings may differ on your machine. (For Windows, you most often can replace Cmd with Ctrl)

With only a few keystrokes it becomes much easier to move code around in your editor or gather more information.

Press the Alt key while selecting with the mouse

and the selection is in “column” mode. Very useful for many well-formatted source files and often even more in resource files with tabular format.

Column mode

can also be toggled with a keystroke. I couldn’t quite remember the default keystroke, so I’ve set it to Cmd Alt Backspace. To find your keystroke look in the Edit menu under Column Mode (or as always use Cmd Shift A and type “col”).

Hold Cmd while hovering over a reference

and you will see the inferred type like so:

Note that this is Groovy code and from the content of the dynamically typed myMap, IDEA infers that this is a Map from Strings to Integers, i.e. not only the raw type is inferred but also the generic type! Is that cool or is that cool?

We touch a very important topic here.

Many developers are under the misconception that IDEs can only do what the compiler of a specific language does. The Groovy compiler does no type inference but still, IDEA does and uses this info for code completion, analysis, refactorings, warnings on mistyped method names, and so on.

This shouldn’t come as a big surprise. Even for Java, IDEs do a lot more analysis than what the Java compiler does.

Using a dynamic language like Groovy does not mean that you lose all the IDE support (as you can hear occasionally). Also note that in Groovy you can always declare your types, making it an optionally typed language.
Inside IDEA, you can seamlessly switch between Groovy and Java, using cross-language testing, debugging, analysis tools, and refactoring.

The next post will be about more editing commands.

keep groovin’
Dierk
@mittie

Understanding dependencies – a smooth intro

Beside all the navigation, editing, and refactoring goodness that IDEA brings to the table, there is one feature that I really adore and find under-utilized by most teams: the dependency structure matrix (DSM).

It seems that many developers shy away because they expect it to be difficult, while in fact it is easy to understand and remember with just a little bit of intro. Here it comes.

Prerequisites: your project must compile. That’s it.

How to start: from the Analyze menu choose Analyze Dependency Matrix.

This is what you see (this is the code from my personal wiki – yes, it has only 5 classes. The code is under github.com/Dierk/MittieWiki)

Now, what does this mean? Well, it actually shows the layering of your architecture – not how you want it to be but how it actually is.

How would you depict the architectural layers in a document? Probably as some kind of pyramid with the common functionality as the fundamental bottom layers and users of the infrastructure on top of it. The DSM is exactly that!

If you want, you can imagine the pyramid being slightly pushed to the left such that the left edges align. Then you have exactly the lower-left triangle of the DSM. The upper layers depend on what is below them. They use the common base functionality.
The common base layers use nothing, therefore they go to the bottom. The uppermost layers are used by nobody.

For the moment, we don’t look at the numbers since we only seek to understand the structure.

The structure of the DSM shows that EventController (second line) uses classes below it. But which ones? Simply click on the EventController label and you will see this picture:

Every class that EventController actually uses gets an orange marker. Do yo see the one at CookService? From that we can tell that EventController uses CookService and no other project class!

CookService seems to be an interesting class. So let’s click on its label:

Do you see the green markers? They tell that CookService is used by EventController, FindController, and PageController.

From this intro you can infer that green markers should always be above the current selection and orange ones below.

Understanding the numbers

The numbers quite obviously show how often a class uses some other class. But which cell contains this information? Well, if you think about it, there is only one possible way of arranging numbers in cells that makes sense. Let’s revisit

The blue cross covers the number 5 saying that EventController uses CookService 5 times.

I mean, you only use classes below yourself, that means a cell that tells how often you use it must necessarily be placed below you, right? And where else should it be than in the row of the used class? And it is quite obviously in the column that responds to the using class.
The columns are not labeled explicitely but they are in same sequence as the rows and therefore you can simply use the diagonal as a “mirror”.

Fazit: usages along with usage counts are shown in the column below the diagonal!

With this knowledge we can anticipate what happens when we select the other controller classes. They equally show 5 usages of CookService.

Now, think in the opposite direction. Who uses our class?

EventController uses CookService 5 times. In other words: CookService is used by EventController 5 times. And the same is true for FindController and PageController. That’s three times the used-by count of 5 in the same row. This means: used-by along with its counts is shown in the row of the used class!

In cases where the situation is less obvious, you can select a single cell (here where the 5 is in) to see the whole picture:

So much for the intro.

A very comprehensive description with many use cases and screencasts is under http://www.jetbrains.com/idea/features/dependency_analysis.html . You will see that this intro helps you understanding it. Once you have understood the concept, you will easily grasp package dependencies, module dependencies, and cyclic references.

The DSM has become an indispensable tool for my consulting work. Whenever I visit a new project, it is my first tool to fire up. There is so much to tell from this simple matrix.

After a while, you start to see patterns like a horizontal line of dependencies (as in CookService) to show a service or utility class or a line just below the diagonal to show a strict layering, breaches of layering, and so on.

A word of caution

Static analysis never shows the whole truth. Especially, it doesn’t show semantic dependencies. Just recently I heard a friend advocating the use of dependency injection to avoid unwanted dependencies in the DSM. It is very easy to fool oneself with that approach if the semantic dependency is not resolved at the same time.
Actually, I’d rather like to see my unwanted dependencies in the DSM than hiding it with tricks (DI, AOP, “Object” in signatures, “def” in Groovy).

I hope this little intro motivated you to give the DSM a try.

keep groovin’
Dierk
@mittie
dzone: http://www.dzone.com/links/r/intellij_idea_tips.html