The essential tools for software developer

As a software developer I have used a ton of different tools for different purposes. However, it got me thinking, if I really need a lot of tools and what are the essential tools for software developer and what tools are rather “nice to haves”.

Editor

First, we better be able to write code. Hence, the editor is absolutely required. For Java, I’ve used different IDEs, but mostly IntelliJ IDEA. NetBeans IDE is nice. Eclipse-based IDEs shine in one way or another. I usually prefer to install JBoss Developer Studio as it provides a solid support for Java EE projects.

For one-off editing, I still use Vim and can’t get rid of it. I’m not even using the full power of the editor. I’ve tried other awesome editors at different times: Notepad++, Crimson, Atom, Sublime Text, VS Code (which I do have installed on my machine). Still, those editors haven’t got much use by me for some unknown reason.

The cool thing about the editors is that there’s so much choice!

Version Control System

In 2004 I started at one financial company as a Java developer. The first task I was assigned to was something likes this: “We have an application running in production and it has a few bugs. We need to fix those, but we don’t have the source code. Please do something?”. A disaster. They didn’t use source control properly and managed to lose it.

Today, the scenario above is very unlikely. However, I still hear stories how people store the source code in folders with suffixes _1, _2, _3 on the network drive. Argh!

Which version control system would you pick? IMO, today Git is the dominant one. However, the way people often use Git (or any other distributed VCS) by avoiding branching and playing with feature flags, they probably would be just fine by using Subversion instead :)

Issue Tracker

An issue tracker is absolutely needed for the team to plan their work, tasks, issues, etc. Now the question is in the implementation. I’ve seen tasks being tracked in MS Excel, text files, sticky notes, and other modern tools like Jira, Mingle, PivotalTracker, YouTrack, ForBugz, Bugzilla, Mantis, Trello… the list is infinite!

The thing with issue trackers is that they should support the approach you take for running the project. For a product company there are quite a few reasons to track issues. First, obviously, you need to track your work, i.e. tasks. From the project management perspective, it’s nice to have the ability to track the tasks, i.e. have the project management facilities in the task tracker. Lots of teams are happy to have it all in one so it’s easier to get an overview of the progress, especially if the tool provides Kanban style boards.

Second, good products usually have users who are eager to submit questions or bug reports. For that, most of the teams are using some kind of helpdesk software. HelpScout was the one I have used at ZeroTurnaround and can recommend. Plus, some teams make use of forum software that also serves as a channel for communication. Also, some teams expose a public issue tracker so that the users would directly submit issues there.

The above means that the issue tracker you choose is better have the required integrations available if that’s a requirement.

Continuous Integration

You write code in the editor, you test the code on your machine, you push it to Git. Someone pulls the code down, tries to run it, and it doesn’t work. Sounds familiar? Yeah, reminds me the famous “Works on my machine” excuse. Automation is absolutely required for a healthy software project. Automated builds, automated tests, automated code style checks, etc.

Previously at ZeroTurnaround, I’ve seen that the CI server was a very critical piece of project infrastructure. If a source control system want offline, it wasn’t an end of the world to them. But if the build server was down, for many developers the work pretty much stalled. Now at JetBrains, I also see that their own product, TeamCity, is a very important service internally, with many teams relying on it. Dogfooding at its best!

Continuous integration was brought to the masses by eXtrame Programming practices. Today, CI is absolutely essential to any healthy software project. Years ago it all started with automating the test execution, building the artifacts, and providing the feedback quickly. Remember CruiseControl? Or Hudson, when it appeared? CI servers have been evolving the in the past years as the notion of Continuous Delivery appeared. Better visualisation of the process is required to cope with growing complexity. Also scaling the CI server has become an important aspect of the process.

With the latest trends in CI, the build servers are eagerly implementing the notion of build pipelines (build chains in TeamCity) which provide a good overview of the process. And also the trend of 2018, I think, is running the CI tasks in a Kubernetes cluster.

Artifact repository

The build server produces the artifacts. Plenty of them. Either the artifact is a final software package, or a reusable component, or a test execution report, etc. Where would you store those artifacts with all the metadata associated with it? Today, there isn’t much choice, actually.

