General overview on updating to Java:
First, a general observation about updating to Java. Previous versions of Java used to be released about once two years or so. As of 2017, Java has switched to a bi-yearly release schedule: there will be a new version of Java released every March and September. Each release is also guaranteed to receive two updates (one update per each quarter of the year) before they are no longer supported.
The plan is to also to have a long-term support release (LTS release) once every three years. Java 8 currently is special-cased to be supported until 2025, Java 11 (which will be released in September 2011) will be the first regular LTS release. Java 11 will be supported until at least 2021.
What this all means is that you should be cautious about updating to Java 9 or 10. They may have useful features, but they also have a shelf-life of only 6 months. Java, in theory, is designed to always backwards-compatible, but there are always going to be bugs and breaking changes, so it will likely be less of a hassle if you just wait until whatever the next LTS is going to be.
In particular, you should definitely test your assignments and course infrastructure to make sure there are no kinks or bugs anywhere. The major players ought to be reasonably up-to-date, but if you require the students to use specific plugins or libraries, there may be unexpected breakages. (I found this out the hard way).
General overview on updating to Java 9 and 10:
In my opinion, Java 9 and 10 are mostly incremental improvements over Java 8, particularly from a pedagogical point of view. Specifically, Java 9 does not introduce any major or breaking changes to the language itself. Java 10 added support for variable type inference, which is a nice convenience but not too big of a change (for now?).
Here's a quick summary of the changes I think I worth highlighting in particular:
Details: Changes in Java 9
Here is the document describing the full list of new 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.
If you previously needed to teach students how to use both abstract classes and interfaces (e.g. if you want them to extend some code you provided for an assignment), this change may be enough to let you convert over to just using interfaces, possibly letting you avoid needing to talk about abstract classes entirely.
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.
Details: Changes in Java 10
The changes landed in Java 10 are comparatively smaller (which makes sense -- Java 9 was released about two years after Java 8; Java 10 was released about 6 months after Java 9). You can find a full list of changes at the following two documents:
Some changes worth talking about:
Java now has variable type inference. That is, it's now legal to do:
var foo = new MyLongObjectType();
This is treated as being exactly equivalent to doing:
MyLongObjectType foo = new MyLongObjectType();
This is a nice feature, but (IMO) is really only a minor quality-of-life improvement especially since it's unlikely you'll have excessively long class names in a pedagogical setting.
This feature also interacts oddly with the diamond operator. For example, the following code:
var foo = new ArrayList<>();
...is treated equivalently to doing:
ArrayList<Object> foo = new ArrayList<>();
This is unfortunate for two reasons: (a) the inference engine is not smart enough to infer the correct inner type based on context (b) the inference engine will always default to inferring the specific type instead of the interface type.
For these reasons, I think variable type inference is (currently) more trouble then it's worth to teach.
This may change in the future though, if Java were to one day add anonymous types a la C# -- type inference plus ad-hoc anonymous types is a potent combination that you can leverage to write code in a much more fluent way then Java currently allows. (No more having to create a bunch of one-off classes everywhere!)
Java 10 (and Java 9) added a variety of convenience methods revolving around creating and using various collection types in cleaner ways. The two releases taken together have added the following methods:
List.of(a, b, c, ...): creates an immutable listSet.of(a, b, c, ...): creates an immutable setMap.of(k1, v1, k2, v2, ...): creates an immutable map (up to a fixed number of key-value pairs)Map.of(entry(k1, v1), entry(k2, v2), ...): creates an immutable map containing an arbitrary number of key-value pairs. Requires you to statically import the Map.Entry.entry method.List.copyOf(list), Set.copyOf(set), and Map.copyOf(map): creates an immutable (shallow) copy of the underlying data structure. If the data structure is already an immutable list/set/map, it's returned unchanged (no copy is made).Optional.getOrThrow(): equivalent to Optional.get(), but is now the preferred name.
These are all minor changes, but they might serve as a good opportunity to have a discussion about the current trend towards preferring immutable data structures/an immutable style of programming.
A memory leak related to foreach loops are now fixed -- the generated bytecode now explicitly sets the implicit iterator to null, which can help prevent memory leaks in some cases. This may potentially affect assignments where students need to manipulate large amounts of memory (and is also an interesting case study of how you can find bugs in even seemingly well-used and well-tested code).
The javadocs tool has seem some minor improvements -- there's a @summary tag now; there's an --overridden-methods=VALUE flag you can use to group documentation about inherited methods with no spec change together. More details.
Java 10 added a few extra features to make using and configuring Java on Docker containers nicer, which may make instrumenting and sandboxing student code slightly easier. More details
Java 10 removed several methods from the standard library -- however, it looks like they were all obscure and relatively unused methods, so it seems this is unlikely to be a breaking change for anybody. Full list.
And finally, I think it's also worth briefly mentioning changes that do not appear to be a part of Java 9 and 10. 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 11, but if so, that version of Java would be the one to keep an eye on.
