CSE 373, Summer 2019: IntelliJ basics

Table of Contents

  1. Importing projects into IntelliJ

  2. Running code in IntelliJ

Importing projects into IntelliJ

Locating your GitLab repository

In this class, the remote repositories on GitLab will be created for you beforehand with the starting code. When we create your repo, GitLab should send you an email with a link to the repo; you should also be able to find your repository by navigating to the GitLab link in the navigation bar of this site, which will take you to the GitLab group that contains all your repositories for the quarter (along with public repositories containing the starter code, which you may ignore).

Obtaining the repository

Once you've found your repo on GitLab, you'll need to clone that remote repo to get a copy on your own machine. Anyone already familiar with Git may use Git's command line interface or any other UI, but we'll use IntelliJ's Git UI in this guide. (If you opt to use another method, note that the course staff may not be able to debug any issues you encounter.)

  1. If IntelliJ is open on the welcome screen, you can just click "Check out from Version Control" option.

    Otherwise, if a project is already open, you can click "VCS" > "Checkout from Version Control" > "Git".

  2. Afterwards, a window will open where you should enter the URL of your repository from GitLab and a directory to save the cloned repo into.

    Note that this URL is NOT just the URL of the webpage you visit; instead, get this URL by navigating to the home page of your repository on GitLab ("Project" > "Details"), then clicking the copy button on the right side of the text box labelled "SSH". The URL should look somewhat like the one in the image above. (If the text box is labelled "HTTPS" instead, you'll need to click the dropdown to select "SSH" before copying the URL.)

    (If you do not have a repo: for project 0, you can clone this public repo. You will not be able to push (submit) until you have your own personal repo, however. If you're enrolled in the class but do not have a repo made for you, you should fill out this form to notify us.)

  3. After the previous step, IntelliJ should have downloaded the repo onto your machine. If you've cloned the repo correctly, IntelliJ should also be able to tell that the code you just cloned contains a project that it can import, so it should pop up with another window asking whether you want to open it now.

    It should be safe to choose "Yes" here to import and open the project. (More details on exceptions later.)

  4. Make sure that "Gradle" is selected on the next screen, then click "Next"

  5. Make sure that "Use auto-import" is checked and that "Use gradle 'wrapper' task configuration" is selected, then click "Finish".

Afterwards, IntelliJ will import and open the project. Note that it will also attempt to download any other libraries needed for the project, so make sure you remain connected to the internet while it finishes.

What if my project doesn't import properly?

The first time that you load a Gradle project in IntelliJ, IntelliJ may give you an error message about "Failed to notify progress listener." In this case, you should be able to click the "refresh" button at the top left of the "Build" tool window that popped up to tell IntelliJ to try importing again, which will usually fix that error.

Other times, in partner projects, your partner may accidentally commit their IDE configuration files. These files sometimes include absolute file paths which, when transferred between machines, will cause your IDE configuration to break. There are also other cases where the initial import simply doesn't work, for some reason or another.

In these cases, you should re-import the project:

  1. If you still have the project open, close it by clicking "File" > "Close Project". This should bring you back to the welcome screen, from where you should click "Import Project":

    Alternatively, if you had another project open instead, simply click "File" > "New" > "Project from Existing Sources...":

  2. Navigate to and select the folder containing the code, and then click "OK". There should be a build.gradle file directly inside that folder. (You may also select the build.gradle file instead if using the folder doesn't work.)

  3. From here, continue importing the project as shown starting in steps 4 and 5 above.

What is a 'gradle project'?

When working on larger projects, programmers tend to face a few different problems:

  1. How do you keep track of what 3rd party libraries the project needs installed?
  2. Each IDE stores its project config in a slightly different way. How can you make sure your project can run on all kinds of different IDEs, including ones you've never heard of, with minimal fuss?
  3. Sometimes, building our project and producing a final JAR we can give to our users can require running multiple instructions/performing several complex steps. Instead of having to do that manually, can we just write a script that does this all automatically for us?

It turns out that we can use the same tool to answer all of these questions: a build manager. Basically, what happens is that we record all of the libraries we need, all project configuration, and all build instructions inside of a special file our build manager understands.

Conveniently, it also turns out that all (modern) IDEs have great support for a wide variety of popular build managers: they can read the special file and automatically convert all of those instructions into their IDE-specific configuration.

In our case, we're using a build manager called "gradle". Try opening up build.gradle inside of your project. If you skim through it, you can see that the file configures a variety of things and specifies a handful of 3rd party libraries we want to install and use. (We've commented this file fairly heavily in case you're curious).

Gradle isn't the only Java build manager—other popular build managers include Ant, Maven, and Ivy.

If you start working with other programming languages, you'll learn that they all also have their own build managers and conventions for managing large projects. However, at a high level, they all work in the same way: you specify the libraries you need and your build instructions in some file(s), and run some sort of build tool to manage everything for you.

Running code in IntelliJ

High-level overview

After you've imported code as a new project, IntelliJ will bring you to its editor view. It will probably have a "Build" tool window open at the bottom showing you its progress as it sets up the Gradle project:

In the center of the screen is the main editor. Currently, no files are open, so IntelliJ just shows some useful(ish) keyboard shortcuts.

Notice that there is a toolbar on every side of the window (we won't count the menu bar at the top and the status bar at the very bottom as toolbars). The top toolbar has some buttons for running code and using Git (and some other buttons), but the other three toolbars just contain buttons for showing or hiding tool windows.

Feel free to play around with these tool windows. IntelliJ lets you show or hide tool windows by clicking on their button in the toolbars, and also lets you resize them normally. You cna also drag the tool buttons around to rearrange the tool windows. There are other display options you can find by right-clicking the tool buttons or clicking the gear icon on the upper-right corner of a shown tool window. You can click the "Help" item in that menu to open the official documentation for more details.

If you accidentally close a tool window, you can reopen it by going through "View" > "Tool Windows", which will list out all the tool windows. You can also reset all tool windows by clicking "Window" > "Restore Default Layout".

It's also possible that your tool window bars become hidden; in this case, simply click "View" > "Tool Window Bars" to restore them. (Other elements of the IDE can be hidden or shown in the same way.

As mentioned already, IntelliJ will automatically open the "Build" tool window upon importing a Gradle project/module; feel free to minimize it now, since it's usually not very useful.

Now take a look at the the "Project" tool window on the left. This tool window lists out all the modules in your project, and all the files in those modules, as well as external libraries used (all of which should now be automatically downloaded by Gradle, with the exception of the JDK itself). You can expand folders by double clicking its row in the tool window or by clicking the triangle icon to the left of the folder icon.

Running Checkstyle

Expand the src/main/java/misc/sanity folder, then double click the SanityCheck file to open it in the editor.

If you have Checkstyle set up properly, there should be 5 Checkstyle errors in this file, each of which should be marked as an error (i.e., there should be red squiggly underlines). You don't need to count them up; instead, just open the "Checkstyle" tool window. By default, there won't be anything in it, but if you click the green play-button-shaped triangle on its left side, it will display all Checkstyle errors in the currently-active file.

Below that button are two more buttons for showing checkstyle for all files in the current module and for all files in all modules respectively. Both should do the same thing right now, since you probably only have one module in your project. Click either button now.

You can see now that some errors in MapProblems.java, LinkedIntListProblems.java, and IntTreeProblems.java also get picked up.

Running code

None of these style errors should affect our ability to run code, however. Right-click the SanityCheck file in the "Project" tool window, then click "Run 'SanityCheck.main()''" to run it.

If you have your JDK settings properly working, you should get output like this:

Also note that the "Add Configuration..." dropdown that was previously in the top toolbar now says "SanityCheck" instead, and that the green play button to the right of it is now enabled. If we click that, IntelliJ will run SanityCheck.main() again. That dropdown should automatically select the file that was run last—IntelliJ will automatically save data about which files you run as "run configurations."

You can click the dropdown to select which run configuration the play button and bug button to the right will use. (There won't be any other configurations right now, though.) The play button will run that configuration normally, just like what we just did, whereas the bug button will run it in debug mode, which we'll talk about on a different page.

Open MapProblems.java from the problems package source code. src/main/java is the root folder for Java packages in our assignments, or at least for the source code.

MapProblems.java is a Java class with some method stubs (they're not implemented yet); such a class with only normal methods cannot be run on its own. (This will be the case with all the data structure classes we implement in this course.) However, if we want to make sure our code is working properly, we'll need to run it somehow, and it's not always feasible to check that a small part of or code works properly by running the entire program.

This is where tests come in: tests are an easy way of running just a small portion of code. Often, tests will focus on a single method at a time.

Running tests

Find the TestMapProblems.java test file from the datastructures package in the "Project" tool window (tests have a different root folder: src/test/java), then run it by right clicking it in the tool window, and then clicking "Run 'TestMapProblems'".

The "Run" tool window should pop up. (Also, the selected run configuration in the top toolbar should change to "TestMapProblems".)

For tests, this window is split into two panes: the left lists out the names of all tests that were run, and the right is the console output and other details about the test. By default, the name of the test file is selected, and the right pane displays output from all tests, but you can click a test name to show output for only that test.

Note: by default, IntelliJ will hide the passing tests. You can change this by looking in the top left of the tool window and clicking a button that will let you 'Show Passed' tests.

Currently, MapProblems.java isn't implemented yet, so all the tests are failing, as indicated by the red exclamation mark icon next to their names. Double-click a test name to open the test file at the failing line.

In the next part of the assignment, we'll start getting the tests to pass as we implement these methods. You don't have to fully understand all the tests for Project 0, but TestMapProblems.java and TestLinkedIntListProblems.java are good test files to start to browse. In part d of Project 0, you'll get some practice by writing some of your own tests.