# Overview:

It is my opinion that Java 9 is mostly an incremental improvement over Java 8, particularly from a pedagogical point of view. I imagine a "Java 9 centered curriculum" would look more or less identical to a Java 8 (or Java 6 or Java 7...) centered curriculum.

There appear to be no major or breaking changes to the language itself, so I'd consider switching over a few months after release just to stay on top of things, once the various 3rd party tools and libraries you plan on using have fixed any bugs and kinks the switchover exposed.

A quick summary:

- Java comes bundled with a REPL called "jshell". This is probably the most relevant and useful change from a pedagogical point of view.
- Java 9 supports Unicode 8.0; Java 8 supported 6.2. This is potentially useful for teachers and students from non-English speaking countries. Unicode 8 also supports a wider range of emoji, which your students may or may not care about.
- Some of the new APIs might make it easier for you to write tooling and infrastructure -- in particular, the external processes API and the stack-walking API.
- Java applets are deprecated in favor of "[Java web start](https://docs.oracle.com/javase/9/deploy/migrating-java-applets-jnlp.htm#JSDPG-GUID-1F95EBB3-D5CB-434A-B069-2261900738F5)", whatever that is. This may or may not be relevant to your course.
- Strings are no longer implemented using an array of chars and are now stored in a more compact form. This will have no visible impact (apart from improving performance), but it does mean saying "Strings are implemented using an array of chars" is technically a lie (again...).
- The other changes seem mostly minor and irrelevant, for the purposes of an intro course. I suppose if you really wanted to, you could use some of the new changes as hooks into some interesting advanced topics (the new modules system hooks into graph algorithms and NP-completeness, and the new reactive interfaces sort of hooks into asynchronous programming), but these topics don't seem immediately appropriate for an intro course and probably ought to be presented differently if you were planning on actually covering them.

---

# Details:

Here is the document describing the full list of planned features in Java 9: https://docs.oracle.com/javase/9/whatsnew/toc.htm

If you skim through, the majority of the features should have no real impact for both the average Java programmer and for students -- they add additional options for tweaking the compilation and deployment process, and some API refinements.

There are, however, a few features worth talking about in more detail:

- **jshell, the new REPL tool**: this is probably the most useful change, pedagogically speaking. There were a few Java REPLs floating around before, but none of them were very polished or easily usable, from what I understand -- most of them were built into IDEs instead of being available as a standalone tool.

   Since this is only a tool, and not an actual change to Java, this would effect only how you present your curriculum, and not the curriculum itself.

   One potential blocker to using this in a classroom setting is that jshell, to the best of my understanding, is a command-line based tool, which isn't immediately accessible to beginners. It'll probably take a little bit of time before the tool is nicely bundled and packaged up in a GUI that students can easily use.