JFrog’s Artifactory is the dominant solution for storing binaries and managing them. Plus, the final artifacts could be promoted directly to Bintray for distribution. Sonatype’s Nexus was originally the go to solution for Java/Maven projects and added support for some other technologies as well in the recent years. Apache Archiva and ProGet are the other options but that’s pretty much it.

The security aspect of software development becoming more and more critical. I think, automated security checks will become an absolute requirement for any software as well. The trend that has been ongoing for years now and binary repositories, such as Artifactory and Nexus, are actually integrating with the services that provide such vulnerability checks. So, don’t be that guy, use the binary repository!

Summary

I have listed 4 categories of tools that I think are essential to any software project:

• an editor,
• a version control system,
• CI server,
• and an artifact repository

I didn’t mention build tools, compilers, static code verifiers, etc, but those are the small tools that will be used by developers anyway. And if not, some of the tools I’ve mentioned can replace or provide such functionality as a bundled feature.

I will be speaking at JavaOne 2015

I'll be speaking at JavaOne this year again! This time I have 2 talks accepted:

CON3597 - Having Fun with Javassist. This is merely a live coding session where I demonstrate various uses of the Javassist library for Java bytecode manipulation. I've delivered this talk multiple times and every time it is different as it turns out quite interactive and attendees usually ask questions right in the middle of the talk so I have to adjust the content as I go. Usually it's quite fun, so I enjoy presenting this talk.

CON6699 - What's the Best IDE for Java EE? I'm not sure how this one turns out - it's so much to talk about and so little time. I'll be presenting this talk along with Max Rydahl Andersen and Adam Bien. This time we're focusing solely on Java EE. Basically - it's and overview of what's available for Java EE users in Eclipse, NetBeans IDE, and IntelliJ IDEA.

Both the talks can be found in the content catalogue for JavaOne.

IntelliJ IDEA 14.1 - Distraction Free Mode

IntelliJ IDEA 14.1 was released just recently with a good set of new features and improvements. Among other things, one really interesting feature that appeals to me is the new "distraction free mode".

Essentially, entering the distraction free mode means that you'd hide away everything but the editor.

The seasoned IntelliJ IDEA user would now ask, how is it different from "presentation mode" that is already available, or the full screen mode?

it would be helpful if @intellijidea explained the exact differences between 'presenation', 'distraction-free' and 'full screen' modes

— Prashant Deva (@pdeva) March 24, 2015

This is a very good question! Let's try to answer that! :)

Presentation mode

Presentation mode is designed essentially for delivering presentations. Some of my friends have adopted the presentation mode for actual coding. But to be honest, it only works fine if you have a reasonably large screen and you're not switching between windows while coding. This is how the whole screen looks like when IntelliJ IDEA is in presentation mode:

The default font size in presentation mode is much larger and can be configured in Settings -> Appearance & Behavior -> Appearance. Locate the setting at the bottom of the view:

Full screen mode

Entering the full screen means exactly that. IDE window will span the full screen area. On Mac OS X it also means that it will take the application window to another desktop, which I actually dislike very much, but it's rather a personal preference. In this mode, nothing is changed in the IDE window - all the toolbars, views, etc are preserved.

Notice all the control elements and widgets at the screenshot above?

Distraction free mode

"Distraction free mode" is actually just a fancy name that the marketers came up with :) In fact, it just means that by entering this mode you only keep the editor. This might sound like you're actually entering the presentation mode, it's an incorrect conclusion. In distraction free mode the IDE window doesn't expand to full screen and the fonts are preserved in the original configuration. Basically, we could call this mode as "Hide all toolbars" and it would probably confuse some users less.

At the screenshot above, you can see - it's only the editor that occupies the IDE window. No toolbars, no status bar, no additional views, nothing! So this is exactly what I wanted and I'm really pleased with the new feature! In addition, the text is center-aligned!

What's also cool is that in this mode I can still navigate the same way as I'm used to it in the normal mode. Navigate to the project tree:

... or call out the navigation bar:

Just have to learn the shortcuts ;)

P.S. The new distraction free mode is really cool. However, it is not quite new. In fact, all this was possible long before version 14.1. Even in earlier versions of IntelliJ IDEA you can achieve the same, just not with one mouse click or shortcut press. In the earlier Intellij IDEA versions, in the View menu, you could just hide the toobar, tool buttons, status bar and navigation bar and here you go - you have a "distraction free mode"! :) So the new feature isn't really new. It is rather just a convenience that was added on top of the existing features.

