As best as I can tell, Java 9 is mostly an incremental improvement over Java 8, particularly from a pedagogical point of view.

More specifically, 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.

- **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).

    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.

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.

---

tl;dr: a "Java 9 centered curriculum" would likely look more or less identical to a Java 8 (or Java 6 or Java 7...) centered curriculum.

I would consider switching a few months after the release, once the various 3rd party tools and libraries you plan on using have fixed any bugs and kinks the switchover exposed, but only because there's no real reason not to, and because jshell looks pretty handy and would presumably make it easier for your students to experiment when writing code.

There are also some changes to Java that provide nice hooks into some interesting advanced topics (graphs algos + NP-completeness, and asych programming), but these topics don't seem immediately appropriate for an intro course.