Overview:

In my opinion, 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 7 or Java 6...) 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", 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 new module system (project Jigsaw) is unlikely to impact your curriculum in the near future, perhaps with one exception: if you want to be super-precise when explaining how Java works on a high level, it might be worth mentioning Java 9 will include an extra "linking" stage which is necessary when using multiple modules.
• Looking forward a few years, project Jigsaw (which, among other things, lets you bundle together a subset of the JRE) could mean that Java could see more usage in robotics and embedded systems, which may in turn increase the number of educational resources available in that area. This is just a hypothesis, though.
• Interfaces in Java may now contain private methods. This may slightly affect how you teach ADTs, Java abstract classes, Java interfaces, and so forth.
• 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 actually planning on 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. It's possible this'll be resolved by September, though.

• Project Jigsaw, the new module system: while this change is exciting from a technical point of view, my opinion is that it shouldn't really change anything in a typical CS1 and CS2 curriculum. 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 necessary, 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 computer science 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 (dependency resolution is often, in fact, NP-complete), 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.

  Depending on how precise you want to be, you may also need to adjust your explanations of how the Java works (on a high level) to your student -- Java 9 introduces a new "linking" stage which is necessary when using multiple modules.

  If we look forward beyond the immediate future, another thing that you might want to watch out for (not in the immediate future, but perhaps several years down the line) is for educational resources and various libraries that allow you to use Java on embedded systems. You can, of course, already do this (Raspberry Pis support arbitrary programming languages, FIRST Robotics supports Java, etc), but one of the benefits of Project Jigsaw is that it's now possible to bundle a subset of the JRE into an application.

  This was previously not possible, and I can see people leveraging this to try and make Java run on platforms it was previously unable to run (or making it run more efficiently on existing platforms). I think it'll take some time before we see meaningful results in this area (if at all), but perhaps something worth keeping an eye on.

• Internationalization changes: Java 9 now supports Unicode 8.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 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 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. 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. 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 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", 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, and reified generics appears to be have been deferred to Java 10. 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.

I believe there were also some plans for adding new APIs for JSON manipulation, and money/currency stuff, but those also seem to have been deferred.

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.