# Use of jshell in AP CS A

I recently installed jshell in my IDE for use in demoing concepts in AP CS A. It came at just the right time as it was a powerful way to teach ArrayLists and its associated methods required for the AP CS A Exam. Rather than having to compile, run, change, repeat, I could demo the methods dynamically and instantly show students the results in something closer to real time.

As I look ahead both to exam preparation and to next year's iteration of the course, I am wondering how others have used it and where it has been successful for student learning.

What topics in the AP CS A curriculum are best suited to instruction via jshell?

I have found jshell to be very useful. It can be used to inspect classes quickly and easily. You can import any standard library class. You can also import user-generated classes using the /open command. It can be very helpful in generating test cases. You can save your explorations to a file by entering /save foo.jsh. You can place them in a main method and you have documented the vulnerabilities in the class you created, so if something goes wrong down the road, you know where you don't have to look.

I found it very helpful for teaching about workhorse classes such as the wrapper classes, BigInteger, and ArrayList. It also came in handy for teaching about polymorphism and interfaces.

It will be a valuable asset in the toolbox in my classes.

A word of warning: I have not used jshell in my AP Computer Science A class, but I have used the Interactions Pane to teach about Racket for the last several years, so my answer comes from a slightly different context. However, I do teach AP Computer Science, so I am familiar with the course, if not with jshell.

Regardless, after many attempts at tweaking my instructional approach with the Interactive Environment, I have recently decided that it is probably not a great way to go about instructing the class, and I am currently seeking new solutions.

# The Good

Demos are quick, quick, quick in the interactive environment. You can create things with your students, have them code along, and have them see instantaneous results. It makes the learning easy and fast!

# The Not-So Good

As it turns out, easy and fast is not as helpful as it sounds, because serious effort is the trigger that causes brains to undergo the arduous task of encoding difficult new information. And, true to form, I have found that my students remember very little from these demos.

I have also found that these code-along experiences in an interactive environment provide particular difficulty when students try to take notes. The best I have figured out is that they can copy and paste the entire session into a text file, but there are generally no comments to explain what is happening unless I write them in myself.

# The Takeaway

An interactive environment is great tiny demos, perhaps on the scale of answering a question from a student. Otherwise, I would largely caution against the use of interactive environments as a part of lecture.

I have never used jshell, but here is my experience with the interactive environments included with python and various lisp dialects:

REPLs (Read-eval-print loops) are extremely useful for rapid prototyping and testing. In all cases, having the student sit at the keyboard and play around with the language is best way to learn how it works. Having a REPL can change how software is developed, and I try to encourage students to use one as they are doing homework. Here are some ways that they can make writing code easier:

• Learning new APIs. Need to figure out how to use the Scanner class? Have the students create an instance of it in the REPL, and call nextLine(), nextChar(), and nextInt() with different inputs. This is a huge leap from sticking print statements places to figure out how each of these calls consume items from the input stream.
• Micro testing code snippets. Not sure how to write a for loop that skips every $5^{\text{th}}$ number? Type it in the REPL and see what happens. Can't remember if arrays are zero-indexed? Check it in the REPL. Being able to experiment with code as you write it can provide instant feedback that helps cement language concepts and promote experimentation. This is especially handy in test/quiz situations.

• Debugging. Being able to interact with code in real time makes debugging less of a pain, as you can directly test functions, or bypass them completely.

• I can post a video some of this in action too. It wouldn't be with Java, however, limiting its usefulness for this specific question. – Soupy Apr 2 '18 at 20:23

Let me second BenI.'s post and go a bit further. My own experience with shell environments is that they are frustrating for all but the simplest things. And the APCS course is not about simple things. It is about teaching people to program (in Java) and also a bit about Computer Science in general. While students think a lot about the exam, I'd think, the real goal, as with any AP course, is to give a college level experience in high school.

There are two possible uses of a shell program; in class demos and private self-learning. I think that a shell program is sub-optimal for both.

