IntelliJ IDEA Notes

Russell Bateman
March 2015
August 2015


You might skip this self-conscious rant about Eclipse and just go on to the set-up steps.

It's hard to begin saying goodbye to Eclipse. It's been a loyal friend for over a decade. At home, on Mint 17 (and earlier Mint and Ubuntu releases), I have no particular problems of stability. However, at work on Fedora 22, it simply is too horrible to continue using (for other folk there too after we all were forced by policy to upgrade from Fedora 20 to 22).

I'm not too put out. Since I first began using IntelliJ IDEA over a year ago (at another company), I found much I didn't like, but much I did, in particular, the debugger which is a lot better than Eclipse's and now in version 14, it's even better with a number of insanely desirable features.

I had switched over to PyCharm earlier this year already and have liked that a lot better than PyDev (a lot). With the switch to Fedora 22 and the continual hanging, badly working features (really, really hard to move views around) and the need to bounce several times per day, I'm giving up and moving to IntelliJ Community Edition with even thoughts of purchasing the full edition for myself.

IDEA is really the Java IDE version of something called IntelliJ from JetBrains. PyCharm is the Python equivalent of IntelliJ IDEA. Other language targets have similarly interesting product names. As for cross-integration of these, my only real interest being Java and Python because that's what I use at work, I haven't succeeded in getting them to work either because the Community Editions do not integrate or, more likely, because I just haven't gotten serious enough about it.

I have an older set of IntelliJ notes; these were made a bit under duress, express frustrations I had when I was forced to use IntelliJ and didn't want to, but contain some useful comments especially connecting Eclipse practices with IntelliJ.

What I really like about IntelliJ IDEA

The first time I used IntelliJ, it was version 12 and it seemed a bit clunky to me. What I did like pretty quickly was the debugger, however. In version 14, the debugger is even better. The comparisons below are with Eclipse, of course.

  1. Debugger—fewer keystrokes, shorter mouse-waving to get around. In IntelliJ 14, you get to see current variable values directly in source code without the need to crane your neck around and look at the Debug panes (which I keep floating on another monitor making it worse).
  2. Better-behaved set/delete breakpoint action—click once, click again.
  3. In IntelliJ 14, a decompiler was introduced that uses reflexion to give code for classes whose source code is inaccessible including what's proprietary and/or missing.
  4. Built-in Vim—don't know when this showed up, but it's great. And, I can easily toggle it off and on via Tools → Vim Emulator.
  5. Method separators—visually, in the code via rulers.
  6. Less busy, cleaner left editor margin.
  7. More visible right editor margin features.
  8. Far better code-folding controls—don't have to scroll to the top of the method to fold the method; there's a handle at the bottom too.
  9. The IntelliSense/Code Assist seems more polished or less hinky to me.
  10. Edge menus—odd at first, they've grown on me as the best way to do very high-use Preferences.