- **Project Jigsaw, the new module system**: while this change is exciting from a technical point of view, I don't think it should really change anything in a typical CS1 and CS2 curriculum, in my opinion. Your students will likely have their hands full trying to learn how to write programs that are only one or two files long at most -- once they're ready to start working on large projects where modules are actually necessarily, they'd likely be technologically mature enough to understand how the module system works relatively quickly.

    I think focusing on the new module system any earlier then that would be a mistake -- I feel fairly strongly that CS1 and CS2 should be focusing on teaching the core fundamentals of programming and problem-solving rather then the quirks and foibles of any one particular programming language. 

    If you do want to incorporate modules into your curriculum, the best place to do it would probably be after students are comfortable with objects and packages: you can introduce this change as an additional tool for encapsulation that lets "encapsulate" many packages, in the same way packages let you encapsulate many objects. Alternatively, you could introduce them as a refinement over standard jars.

    A third place you might introduce or revisit modules is when talking about graphs -- dependency management is an application of graphs and resolving dependencies can [notoriously difficult in practice](https://blog.codefx.org/java/jar-hell/) (dependency resolution is often, in fact, [NP-complete](https://research.swtch.com/version-sat)), and it might be interesting to explore different ways programming languages attempt to solve this problem from a software engineering perspective. This is probably too much and too abstract for intro courses, though.

    In any case, I imagine the main thing to watch out for is tooling and infrastructure changes, and various 3rd party tools and libraries adapt to these changes.

- **Internationalization changes**: Java 9 now supports [Unicode 8.0](http://www.unicode.org/versions/Unicode8.0.0/); Java 8 supported Unicode 6.2. This change adds approximately 10,555 new characters, 29 scripts, and 42 blocks, which I imagine would be useful if you're teaching programming in a non-English speaking country.

    Somewhat more relevantly, Unicode 8.0 supports a wider range of emoji, which seems like the sort of thing that could leverage to make an entertaining set of lessons and homework assignment, especially for students at the K-12 level.

    It's worth noting the latest version of the Unicode standard is actually 10.0, so Java 9 still isn't fully caught up.

- **API changes**: most of the API changes are minor. The streams API gained three or four more utility methods, the collections library has some new [convenience factory methods](http://openjdk.java.net/jeps/269) which might be handy, the process API seems to be much improved (though your students were unlikely to be using that anyways). I suppose you, the instructor, could use the new process API to write better tooling and infrastructure.

    One thing to perhaps keep an eye on is the [reactive streams](http://openjdk.java.net/jeps/266) interfaces. It appears that the plan is for various 3rd party libraries to implement libraries based on these interfaces, helping increase interoperability. This, by itself, doesn't really seem worth teaching, but programming languages _do_ seem to be adding enhanced support for asynchronous programming as of late. (e.g. Python has async-await keywords now, Node.js grew popular a few years ago in part because it had a good story for asynchronous programming at the time...). The takeaway seems to be that async programming is an increasingly popular paradigm -- in that case, it might be worth teaching it to your students. 

    That said, I don't know if Java is the most appropriate language to do this in, or if this is an appropriate topic for intro courses. If you're going to do this, if at all, it should be probably relatively late, once you're convinced your students are ready to learn additional paradigms beyond imperative and OOP. You could maybe introduce this earlier if you cover web programming if you really want, since asynchronicity comes up everywhere in that subdomain, but this seems sort of moot, if you're teaching Java. 

    Another thing to perhaps keep an eye on is the new [Stack-walking API](http://openjdk.java.net/jeps/259). You (the instructor) could perhaps leverage this API to provide students with better tooling to help them debug their code or to allow you to perform more fine-grained analysis when writing automatic grading scripts.

- **Language changes**: the language changes also seem to be [relatively minor](https://docs.oracle.com/javase/9/whatsnew/toc.htm#JSNEW-GUID-825576B5-203C-4C8D-85E5-FFDA4CA0B346). The main thing that might be worth mentioning is that private interface methods are now allowed, and that using underscore as an identifier is deprecated.

    Strings are also no longer implemented using a char array -- rather, they're implemented using a [byte array with an encoding field](http://openjdk.java.net/jeps/254) to improve on space efficiency and possibly performance. This, of course, makes absolutely no difference to the end-user, since the API is completely unchanged, but it does mean saying "Strings are implemented as an array of chars" is technically a lie, again. This statement is now completely true only in Java 7 and 8.

- **Applets are deprecated**: Java web applets are deprecated in favor of "[Java web start](https://docs.oracle.com/javase/9/deploy/migrating-java-applets-jnlp.htm#JSDPG-GUID-1F95EBB3-D5CB-434A-B069-2261900738F5)", whatever that is. I imagine most people aren't using web applets anymore, but if you are, upcoming versions of Java might be breaking changes.

And finally, I think it's also worth briefly mentioning changes that do *not* appear to be a part of Java 9. From what I can tell, value generics (e.g. `List<int>`), value types, reified generics appears to be have been deferred to Java 10 (along with the proposed new APIs for JSON and currency/money manipulation). These proposed changes to how Java's generics function, had they been included in Java 9,  *would* have required some changes to a Java-based curriculum, but alas, not yet, it seems.

It's unclear if these proposed changes will land by Java 10, but if so, that version of Java would be the one to keep an eye on.