In a classroom demonstration, it is true that the instructor can quickly set up a simple statement or two and see an immediate result, perhaps in answer to a question. But we, even instructors, do make mistakes, leading to re-doing the illustration (maybe more than once), since it is hard to edit a previous line. This can be boring for students and can take up valuable time. Some demos, in particular, require a certain amount of set-up before you can demo the key idea; populating an array, say.

Moreover, if the demo is quick it is less likely to be internalized by very many students. It leaves no permanent trace, though it can likely be saved. And the line-by-line responses of the shell may actually get in the way of the retention step, since the code that generated the transcript is not all in one place but dispersed throughout it.

The other use is self learning. Here, too, a shell is useful for answering quick questions, but again at the risk of not properly internalizing the result. I think that using a sophisticated IDE is more productive for learning. But not all will serve equally well.

I use Eclipse for nearly everything now. It isn't really an IDE, but, rather, a framework into which you can pour plug-ins to create and modify an IDE. It is usually used for Java programming, but can be used for other languages and even non-programming purposes. But even just as downloaded, it solves the quick-and-dirty demo problem as well as supporting sustained learning.

The reason for this is that it is organized around workspaces. A workspace can contain one or more projects. A project is a collection of files intended to work together, including source files, tests, jar files (for Java libraries, say), design notes, etc.

When working alone or with others you are normally in one workspace developing one project. But you can have another project open at the same instant. The project is called something like DemoCode and contains a class or two that you use for testing ideas quickly. It has a main function and maybe a class or two. In this project you can easily create a method, static or not, and immediately test it by invoking it from main. There are surprisingly few "extra steps" in doing it here rather than from a shell. A click can take you from one project to another, and you can even have files from different projects open simultaneously in the workspace.

Whether done in a shell or in a program framework, you still have to type the code. If you create a method, you need a header, of course, but the name isn't very important since it is a demo. You can also type the instructions directly into main. When it is time for the next demo it is almost trivial to comment-out unneeded statements as Eclipse provides key combinations for commenting a block. You can also set up a common initialization for a collection of fragments. If you want to use a shell to try to understand, say ArrayList, you still need to create the list and populate it. In the IDE this is preserved for the future and can be corrected (edited) if mistakes are made since it is a saved text file.

Moreover, there is no separate compile step in Eclipse, as it normally brings everything up to date on saving a file, which works fine, and instantly, in any project of student scope. Running the program after the first run is via a single mouse click (the first run is a menu selection). It can hardly be easier or quicker.

Moreover (yet again), once you have typed the code into such a demo project it is available to edit in future, say via cut-paste-change, leaving the original in place but helping you with the new. More important, once you have typed the code, and saved it, you have it available for review later to aid your retention. You can also, in fact, copy code from the DemoCode project into the primary project, which is difficult (impossible?) to do from a shell program as the shell responses interfere with the copying.

But, there is another way to use something like Eclipse as it (as others) incorporate the JUnit testing framework in your project. So instead of little code fragments, you can write tests and make assertions about the code. A set of tests can have a common set-up, say defining and populating a List, against which you run several tests, and the individual tests are all run independently of one another. Making assertions about code, I'll suggest, requires a somewhat higher form of understanding than just watching code run.

There are two things supplementing the answering of student questions, whether you use an IDE or a shell. The Oracle Java Docs are online and can be consulted easily, perhaps via a Google Search for some classname or concept.

The other is Stack Exchange itself, especially StackOverflow.

• I use the command line interface to teach programming. You might say, "How old-fashioned?" To this I would say no. Companies who subsequently hire our students have given me very positive feedback on this practice. The command line interface is programmable, extensible, and it's low-overhead. – ncmathsadist Mar 18 '18 at 21:45
• I'd like to point out that many of these objections can be fixed with a text editor/IDE that closely integrates with an interactive environment. For example, Emacs allows you to evaluate code directly in the text file you are editing using a variety of languages. These include Python, Scheme, Clojure, Common Lisp, Haskell, and many others. – Soupy Apr 2 '18 at 20:22