IntelliJ IDEA: Have you tried Search Everywhere yet?

The Search Everywhere action, invoked with double Shift key press, was added in IntelliJ IDEA version 13. I guess, most of the IDEA users/fans know about this feature and are enjoying it. At first glance, it just provides the means for search. You can search "everything": classes, files, symbols, actions, settings, etc. However, Search Everywhere widget is full of easter eggs.

Try using to jump between the search result groups. Or try left arrow to navigate in the history of search entries. But also, depending on the nature of the item that was found, the widget can provide some extra actions, like in the screenshot below: the "Show Navigation Bar" entry has an extra switch - on/off - showing that you can actually invoke this action.

Search Everywhere is a little gem in IntelliJ IDEA and all its features are yet to be discovered ;)

IntelliJ IDEA for Eclipse users

Finally! With help from the awesome RebelLabs team, I present you the Getting Started with IntelliJ IDEA as an Eclipse User report.

If you're an Eclipse user and considering to give IntelliJ IDEA a try - this is the finest read for you! If you're a convinced Eclipse (or NetBeans) user and not considering to switch to IntelliJ IDEA, still, you might learn something interesting from this report. If you are an IntelliJ IDEA fan, yet, you can find something interesting from this read.

Getting Started with IntelliJ IDEA as an Eclipse User from ZeroTurnaround

IDE Fanboys

I just leave it here...

JavaOne 2013 - Apples and Oranges: The Highlights of Eclipse, IntelliJ IDEA, and NetBeans

Automating IntelliJ IDEA Plug-in Development

In the previous post I wrote about managing the dependencies for IntelliJ IDEA plugin development and generating the project files. This was pretty simple and here's the full script:

apply plugin: "java"
apply plugin: "idea"

repositories {
    jcenter()
    maven {
        credentials {
            username 'username'
            password 'password'
        }
        url "http://my.repository.url
    }
}

dependencies {
    compile('org.zeroturnaround:jr-sdk:5.4.1') {
        transitive = false
    }
    compile 'org.ow2.asm:asm-all:4.1'
    compile 'org.slf4j:slf4j-nop:1.6.3'
    compile 'org.apache.commons:commons-compress:1.2'
}

defaultTasks 'setup'

idea.project.ipr {
    beforeMerged { project ->
        project.modulePaths.clear()
    }
}

idea.module.iml {
    withXml {
        it.node.@type = "PLUGIN_MODULE"
    }
}

task setup {
   description = "crete .idea based project structure"
   dependsOn ideaModule, ideaProject
   doLast {
     copy {
        from '.'
        into '.idea/'
        include '*.ipr'
        rename { "modules.xml" }
     }
     project.delete "${project.name}.ipr"
   }
}

task wrapper(type: Wrapper) {
    gradleVersion = '1.8'
}

The script is only limited to pulling down the dependencies from binary repository and generating the project files. However, one really big thing is missing here, is the SDK setup. Adding the new SDK for plugin development is simple enough, but I still have a good reason to automate that. In my plugin, there's a dependency on some SDK artifacts that are not included into SDK classpath by default. So adding the dependencies one by one into the SDK via the UI is a bit tedious and not really encouraging for the team work.

It would be cool if the script could register the IntelliJ Platform Plugin SDK and add it into the project files. It turns out that it should be doable as the SDK definitions are stored in options/jdk.table.xml file in IntelliJ IDEA's configuration directory.

It might be a bit brittle to go tinkering with the file directly, so maybe JPS API could actually be used to add a new entry for the SDK. (just an idea)

Those would be the steps for automating the setup:

1. Fetch dependencies and generate .idea directory based project
2. Generate Platform SDK entry to options/jdk.table.xml and add the reference to project *.iml file and .idea/misc.xml file
3. Optionally, add more dependencies to Platform SDK definition
4. The final step is the to add the build and release logic to the script

Now, a little bit of dreaming :-)

In the ideal world, the steps could be described as properties in build.gradle file:

1. idea.module.type="PLUGIN_MODULE" - resolve as plugin module
2. idea.project.sdk=auto (and idea.module.sdk=auto) - auto-generate the SDK entry (with good defaults) and add it to the project and module
3. The extra SDK dependencies are probably something that needs a special care. Don't know what could be the best workaround, but maybe something like this:
   

   idea.project.sdk.dependencies {
      lib1.jar
      lib2.jar
      lib3.jar
   }

4. Build script would basically mimic the autogenerated the Ant file, and release step actually requires a bit more than just changing the version of the artifact: the version in META-INF/plugin.xml has to be updated as well.

Dreaming aside, I think that the steps described above could be automated with a reasonable effort.

Managing Dependencies for IntelliJ IDEA Plug-in Development

Probably the most painful part in developing plugins for IntelliJ IDEA is the dependency management of the libraries that your plugin might depend on. There is a multitude of problems that one may encounter:

• IDEA binaries are not hosted publicly neither in Maven Central, JCenter, or any other repository.
• Plugins cannot be built with the common tools like Maven or Gradle without setting up your hair on fire.

When your plugin depends on just a few external libraries, and the plugin build itself doesn't require customization, then everything is simple: put the dependencies into lib/ (or whatever) folder in the project and generate the Ant build script through Build -> Generate Ant Build... action. Simple. Well, not really simple: the generated build script will require a few JARs from IDEA by pointing to the IDEA installation directory. So the simplest thing to do in this case is to extract the full IntelliJ IDEA distribution into some directory at the machine where the continuous integration server runs.

Simple, ugly, but works. Why not to make things a bit more kosher?

In my world, any developer in the team should be able to clone the project, open it in the IDE(A), and ideally, launch the project without any additional tuning.

So what could we do in case of IntelliJ IDEA plugins projects? Store the *.iml files in VCS so that when the project is opened by another developer he would automatically have all the dependencies attached to the module? Not kosher.

For me, clearly, the dependencies should be managed by dependency management tool. Options: Maven, Ivy, Gradle. IDEA provides a very good Maven support. But not for its own plugin modules. In fact, for plugin modules I wouldn't even try to use Maven as once IDEA recognizes it as a Maven project, it will erase the information about its plugin origin.

Other options: Ivy and Gradle. Ivy is awesome. It works. There's also a nice plugin for IDEA that will automatically import the dependencies if it locates ivy.xml in the project directory. In that case you could still use the autogenerated Ant build script - just alter it a bit so that it would make a call to ivy task to get the dependencies and incorporate 'em into the build classpath.

Sounds a bit too hardcore to me. There's a high chance that the project import will not be as smooth as you would like it to be. Especially if the project structure isn't very trivial.

Gradle to the rescue!

Gradle is awesome when it comes to non-trivial project structures. Its Ant-like flexibility along with nice Groovy syntax and all the Maven-like goodies is just awesome!

First of all, managing dependencies is very easy. For instance:

  repositories {
    jcenter()
  }

  dependencies {
    compile('org.zeroturnaround:jr-sdk:5.4.1') {
        transitive = false
    }
    compile 'org.ow2.asm:asm-all:4.1'
    compile 'org.slf4j:slf4j-nop:1.6.3'
    compile 'org.apache.commons:commons-compress:1.2'
  }

The little cool part is that JetGradle (in IDEA 12) would also automatically resolve and add the dependencies into the project.

This is cool but it is not enough. First of all, JetGradle cannot import the project as an IDEA plugin module. Secondly, there's no JetGradle in IDEA 13 as Gradle integration is getting a major overhaul. OK, back to the drawing board.

There's an 'idea' plugin for Gradle, how cool is that?

Just run gradle idea and it will generate the project files, incorporating the references to the required dependencies. Good. But the generated module type is a Java module. And I need Plugin module. Have no fear, Gradle's here! We can easily customize the build script to adjust the XML project descriptor to our requirements.

  apply plugin: "idea"

  repositories { ... }
  dependencies { ... }

  idea.project.ipr {
    beforeMerged { project ->
      project.modulePaths.clear()
    }
  }

  idea.module.iml {
    withXml {
      it.node.@type = "PLUGIN_MODULE"
    }
  }

The withXml hook makes the magic here - instead of the auto-generated 'JAVA_MODULE' the final descriptor will contain 'PLUGIN_MODULE' which will make IDEA think that the module is an IntelliJ IDEA plugin.