What's not so good?

  1. AWT's (or whatever IDEA uses) not as crisp and GUI-like as Eclipse's RCP.
  2. Failure to implement Alt+Left/Alt+Right for moving between editor actions. The blue left and right arrows in the Toolbar work perfectly well, but I've never succeeded in rigging Eclipse's key assignment for this functionality and I prefer the latter approach. (Maybe I haven't tried hard enough.)

Setting up IntelliJ IDEA

Here's how that went...

  1. Download community-edition tarball from
  2. Explode and drop into place, ~/dev/idea-IC-141.1532.4.
  3. Create a launcher and pin it to the GNOME/Cinnamon panel:
    1. Menu → Preferences → Main Menu.
    2. Select Programming.
    3. Click New Item.
    4. Fill out Launcher:
      1. Name: IntelliJ
      2. Command: Browse to ~/dev/idea-IC-141.1532.4/bin/
      3. Comment: IntelliJ Community Edition (unimportant)
      4. Click icon and navigate to select ~/dev/idea-IC-141.1532.4/bin/idea.png
      5. OK
    5. Click Close.
    6. Menu → Other (why?) → IntelliJ → Right-click → Add to Panel. (You might end up with no icon, just right-click the empty space, choose Edit, then redo the step above to set the icon.)
  4. Launch IntelliJ.

  5. If all you want to do is set up IntelliJ IDEA, you've succeeded; quit now.

  6. Choose to create a new project or open an existing one. As I have an existing project that's already an IntelliJ one, I'm going to avoid opening it and just create a new one. My objective here is to configure IntelliJ.
  7. I select Java.
  8. I click the New... button for the Project SDK: because I want to tell IntelliJ where my copy of Java 8 is installed (I never use the one for my host, but always a private one I control). The filesystem browser finds and presents one belonging to my host; I don't want that.
  9. I navigate to where I keep my private JDK, /home/russ/dev/jdk1.8.0_45 and click OK, then I click Next because I couldn't give a rat's tushie about Groovy.
  10. It offers to create me a project from template. This is the last thing in the world I want to do. I loathe the original, overly deep project structure Sun preconized including and especially
    1. src/main/java/...
    2. src/test/java/...
    I get why they did that, but the Eclipse community's more abbreviate structure makes more sense to me and I don't have to type or navigate as much:
    1. src/...
    2. test/...
    So, without clicking anything, I choose Next.
  11. Now I name my project and give it a filesystem path.
    1. intellij-trial
    2. ~/dev/intellij-trial
    IntelliJ suggests placing it on the path ~/Idea/Project/intellij-trial, but, just as I rejected Eclipse's internal workspace, I reject this suggestion.
  12. I click Finish; IntelliJ creates the new subdirectory and configures the workbench. This can take a few seconds.

Some preliminary configuration

Before we get on with working with our first project, let's do some configuration.

  1. Pull down the View menu and toggle the Toolbar on.
  2. Open the File → Settings dialog. There's a lot of work to do there.

Gross IntelliJ settings

At this point, things get real specific about how you want to run your life. I'll show you mine; you can figure out yours later.


The very first place I head for is the Keymap. There, I'll do a major Eclipse thing as described in my older notes here. I fix what Ctrl-D means.

Editor / General

I want the newline at file's end. Especially in Python, it's a good thing.


I like to Show line numbers and method separators.

Code Folding

I like to lose Javadoc initially; I'll open it if I want it.

Editor / Colors & Fonts

Here, I like a different font; IntelliJ ships with a much better font, Source Code Pro. However, in order to get that, I have to begin differentiating my settings from the Default ones.

  1. Click Save As... and type "russ".
  2. As Primary font:, I choose Source Code Pro.
  3. 12pt might be a little too small; I'll remember I can change that later if my HP ZR30w monitors (2560×1600) make it too small to see.
  4. Here's a script:
    set  -euo pipefail
    mkdir -p /tmp/adodefont
    cd /tmp/adodefont
    wget -q --show-progress -O
    unzip -q -d source-code-pro
    mkdir -p ~/.fonts
    cp -v source-code-pro/*/OTF/*.otf ~/.fonts/
    fc-cache -f
    rm -rf source-code-pro{,.zip}


Next, I hate the retro, black background most people like today. It reminds me too much of my old dumb-terminal days back when I started working. I write on white not black paper; it's the natural metaphor. However, staring at a stark, white screen all day is murder on the eyes. I'll soften it a bit by finding a wheat-colored alternative for my editor window background.

  1. Scroll down to Default text or just click in the sample below the list in an unoccupied region.
  2. Click on Background, then on the white square to the right.
  3. I click around and land finally on something like #FFEEB2.
  4. Click Choose.
  5. Yeah, that's more like it: still like paper, but not blinding.
  6. I click Apply; if you have a file open in an editor, you'll see the change.

Console Font

When I debug or run tests, I'll get a console, so I change the Console Font to Source Code Pro.

Editor / Code Style

Here's where I'm the most anal... I'm an Allman not a KNF sort of guy. We left that ugly mess behind in the late 80s/early 90s, then the Sun Microsystems Java guys found a way to sneak it back in. That's confused all the young folk who weren't along for the ride in the 80s. They think it's okay to leave your code messy, harder to read and harder to comment out without syntax errors.

Anyway, smart guys that they are at IntelliJ, they have leave us the ability to import settings from elsewhere, ... like Eclipse! (Here are my own Allman-conformant settings, if you care.)

  1. Click Manage.
  2. In the new dialog, click Import....
  3. You should see Eclipse XML Profile; select that and click OK.
  4. Navigate to your carefully saved Eclipse settings; IntelliJ will glean the indentation and other code-style modifications you've been using. (Of course, you had to have exported these from Eclipse already like the ones I mentioned just above.)
  5. Click OK, then Close.
  6. You've just saved yourself a ton of work.

You can set up how your code is automatically created with company copyrights, Javadoc statements, etc. Whether and/or how may be something you'll deal with later after using IntelliJ.

Suppress deprecated symbols/features

Working on larger projects with other and on older code gone stale, I find it super annoying to have to dismiss the Messages Make window that pops up to remind me of all the deprecated interfaces in use when I have little or no control over them being consumed in the first place. To disable, go to File → Settings... → Build, Execution, Deployment → Compiler → Java Compiler and uncheck Report use of deprecated features.

Version Control

It's possible and very convenient to set up Git if you're that way. I prefer to use Git outside the IDE at the command line.

Build Tools

Your chance to tell IntelliJ that you use Maven. Click on Maven; likely, if you've set Maven up correctly, you'll find that IntelliJ already knows where to find it and there won't be too much to do.

Next I move on to demonstrate writing a tiny hello-world project with Maven.

The .iml in IntelliJ

It appears that a .iml is expected in every subdirectory/folder that is a module.

Doing the first project using Maven

If you're not using Maven, don't worry about this now.

If you let IntelliJ (or a Maven archetype) set a project up for you, it's going to have that overly deep, complicated filesystem of subdirectories described in the set-up section above.

I never really was a fan of Maven, but it's grown on me. It solves a lot of problems. 30+ years ago I started out as the team's Make guy, then moving on to Java a decade ago, I became an ant guy. Once, I almost became an Ivy guy, but that was short-circuited. Now I'm a Maven guy (and still an ant guy when necessary).

Here are my steps from leaving off those above...

  1. I write-click intellij-trial and set up two subdirectories (remember, I'm an incurable Eclipse guy) and one file:
    1. src (this one is already there)
    2. test
    3. pom.xml
    Just ignore the project-name.iml file; it's an annoying artifact of unknown value. Where I've worked, we did not keep it under version-control and never regretted not having it. The .idea subdirectory probably corresponds to Eclipse's .settings subdirectory. And it probably also contains what's in Eclipse's .project and .classpath files.
  2. I can't think of a better way to set up pom.xml than to steal one from somewhere else. It's in my nature. Here's a good, generic one to start with. You'll have to change what's on lines 6, 7, 9 and 10, and add or even subtract JAR dependencies, but paying attention to what's in here and how it's set up gets you more than 95% of the way into adequate Maven competence.
    <project xmlns=""
      <description>Experimenting with IntelliJ.</description>
    What am I getting out of this POM file, you ask? You're getting a project name, a group id, artifact id and the JARs for JUnit testing and Log4j use. You're also getting the capability of building an executable JAR for distribution.
  3. Now, let's get on

What to do when there's trouble in IntelliJ

There are many times when IDEA doesn't compile code and it's a mystery why. Before pulling your hair out, rewriting pom.xml, restructuring package paths and class relationships, try try File → Invalidate Caches/Restart then clicking Invalidate and Restart.

How to manage IntelliJ projects under version control

This format is used by all the recent IDE versions by default. Here is what you should share:

  1. All the files under the .idea directory in the project root except the workspace.xml and tasks.xml files which store user-specific settings. [I wonder: tasks.xml aren't that personal when you're collaborating.] However, I've never seen a tasks.xml file anywhere in my project (and I do have a great number of TODOs in code comments).
  2. All the .iml module files that can be located in different module subdirectories. If you don't hang on to project.iml files, things go very badly in the IDEA workbench.

How to make Run/Debug console infinite length

Edit $IDEA_HOME/bin/ and set thus:


How to add the test subdirectory
  1. File → Project Structure....
  2. In the left pane, click on Modules.
  3. In the right-middle pane, select the module (likely, the project).
  4. Click the test folder in the right-middle pane.
  5. Above it, where it says Mark as:, click the Tests icon.
  6. In the rightmost pane, under Source Folders and Test Source Folders, delete any folder you don't want (leaving just src and test).
  7. Click OK.

How to add a JAR or library to the project or module

The right way is to use Maven, but if there is a reason this cannot be done, here's how to add a library extra-Maven to the project.

  1. Create lib subdirectory.
  2. Drop JAR inside.
  3. File → Project Structure...
  4. Modules
  5. Dependencies tab.
  6. Click add (+).
  7. Select lib.
  8. Click OK.
  9. Don't click the Export checkbox.

How to open multiple projects from Eclipse sources

You've been working on a number of projects in Eclipse, but wish to run IntelliJ and want them all open in the same window. They will be called modules.

Make certain that File → Settings → Appearance and Behavior → System Settings has either Open project in the same window or Confirm window to open project in clicked or opening new modules (projects) will happen in different windows. This would be fine, but the objective is to imitate Eclipse.

  1. File → New → Module from Existing Sources.
  2. Navigate to find the root of the old Eclipse project you wish to open.
  3. Click OK.

You should be able to see something as illustrated below with three modules (projects) each with src set as if File → Make Directory As → Sources Root and test as if File → Make Directory As → Test Sources Root were done.

How to structure a new projects from existing code

Creating a new IntelliJ project

Make certain that File → Settings → Appearance and Behavior → System Settings has either Open project in the same window or Confirm window to open project in clicked or opening/creating new projects or modules will happen in different windows.

First, create the project. The name will be the same as the sandbox and the location is the sandbox:

  1. In the workbench of an existing IntelliJ project (because you can't do it from the command line as far as I know)...
  2. Do File → New → Project....
  3. In New Project dialog...
  4. Click Next.
  5. Then click Next again (don't check anything about Groovy, etc.).
  6. Set Project name: to (e.g.:), i.e.: the same as the sandbox name.
  7. Set Project location: to the existing sandbox location, (e.g.:) ~/sandboxes/
  8. Click Finish.
  9. Be sure to put this into a new window.

This gives you a new project in a new workbench window. You will see everything you're used to seeing when you list the sandbox' filesystem subdirectory. But, we're still not finished here! We have to make modules of the three, separate entities that were projects in Eclipse.

Depending on your project structure, you'll may also need to create a module of the dominant source-code parent subdirectory. (This sort of thing works very differently than in Eclipse. There are more notes on this, especially multimodule projects, below.)

Add a new module...

What are projects under a same workbench in Eclipse are modules under a same project in IntelliJ IDEA.

For example, imagine a project, cda-filter, whose filesystem structure appears something like this:
+-- cda-filter
`-- run
  1. File → New → Module from Existing Sources.
  2. Navigate to find cda-filter.
  3. Click OK.
  4. Continue set-up, taking defaults, but... uncheck (do not do) Python integration:
    Python integration in IDEA isn't supported unless you've purchased the licensed version.

Once this done, you can try to build (Build → Make Project). That might fail with either a message to set up a JDK (keep clicking, it will take you to Project Structure → Dependencies where you can set this up in Module SDK) and/or an obscure message about Maven, which you can fix also by clicking Maven Projects on the extreme right edge of the workbench window, then clicking the circular-arrow icon near the top of that pane. This should get you running. Beyond that, you're just fixing compilation errors, etc. before running.

How to structure hard projects from Eclipse origins

This is a real example that may illustrate how to piece together an IntelliJ IDEA project with modules from an existing project (that used to be three Eclipse projects). The subprojects, that will become modules in IntelliJ, are psjbase, feeder and medical-filter, the last one being also the name of the greater or parent project (which changes versions in the illustrations—beware).

I started trying to use IntelliJ IDEA to work in the greater Feeder. In Eclipse, we're used to creating maybe a new workspace, but then importing, e.g.: buildscripts, feeder, medical-filter and psjbase into the workspace because that's what the "parent," e.g.:, offers (among other things). This is not exactly how it happens in IntelliJ.

Creating a new IntelliJ project

Follow the instructions in the preceding section for creating a new IntelliJ IDEA project.

This gives you a new project in a new workbench window. You will see everything you're used to seeing when you list the sandbox' filesystem subdirectory. But, we're still not finished here! We have to make modules of the three, separate entities that were projects in Eclipse.

Add three modules...

What are projects under a same workbench in Eclipse are modules under a same project in IntelliJ IDEA.

Those three would be feeder, medical-filter and psjbase, of course. Sitting in the workbench with the new project...

  1. File → New → Module from Existing Sources.
  2. Navigate under code to find psjbase.
  3. Click OK.
  4. Continue set-up, taking defaults, but... uncheck (do not do) Python integration:
    Python integration in IDEA isn't supported unless you've purchased the licensed version.

Do this for the other two, feeder and medical-filter.

Structuring module (inter) dependencies...

For now, since we're not using Maven, the best way I can think of to solve the intermodule dependencies is the following. You'll do this for each of psjbase, feeder and medical-filter.

Setting up the Feeder's dependencies is a little precarious. First, psjbase, since everything else depends on it:

  1. Right-click on psjbase and choose Open Module Settings.
  2. Under the Dependencies tab, click the box in the Export column for psjbase's lib subdirectory. It appears that if feeder depends on something in psjbase/lib, it cannot merely depend on the psjbase module unless psjbase exports the JARs of that subdirectory. So, check the box under psjbase's Export column.
  3. Click OK.

Next, feeder:

  1. Right-click on feeder and choose Open Module Settings.
  2. Add psjbase as a module dependency (described below). Since medical-filter will add it as a dependency, you don't need to click its Export box.
  3. Add the following JARs from the built.linux_x86-64 subdirectory, an uncle to the psjbase subdirectory (as described below). This step is the most tedious.
    1. ./built.linux_x86-64/jcifs/bin/jcifs.jar
    2. ./built.linux_x86-64/tika/tika-parsers/test-classes/test-documents/testJAR.jar
    3. ./built.linux_x86-64/tika/tika-parsers/tika-parsers-1.0.jar
    4. ./built.linux_x86-64/tika/tika-bundle/tika-bundle-1.0.jar
    5. ./built.linux_x86-64/tika/tika-app/tika-app-1.0.jar
    6. ./built.linux_x86-64/tika/tika-core/tika-core-1.0.jar
    7. ./built.linux_x86-64/libwpd-java/libwpd-0.9.jar
    8. ./built.linux_x86-64/libdicom/lib/pixelmed.jar
    9. ./built.linux_x86-64/libdicom/lib/dicom.jar
    10. ./built.linux_x86-64/yanfs/bin/yanfs.jar

  4. If medical-filter depends on a symbol out of the tika JARs as well as the feeder module (it does), then the feeder module must mark the tika JARs as exported or the tika JARs must be explicit dependencies of medical-filter. Click Export for each of the tika JARs.
  5. Click OK.

Last, medical-filter:

  1. Right-click on medical-filter and choose Open Module Settings.
  2. Add psjbase and feeder as module dependencies.
  3. Click OK.

The up-shot of this is that I got it built with no red and could run a unit test, my old ApiTest.handleNewWithCommentsTest().

Please note that as a module is correctly configured, its name in the project window will become bold-faced. When it is no longer adequately configured, which may include having compilation errors created by incorrect configuration, it stops being bolded and often acquires a red underline. This goes away when it's well configured and working correctly.

This creates a project in the parent sandbox,, and...

  • dependencies.txt which lists the intricate dependencies already noted (didn't know IDEA did this, but now I know where),
  • sandbox.conf, which contains settings for targeted platform (linux_x86-64) and other, less interesting stuff.

Once finished, you should see something like this (if not, check out errors below):


The nastiest error I have got when doing this is the following:

This refers to a problem in Project Structure → Modules again, under the Paths tab. It can be challenging to get it just right. Here are illustrations of how I configurated the output paths before the error going away:

One approach is to look at all the .iml files to see if they don't have the component's inherit-compiler-output set to false. Do this to figure that out:

~/sandboxes/ $  find . -name '*.iml' -exec fgrep -Hn NewModuleRootManager {} \;
.code/psjbase/psjbase.iml: <component name="NewModuleRootManager" inherit-compiler-output="false">
.code/feeder/feeder.iml: <component name="NewModuleRootManager" inherit-compiler-output="false">
.code/medical-filter/medical-filter.iml: <component name="NewModuleRootManager" inherit-compiler-output="false">
./ <component name="NewModuleRootManager" inherit-compiler-output="true">

You'll see a list; usually, the parent one will be set to true (go figure). Set the others to true as well, then do Build → Build Project.

If that doesn't work, try working with the Paths tab of each module or submodule:

To configure dependencies...

I noted earlier that a correctly configured module will acquire a bold-faced name in the project window list. What follows here is most of the information, in addition to the immedidately previous section, needed to cause this to happen. It can be very tricky and require some patience.

Do these steps to configure other modules, libraries, JARs or subdirectories as dependencies.

  1. Right-click the module the module in the Project pane that needs dependencies defined and choose Open Module Settings.
  2. Down left-hand column, click Modules if not selected.
  3. In the next column just to the right, select the module if the right one isn't selected.
  4. In rightmost section, click Dependencies tab.
  5. Near right-hand side, click Add (the green plus).

...then, follow the appropriate steps described below for the type of dependency:

To add other modules as dependencies

  1. above.
  2. Choose Module Dependency.
  3. Click the "other" module than the one you selected in step 3 depends on.
  4. Click OK.
  5. Click OK.

To add JAR or directory dependencies

  1. above.
  2. Click JARs or directories....
  3. Navigate to the library subdirectory containing the JAR(s) needed.
  4. Click OK.

Outside the project...

In this case, I've got to maintain a .idea outside the project. As it changes remotely (wherever I am working on this code from version control), I have to make a tarball of .idea and ship it along outside version control. I mention this because of the peculiar way this non-standard project is set up.

Wrapping it up...

To test your new project/modules set-up, do Build → Make Project. If there are errors, a window should open across the bottom half of the workbench with references. Double-clicking the references will bring up the code files with the missing symbols. This should not be your experience as long as a) you followed the steps above and b) nothing has changed in the sample project that you must react to (like the addition of another JAR file to built.linux_x86-64).

To confirm, once you have a clean build, do Ctrl+Shift+Alt+N, type in "handleNewWithCommentsTest," then right-click on the highlighted method name and choose Run. The Run view should appear across the bottom half of the workbench telling you that this test case was successful.

Addendum: Configuration

Here is the finished configuation for consulting.

How to structure hard projects from Eclipse origins—addendum

Steps to IDEA-ize a complex component

  1. Make top-level component (project/module) a module.
  2. Under Paths tab for the top-level module, click Inherit project compile output path (which won't be anything).
  3. Click green + to add a new module.
  4. Click through (don't name it) to browse to the root of the submodule to create.
  5. Finish.
  6. Under Paths tab, click Use module compile output path, and make Output path:
    and Test output path:
  7. Under the Source tab, make all the non-code subdirectories (like .bzr, lib, etc.) Excluded.
  8. Under the Source tab, make Sources, Tests, Resources and Test Resources of the appropriate subdirectories.
  9. Configure Maven Projects—only if there are pom.xml files...
  10. Click on the (usually) right-side menu, Maven Projects, which will likely be empty.
  11. Click the "rotating arrow" icon. This will (usually) add the modules already configured.
  12. Configure Ant Build...
  13. Click on the (usually) right-side menu, Ant Build.
  14. Click on the green + menu to add each module (subproject/module). Navigate to the build.xml of each module.
  15. Fix Java errors: these are usually Java compiler compliance settings to be polished on each module in the Project Settings for that module. The default Language level: will often fall short of what it's supposed to be.
  16. "Error: jave: javacTask: source release 1.7 requires target release 1.7" means (usually) that under Project Structure → Project Settings → Project (the main-level dialog), the Project language level: is set (usually too high) or...
  17. Settings → Build, Execution, Deployment → Project bytecode version: isn't set or is wrong. Check also the individual module levels under (the above) Per-module bytecode version:.
  18. Fix missing symbol errors, usually from unaccounted-for libraries. Add these as necessary in Project Structure → Modules for each module under the Dependencies tab by clicking the green + and adding (to JARs or directories...) the lib subdirectory of the project/module and...
  19. ...If there is some module interdependence, that is, that some lib of one (sub)module is to be exported to (for the use of) another module, check the box under the Export column.
  20. Ultimately though, you'll just have to play around adding subdirectories, JARs and modules until all the compilation errors are fixed:

Suppress "Access can be more private" inspection

(So annoying...)

Go to File → Settings → Editor → Inspections → Java → Declaration redundancy → Declaration access can be weaker. Uncheck the box at the right.

Suppress "Field can be local" inspection

(So annoying...)

Go to File → Settings → Editor → Inspections → Java → Class Structure → Field can be local. Uncheck the box at the right.

Maven duality...

There are rare occasions where running Maven from the command line isn't what's happening inside IntelliJ. This situation is typically characterized by some strange goings-on in your project. For example, if you're using Google's addjars-maven-plugin to grab and statically link JARs from a subdirectory like lib, which IDEA hates, but Maven appears to tolerate, you're in for trouble and you have to use IntelliJ IDEA's Project Structure → Project Settings → Modules → Dependencies editor to make IDEA recognize symbols in those statically linked JARs.

JUnit symbols missing

You see a symbol from junit-x.y.jar missing inexplicably:

Beyond hope, you do File → Invalidate Cache / Restart to no avail. Then you inspect the module dependencies:

Finally, you reinspect pom.xml and discover your stupid mistake:


...only for it to dawn on you that the code consuming it isn't in fact test code when you've told Maven to restrict this JAR to the test scope.

Which JAR is consuming (causing) other JARs (to come in)

Chasing down a nasty problem of a missing method in slf4j-api, I needed to know who the culprit was that might be dragging in the wrong version of slf4j-api into the build.

I learned of adding

    -verbose:class the JVM arguments. In my case, this was happening in a JUnit test run. So I added this option by doing (in IntelliJ IDEA) Run → Edit Configurations... → JUnit. There I added, to VM options: this option. Then I ran the test. The option didn't take. I had to reedit the configuration, marking (under JUnit) the test run I was doing with the option. I'm not sure of the exact steps needed to do it correctly without playing with it, but it only took mea second try to get it right.

When I ran, the Run console window displayed huge amounts of data about classpath. I scraped this window, then edited the firs section of the scrape to put each JAR on its own line (splitting the lines on colon). Then, I grep'd the result for "slf4j."

Legend: below you see four sections.

  1. Relevant bits of my classpath showing how I'm trying to enforce version 1.7.25 in pom.xml.
  2. What's really getting loaded, who the culprits are.
  3. The culprit ensuring I get completely the wrong MessageFormatter class.
  4. The error I'm getting when running the test (which was also part of the scrape).
master ~/notes $ fgrep slf4j debug-console.log
[Loaded org.slf4j.LoggerFactory from file:/home/russ/.m2/repository/org/apache/tika/tika-app/1.0/tika-app-1.0.jar]
[Loaded org.slf4j.ILoggerFactory from file:/home/russ/.m2/repository/org/apache/tika/tika-app/1.0/tika-app-1.0.jar]
[Loaded org.slf4j.helpers.SubstituteLoggerFactory from file:/home/russ/.m2/repository/org/apache/tika/tika-app/1.0/tika-app-1.0.jar]
[Loaded org.slf4j.Logger from file:/home/russ/.m2/repository/org/apache/tika/tika-app/1.0/tika-app-1.0.jar]
[Loaded org.slf4j.spi.LoggerFactoryBinder from file:/home/russ/.m2/repository/org/apache/tika/tika-app/1.0/tika-app-1.0.jar]
[Loaded org.slf4j.impl.StaticLoggerBinder from file:/home/russ/.m2/repository/com/etretatlogiciels/medical-filter/195/medical-filter-195.jar]
[Loaded org.slf4j.helpers.MessageFormatter from
java.lang.AssertionError: java.lang.NoSuchMethodError:
Caused by: java.lang.NoSuchMethodError:

This put me on to the fact that Tika 1.0 may be hard-linking slf4j-api. And it would be the wrong (a very old) one too. Also, other lines tell me that, though I tried very hard to impose a version of 1.7.25 on slf4j, that's not what I'm getting. The culprits are, foremost, Tika and also medical-filter.

Setting breakpoints on exceptions

This is the possibility to set, not in any particular place in the code, but on an exception (or exceptions) occurring anywhere any time.

  1. Go to Run (menu), Biew Breakpoints....
  2. Click the green + sign.
  3. Choose Java Exception Breakpoints.
  4. It lists many of your own, custom exceptions, but you can type the name of any particular exception in.
  5. Click OK.
  6. Make sure the new breakpoint listed is enabled by clicking in its box. You can deactivated it without removing simply by uncheking the box.

Unable to save settings. Failed to save settings. Please restart IntelliJ IDE.

Beginning in late 2016 or early 2017, I started to get these messages. I'm still using the community edition because I can't find many reasons to upgrade. I feared that it might be for that reason and I submitted a problem (while it was still possible for an unlicensed/community-version user to do so), but didn't get a very helpful response.

I noticed that many others were complaining about this. There were various theories including ownership of or privileges in the relevant filesystem. Most of the inquiries were from Macintosh users so it wasn't really possible to investigate these claims or their presumed fixes. However, I kept thinking about the problem and once spied workspace.xml anomalies as a suggested cause.

Yesterday, I took a look at workspace.xml. It no longer existed in my projects. (Its home is under the .idea subdirectory.) I surmised that this had become the case somewhere along the way, perhaps originally because I had to use Bazaar for version control, and surely because this file holds settings more for the personal use of each developer than the use of all developers of the project code. So, I had excised it from Bazaar and somewhere along the way, it went missing entirely. Once we finally switched to Git, it remained a problem.

Clearly, I had expected this file to be maintained despite not being under version control. What I think led to its disappearance was, beginning to figure in .bzrignore (.gitignore), when a project is created/cloned anew, the file simply no longer exists. Moreover, as long as it doesn't exist, IDEA will not voluntarily create and begin to use it.

So, I touched this file ($ touch .idea/workspace.xml), then waited to see more of these warnings. I never did. This morning I came in to see that no warnings were issued during the night. To prove that the problem is fixed, it now has plenty in it (going from 0—a new, empty file, to a non-empty file).