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.