Only little problem that bothered me: the generated project descriptor is an *.ipr file that is kind of deprecated. It would have been much better if the plugin generated a directory based project metadata. The feature request was filed long ago but still isn't resolved.

After experimenting with the project descriptors for a bit, I actually found a simple workaround for this minor annoyance. The .idea directory structure requires only modules.xml file that is identical to the *.ipr file that idea plugin generates. So I could just use this simple task to create directory based structure:

  task setup {
     dependsOn ideaModule, ideaProject
     doLast {
       copy {
          from '.'
          into '.idea/'
          include '*.ipr'
          rename { "modules.xml" }
       }
       project.delete "${project.name}.ipr"
     }
  }

[hate mode="on"]Just writing delete "*.ipr" would not work. That's annoying.[hate mode="off"]

So now I could just execute gradle setup and it would generate the directory based project structure, with the correct references to the required dependencies and I could import the project into IDEA without any hassle.

This is all good. However, this is not the end of the story! There's more to do and more issues to resolve:

• Get the required IDEA internal artifacts to a local repository, so that these dependencies could also be downloaded via Gradle dependency manager.
• Migrate auto-generated Ant build script into Gradle script.
• Adopt the Gradle script to be able to manage the releases of the plugin.

However, [hate mode="on"]none of this hassle would be needed if IntelliJ IDEA provided a sane way of building the plugins and managing the dependencies.[hate mode="off"]

Maven support in IntelliJ IDEA (screencast)

The screencast demonstrates Maven integration features available in IntelliJ IDEA. Apache Camel maven archetype is used to generate the application. The main features are:

• Project setup automation and automatic dependency resolution
• Editor assistance and autocompletion
• Refactorings
• Dependency graph
• Lifecycle management using the tooling window

IDE Project Files In Version Control - Yes or No? Of Course, Not!

NB! This topic is mostly related to Java projects. The situation might be a little different in case of other technologies and IDEs.

Just recently I had some discussions with the clients who were claiming that they keep IDE project files in version control system hence they avoid any changes to those files. For reference, those are Eclipse generated .project and .classpath. From my point of view it is a bad practice by all means, however I usually prefer to collect some information on the topic before I say it loudly. So I asked from my G+ and Twitter followers, IDE project files in version control - Yes/No? Surprisingly, I've got quite a number of responses, so I decided to summarize the information as a blog post.

Basically, the answer to this question isn't binary, yes or no, but it also could be "yes, but... " or "no, if...". So there might be some argument why someone prefers one way or another.

The vast majority of the answers is "No, no, noooooooo!! Never!". And just a couple of answers were "yes" with some weak arguments of why someone should keep those files in version control.

Here are some yes answers first.

Bad stuff. Seems that the team isn't really competent with the tools. The project should be easy to setup and why on earth I should press 100500 buttons to setup a project. If this is the case, the first thing that team lead should do, is to simplify the project structure, setup and build process. No excuses there.

Yeah, yeah, I can already hear some arguments like "but we have a complex project" or "this is the way our setup is done". Bullsh*t!

OK, there is some optimization for the setup, IDE specific though. If all the team members use the same setup, it might even make sense for those who want to keep hands off the console.

Here's another one:

"Specific Eclipse plugins" - yeah! that's is actually an argument for not keeping the files in version control! Eclipse plugins usually modify .project files as they add a "nature" or any other project specific settings to the configuration. And actually, IntelliJ does the same, but (let me bash to tools a bit) IntelliJ can suggest the settings as you open a project from scratch. And with Eclipse, you have to do that manually. What if your colleague uses some awesome eclipse plugin that makes modifications to .project file, and you hate that plugin and do not want to install it, and the .project file is in version control? Here's just a simple example that you could see while exporting a project with existing project files:

This is so annoying to resolve this kind of problems. And all you want to do is just to open the project and proceed with your normal work.

Here's more:

Currently, I use IntelliJ and the rest of the team uses Eclipse. And I absolutely do not care if they put the project files into version control, because I will import it into my IDE in two clicks anyway. So the assumption that "absolutely yes, given that the team is working with the same IDEs" is wrong, and no viable argument here as well. 

However, here we have some much more interesting ideas:

Wow, this is really interesting one - "those that define formatting or source code". Indeed! In cases when you work on varions projects for different clients, the requirements and code styles might be quite different and it makes sense even to keep this kind of files in version control, so you can share it with the team and restore the code style settings if you lost them. Good point here!

However, you can probably see the vector of my post now.

So the point is, IDEs support Maven quite well, so why on earth I would need to keep the IDE settings in version control if we already have what we need: pom.xml. IntelliJ and NetBeans cope with that quite well, and Eclipse also, if you use JBoss Tools.

But what if I'm a Maven hater? (I really am). Here's an interesting conversation:

Oh sure, Gradle that is! Well, the IDE support isn't there yet. Luckily, STS provides a nice Gradle plugin for Eclipse, but the support for IntelliJ and NetBeans isn't quite there yet.

However, my claim is that Maven or Gradle isn't the prerequisite to avoid the project files in version control. The real prerequisite is the simple setup of you project and a clean structure, so that importing the project is just a couple of clicks. Then you can cope with any kind of project, even if it doesn't contain pom.xml.

And here's what most of them say about the topic:

Myself, I have tried both ways - keeping the project files in version control and not checking them in, and my take is that under no circumstances it is a good idea to check the project files in. Again, a much better solution is to keep your project structure clean and simple, which might be harder than to check the files into version control, but much more beneficial on the long run.

Thanks everyone for the input! Take care...

IntelliJIDEA Tip: Configuration Profiles

How many plugins do you have installed in your IntelliJIDEA instance? How many of the plugins are actually active? Do you need all the plugins to be active at once? Thins might be a quite realistic scenario that you have a fairly large number of plugins activated but you need only a some of them to be active while working on some particular project. Unfortunately, there's no such thing in IntelliJ as "configuration profiles" out of the box, so that for each "profile" you could enable only specific features and thus drop some weight of your IDE while working on a specific task. However, the "profiles" can easily be emulated. In IntelliJ the settings are stored under USER_HOME/.IntelliJIDEAxx folder. There you will find all the settings, plugins, and other stuff related to your current IntelliJ installation. This directory is actually the current "profile" of your IntelliJ installation. In IDEA_HOME/bin/idea.properties file there is a number of properties that refer to the settings directory:

 
 idea.config.path=${user.home}/.IntelliJIdea/config
 idea.system.path=${user.home}/.IntelliJIdea/system
 idea.plugins.path=${user.home}/.IntelliJIdea/config/plugins
 idea.log.path=${user.home}/.IntelliJIdea/system/log

So in order to create a new profile you need to copy the settings directory from USER_HOME/.IntelliJIdea to USER_HOME/.MyIntelliJ and in the configuration file that points to the settings directory you need to change to pointers accordingly to:

 
 idea.config.path=${user.home}/.MyIntelliJ/config
 idea.system.path=${user.home}/.MyIntelliJ/system
 idea.plugins.path=${user.home}/.MyIntelliJ/config/plugins
 idea.log.path=${user.home}/.MyIntelliJ/system/log

Assume, I will keep the configuration in MyIntelliJ.properties file. Now, on the startup, IntelliJ just needs to know, which properties file to use. As the documentation says, we can either set up IDEA_PROPERTIES environment variable to specify custom location of this properties file, like

set IDEA_PROPERTIES=c:\config\MyIntelliJ.properties

or in unix:

export IDEA_PROPERTIES=/home/anton/MyIntelliJ.properties

In the environment variable isn't specified, the configuration file is searched according following sequence (first successful is used):
1. USER_HOME/
2. IDEA_HOME/bin

This way, it is pretty much possible to organize the profiles for IntelliJ, however, it would be cool to have such possibility out of the box via UI configuration.

What’s Cool In IntelliJIDEA. Part III: External Tools

Previous posts about IntelliJ
What’s Cool In IntelliJIDEA. Part I
What’s Cool In IntelliJIDEA. Part II: Live Templates


Although there is almost any kind of functionality available in IntelliJIDEA, either as a base functionality or via plugins, there's still a fraction of probability involved that you might want to do something that goes beyond the power of the IDE. For such rare cases you might want to take a look at External Tools in IntelliJ.

Just recently I've encountered such a case myself - I wanted to use an utility from JDK, but in a more flexible way than just switching to command line and navigating to the correct location. My idea was that I should just press an arbitrary shortcut and get the result. So I decided to give External Tools a try.

