If you’ve been around me for any amount of time, I’ve probably pushed DrJava on you at some point. Finally, I’ve decided to articulate my reasoning in an article.
What is DrJava?
For those of you that might not know, DrJava is an IDE built by Rice University for students who want to learn Java. Funny story: I applied to Rice for grad school, but I didn’t get in despite my interest in their software.
Anyway, DrJava has a lot of what you would expect out of an IDE: an editor with syntax highlighting as well as a whole host of features like integrated JUnit testing, code coverage, and Javadoc API generation.
In addition, there are a handful of features that DrJava has and doesn’t have which sets it apart as an excellent tool for educators. For instance, DrJava doesn’t have any form of autocomplete. Even better, DrJava has a console—the interactions pane—which you can use to run lines of code as if Java were interpreted.
That said, it’s likely you’ve never heard of it because the industry tends to lean towards Eclipse, IntelliJ, and NetBeans. All these tools are great, but DrJava is my go-to (no pun intended) IDE for Java education. Naturally, the question is “why?”
DrJava Features
As mentioned already, there are two major features of DrJava that I love as an educator: the interactions pane and the lack of autocomplete. In addition, there are a handful of features for more advanced students. Let’s talk about them.
The Interactions Pane
By far, the absolute best feature of DrJava is the interactions pane. This is a feature that I have yet to see implemented in another IDE (though, I recently found out it comes standard with the JDK under jshell), and I think it’s brilliant. Basically, it allows you to treat Java like it were an interpreted language. In other words, you can run commands line-by-line without having to spin up a class with a main method. It’s glorious.
Just to put things into perspective, here’s the code you’d have to write for HelloWorld in a normal IDE:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
And, here’s the code in the interactions pane:
System.out.println("Hello, World!");
To change the message with a traditional editor, you’d have to edit the source code, recompile, and run the solution again. In the interactions pane, it’s as easy as pressing the up arrow, changing the message, and hitting enter:
Typically, I like to use the interactions pane to teach Java without actually introducing classes. In other words, I like to talk variables, types, methods, and control flow without having to talk too much about public vs. private, static vs. instance, etc. The nature of being able to quickly prototype code is wonderful.
As an added benefit, students are able to make a lot of mistakes without all that frustration of the compile/run loop. Try a line, watch it break, then try another line. It’s that convenient. Also, it gets students used to using the command line. Being able to hit the up arrow and slightly modify a line of code before running it again is really amazing.
Overall, I think the interactions pane is reason enough to use DrJava over any other bulky IDE. Students just don’t need all the bells and whistles when they’re first learning to code.
The Lack of Autocomplete
While the interactions pane alone is a great feature, I love the fact that DrJava has no autocomplete. In other words, all code has to be typed from memory. Normally, I wouldn’t bother wasting time committing code to memory, but it’s critical for beginners to actually write their own code. Otherwise, they’ll never learn the syntax.
As an added bonus, if you give out exams where students have to hand write code (I hate these by the way), your students will thank you for forcing them to learn the syntax.
That said, everyone knows how verbose Java is, so typing code by hand can be a long and painful process in DrJava. As a result, I don’t recommend the tool for anyone who knows what they’re doing. In other words, only use DrJava if you’re just trying to learn the syntax.
No Real-time Compilation
When you use editors like Eclipse, you’ll notice that your code will compile on its own. After all, errors will randomly appear throughout your code with a squiggly red underline. Hover over that error, and you’ll see exactly what’s wrong.
With DrJava, you don’t get the benefit of a red underline. Instead, you have to actually read error messages when you compile your code. Personally, I’m not that much of a masochist myself, but I do think it’s critical for students to figure things out on their own. Otherwise, they’ll just chase red lines around the screen until everything “works.”
Other Features
In addition to everything mentioned already, DrJava has a few more nice features. For instance, JUnit is built into the tool, so students can write tests without having to deal with dependency issues. In fact, I like to use this as an opportunity to teach testing as soon as I teach methods.
On top of JUnit testing, DrJava has builtin code coverage. If you write JUnit tests, you can check how much of your code is covered by your tests with a click of a button. Together, these three features get students rapidly up to speed with a handful of good software practices.
Likewise, DrJava is built with JavaDoc in mind. If you write JavaDoc comments, DrJava will allow you to easily render your own documentation at the click of a button. I can personally say this is a big “wow” moment for students. There’s nothing quite like watching your comments come to life as a web page.
Finally, DrJava has a small readability feature which automatically indents code at the current line when tab is pressed. While editors like Eclipse usually have builtin formatters which activate when code is saved, these features can be difficult to setup. Meanwhile, the automatic indentation in DrJava can be activated by selecting all code and hitting tab. Boom, proper indentation.
An Educator’s Perspective
Personally, I’ve been urging my students to use DrJava ever since I started teaching. Naturally, I was exposed to the tool when I started coding, and I think a lot of beginners could benefit from it as well. Unfortunately, most courses today throw students right off the deep end with Eclipse, but what can you do?
As an educator, if I can’t convert my students to DrJava, I at least expose them to it in the classroom. I’m practically notorious for answering questions to the tune of “well, let’s try it” before promptly dumping some code in the interactions pane of DrJava. It’s really a wonderful tool for anyone teaching Java.
For anyone who is stuck working with Eclipse, there’s actually a DrJava plugin for Eclipse. As far as I can tell, it still works—at least as of Eclipse 2019-03. It adds the interactions pane right into Eclipse, so students can at least start testing code snippets.
At any rate, I hope I opened your eyes up to a new tool today. If not, let me know if there’s anything you prefer to use in the classroom. If you’re a student, how did you learn Java? I’m always interested in finding new ways to teach the same material.
While I’ve got you here, check out some of these other teaching-related articles:
As always, if you’re enjoying this content, consider becoming a member. Or, at the very least, subscribe to my weekly newsletter! That way, you’ll never miss another article. Until next time!
The post Why I Urge My Students to Use DrJava appeared first on The Renegade Coder.
Top comments (2)
Because we're talking about absolute beginners here.
You don't just hand someone the entire tool set and expect them to figure it out. You give them a starter set and add features as the students grow comfortable. To me, using an IDE like Eclipse is like handing an aspiring mechanic an expert's tool chest. They're going to spend so much time tripping over functionality that it actually hinders the learning process. Beginners are at an impressionable stage in their development, so fighting with an IDE can actually turn students away.
In addition, keeping things simple reduces maintenance issues for the instructor. For instance, compiling and running code in DrJava just works without configuration. Plus, with the interactions pane right next to the code editor, students can experiment with code without having to go through a compile/run loop.
Ultimately, there's nothing wrong with using Eclipse or any other IDE for that matter. This is just a choice I made from practical experience.
For reference, DrJava has Java 7/8 built in.
I feel like the article outlines that decision pretty well. DrJava is more than a REPL. It’s an educational IDE plus a REPL.