The utility I use a lot when studying Java is javap - the java class file disassembler. This is due I study the bytecode sometimes. And although there's ASM plugin available for IntelliJ that basically can provide me the result I needed, I still prefer to read the raw javap output.

To setup javap in Intellij as an External Tool go to Settings >> External Tools and press Add... . You can then define the location of the tool, the working directory, and the parameters.

The nice part of it is that IntelliJ provides some basic macros in order to dynamically resolve the parameters for the tool. So for javap it was enough to set $FileClass$ for the parameter, and $OutputPath$ as the working directory. And that's it - the tool is now ready for use.

You can also define a "group" which is then used to group the external tools in the popup menu. I use "jdk" as a group name for javap so here's what it looks after:

So that's cool but you might have noticed that it is not that comfortable to use - have to right-click the file, navigate to "jdk" group, expand it, and only then can execute javap. Well, shortcuts to the rescue! Browse to Settings >> Keymap, and there you can define any sortcut for the tool. The nice part of it is that IntelliJ detects if you select a conflicting shortcut and notifies you.

One more tweak left to do. Once I press the shortcut that I've assigned to javap, the result of decompilation is printed out to the IDE console, which is just below the source code. But it would be more convenient to see it side by side. For that, it is possible to drag-and-drop the Run window to the side panel in IntelliJ so the result can be observed right next to the source I'm currently working with.

The only thing that is probably missing is the syntax highlight for the javap output, but that is probably too much to wish.

What’s Cool In IntelliJIDEA. Part II: Live Templates

In IntelliJ, I use Live Templates quite heavily and still think that these are underused. It is not only the standard number of templates that can make your life easier while typing yet another piece of code, but it is also the ability to define new templates with all the bells and whistles that are available in IntelliJ standard template list.

In the previous post I've covered the basics of Live Templates but I think that it would be cool to cover these in more details and to point out some less-known aspects of this functionality.

First of all, Ctrl+J is the shortcut to use in order to get a list of the available by default. But if you had time to practice, most likely you can remember the abbreviations by heart, like psvm, iter, psfs, soutv, etc.

One thing I do for sure before using Live Templates is that I change the default expansion key, which is Tab by default, to a Space key. It seems to me that it is more natural to use Space for this purpose as when you type you actually hit the Space key almost automatically.

Another cool feature of Live Templates is to surround a capable statement with a block of code - also covered in the previous post.

How do I define my own template?

IntelliJ provides a number of templates in its default distribution but obviously it doesn't cover all cases you might need. So here's the main purpose of this post - how to define a custom live template in IntelliJ. First, let's make up a use case - a situation where we'd like to have some means for typing faster but which isn't defined in the IDE by default.

For some reason, IntelliJ doesn't provide try-catch template by default. It only suggests this option if you'd like to surround an existing statement with the try-catch block, but not when you just want to create an empty one. Here's what we can do: open Settings window (Ctrl+Alt+S) and start typing 'Live Templates' - this will lead you to the templates' settings - and hit the "Add.." button on the right.

It is quite easy to create a simple template which just has to generate a defined text for the given keyword. For the empty try-catch block we just need to fill in the abbreviation and the code itself, and not to forget to bind it to Java context using the corresponding checkbox.

This is quite a dumb template, nothing intelligent here. But what if we'd like to suggest the exception type in the catch block? What if we'd like to position the cursor in some particular place after the template is applied? Let's make our brand new template a little smarter.

To ask IntelliJ for a type of the throwable in the catch block we can add a variable ($EXCEPTION$) and define its value using a special function provided by IntelliJ. Say, I'd like the type to be a subtype of java.lang.Exception class, hence I'm using the subtype(<type>) function:

You've probably noticed that I've used another variable, $END$, but there's no value defined in the dialog window. This is a predefined variable, meaning where should the cursor be positioned after the last choice made within the templates.

So now once I type 'try' and hit the space key, the template is expanded to the following:

First the cursor will be positioned inside the catch block in order to choose the type of the exception to be handled. Right after I make my mind about the type and hit the Enter key, the cursor will be positioned back into the try block.

What’s Cool In IntelliJIDEA. Part I

Eclipse or IntelliJ? NetBeans or Eclipse? IntelliJ or NetBeans? The dispute about the IDEs is the most popular among the software developers and hardly will ever end. I consider myself being a big IntelliJ fan, but I do realize that there are a lot of things that IntelliJ could do better and that NetBeans and Eclipse are better in some ways. In this post I’d like to make an overview of IntelliJ’s features which I like the most, and and beyond that. Also I’d like point out some of the aspects in which IntelliJ could do better.

UPDATE: due to the popularity of this blog post I took some time to combine my blog posts about IntelliJ IDEA into one big article, published at RebelLabs as Getting Started with IntelliJ IDEA as an Eclipse User. You will find it interesting, I'm sure :)

Other post in the series:

• What’s Cool In IntelliJIDEA. Part II: Live Templates
• What’s Cool In IntelliJIDEA. Part III: External Tools

One of my friends said once:

I don't like IDEs. They help to write verbose code. In real life 90% of time I spend on code reading. Verbose code kills my productivity

I think he's wrong. The reality is that IDEs are used not only for writing/generating code, but to a greater extent IDEs are used to read and analyze the code. You might be a hard-core Emacs/Vim ninja but still, there are things that you just cannot do with the text editors.

Navigation

Navigation through the source code is one of the activities that programmer executes on a regular basis. Basically, it is not hard to navigate the code with Emacs or Vim, but it would limit you only to a basic navigation options. IDEs take navigation abilities one step further.

Let's see what are the navigation features in IntelliJ. First of all, "Open Type" which is executed via Ctrl+N:

The same can be achieved with Ctrl+Shift+T in Eclipse and the behavior is exactly the same.

Ctrl+Shift+N will help you to open any resource. Eclipse does the same with Ctrl+Shift+R.

And it could have been all but there's more - Ctrl+Shift+Alt+N will find you all the appearances of a specific symbol, e.g. a method name:

It doesn't mean IntelliJ will scan the code for the occurrence of the specific symbols but it rather will match the code structure and look for the elements in your code so you will get a list of method declarations but not just any appearance of the method name in the code. This is quite useful if your classes are not sharing the same hierarchy.

Often when you navigate the source code you jump over class hierarchies, browse different methods, open type declarations, etc. It is quite common that once in a while you would like to step several steps back in your navigation and proceed with some other direction. Ctrl+Alt+(left|right) arrow is a very useful shortcut for such purpose. Whenever a caret hits any place in the code this place is remembered and you can go back and forward in the your browsing history. This is quite cool as if you navigate a large code base you might not even remember which classes you actually opened just a second ago.

Actually you can get a list of the recently visited files by pressing Ctrl+E - also quite often used to reopen the recently closed files.

Navigating back in forward is the same in Eclipse (with Alt+(left|right)arrow shortcuts). But I failed to find a list of recently edited files there, while this can be done in IntelliJ by hitting Ctrl+Shift+E shortcut.

There are plenty of other feature that make your code browsing experience more pleasant. For instance, both IntelliJ and Eclipse provide a feature to quickly browse the location of the currently opened class - Alt+Home will popup a navigation bar with the path to the class.

The cool feature in IntelliJ for this navigation par is that it is possible to brows the content of any file with Ctrl+Shift+I without having to really open the file:

In Eclipse a similar feature is called "Browse in Breadcrumb" called via Alt+Shift+B. The difference is that in Eclipse it works only if a Java type is opened and it acts only as a navigation bar - no quick preview available. Also, I didn't find an easy way how to get rid of that "Breadcrumb" in Eclipse besides clicking a dedicated button on the toolbar.

Ctrl+Shift+I also works in IntelliJ for any symbol that you'd probably like to inspect. For instance, you may press this shortcut on any method call, and it will raise a popup that displays the methods source code:

Also, if you try to browse the code that maybe involved in the type hierarchy, it is possible to select the implementation by choosing the type in the very same quick view popup:

Talking about navigation on the hierarchy of classes, IntelliJ implements that also quite nicely - quick hierarchy view is available the same way as in Eclipse. The feature that distinguishes IntelliJ is the ability to easily navigate to implementation. For instance, from interface method declaration to any of the implementations. If there are multiple implementations of an interface method Ctrl+Alt+B will call a popup dialog with the list of implementations: