<p>While this question is specifically about Java, it is a subset of the larger question as to what version of software should be used for teaching. This involves not only languages (Java/C/C++/Python), but operating systems (Windows/Linux/MacOS), and compilers (gnu/MSstudio/clang).</p>

<p>There are good reasons for any of the choices. What the student is concerned with is how their program will be tested. Therefore, it is important to specify how testing is performed. CSU's blanket statement is that testing is performed on the lab computers, which the students may access both in person and remotely. They are expected to test their program on lab computers, no matter where they actually developed the code. Our system admin provides identical environments on all lab computers.</p>

<p>At least one university provided a VM image to the students to guarantee a consistent environment. At a minimum, one should specify which version of a language (e.g. Java8), will be used in testing.</p>

CC BY-SA 3.0
2018-03-26T16:12:08.200Z
2018-03-26T16:12:08.200Z
Fritz Sieker
<h1>General overview on updating to Java:</h1>

<p>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 <a href="https://www.infoq.com/news/2017/09/Java6Month" rel="nofollow noreferrer">bi-yearly release schedule</a>: 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.</p>

<p>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.</p>

<p>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.</p>

<p>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).</p>

<h1>General overview on updating to Java 9 and 10:</h1>

<p>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?).</p>

<p>Here's a quick summary of the changes I think I worth highlighting in particular:</p>

<ul>
<li><p><strong>Language changes and major new features:</strong></p>

<ul>
<li>Java 9 introduced a REPL called "jshell". This is probably the most relevant and useful change from a pedagogical point of view.</li>
<li><p>Java 10 introduced variable type inference -- e.g. if you type <code>var a = new StringBuilder()</code>, the variable <code>a</code> will be inferred to be of type StringBuilder. </p>

<p>Although this feature may be worth mentioning, I think it's also safe to largely ignore -- see the section below for more discussion. </p></li>
<li><p>Java 9 introduced a new module system (Project Jigsaw). Although this this is a potentially major change to Java/the Java ecosystem, it's unlikely to impact your curriculum in the near future and is probably not something worth teaching (see below). </p>

<p>At most, if you want to be super-precise when explaining how Java works, it might be worth mentioning Java now includes an extra "linking" stage which is necessary when using multiple modules.</p>

<p>Looking forward a few years, project Jigsaw (which, among other things, lets you bundle together a <em>subset</em> 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.</p></li>
</ul></li>
<li><p><strong>Minor new features and quality-of-life improvements:</strong></p>

<ul>
<li>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. Java 10 followed this up with <a href="http://openjdk.java.net/jeps/314" rel="nofollow noreferrer">some additional minor improvements</a> also related to internationalization.</li>
<li>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.</li>
<li><p>Interfaces in Java may now contain private methods. This may slightly affect how you teach ADTs, Java abstract classes, Java interfaces, and so forth.</p>

<p>You may also be able to use this new feature to actually help <em>minimize</em> the amount of time you spend having to teach Java. That is, Java currently has two mechanisms for encoding the notion of an abstract data type: interfaces, and abstract classes. Depending on the kinds of assignments you give out, you may have needed to explain how to use both. Now that interfaces are slightly more powerful, it's possible you may be able to adjust your assignments and skip having to explain abstract classes altogether.</p></li>
<li><p>Java 9 and 10 together introduce a variety of convenience methods for more conveniently creating and copying collection types -- e.g. <code>List.of(a, b, c, ...)</code>, which creates an immutable list, and <code>List.copyOf(list)</code>, which creates an (immutable) copy of the given list.</p></li>
</ul></li>
<li><p><strong>Other changes:</strong></p>

<ul>
<li>Java applets are deprecated in favor of "<a href="https://docs.oracle.com/javase/9/deploy/migrating-java-applets-jnlp.htm#JSDPG-GUID-1F95EBB3-D5CB-434A-B069-2261900738F5" rel="nofollow noreferrer">Java web start</a>", whatever that is. This may or may not be relevant to your course.</li>
<li>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...).</li>
<li>The way foreach loops were translated to bytecode was actually <a href="https://bugs.java.com/view_bug.do?bug_id=JDK-8175883" rel="nofollow noreferrer">slightly buggy</a> and could prevent garbage collection in some cases -- this issue was fixed in Java 10. This is unlikely to affect you and your students, perhaps unless you are deliberately asking them to work on assignments that ask them to manipulate large amounts of data.</li>
<li>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. <a href="http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html#JDK-8146115" rel="nofollow noreferrer">More details</a></li>
</ul></li>
</ul>

<hr>

<h1>Details: Changes in Java 9</h1>

<p>Here is the document describing the full list of new features in Java 9: <a href="https://docs.oracle.com/javase/9/whatsnew/toc.htm" rel="nofollow noreferrer">https://docs.oracle.com/javase/9/whatsnew/toc.htm</a></p>

<p>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.</p>

<p>There are, however, a few features worth talking about in more detail:</p>

<ul>
<li><p><strong>jshell, the new REPL tool</strong>: 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.</p>

<p>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.</p>

<p>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.</p></li>
<li><p><strong>Project Jigsaw, the new module system</strong>: 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.</p>

<p>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. </p>

<p>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.</p>

<p>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 <a href="https://blog.codefx.org/java/jar-hell/" rel="nofollow noreferrer">notoriously difficult in practice</a> (dependency resolution is often, in fact, <a href="https://research.swtch.com/version-sat" rel="nofollow noreferrer">NP-complete</a>), 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.</p>

<p>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.</p>

<p>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. </p>

<p>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 <em>subset</em> of the JRE into an application.</p>

<p>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.</p></li>
<li><p><strong>Internationalization changes</strong>: Java 9 now supports <a href="http://www.unicode.org/versions/Unicode8.0.0/" rel="nofollow noreferrer">Unicode 8.0</a>; 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.</p>

<p>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.</p>

<p>It's worth noting the latest version of the Unicode standard is actually 10.0, so Java 9 still isn't fully caught up.</p></li>
<li><p><strong>API changes</strong>: most of the API changes are minor. The streams API gained three or four more utility methods, the collections library has some new <a href="http://openjdk.java.net/jeps/269" rel="nofollow noreferrer">convenience factory methods</a> 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.</p>

<p>One thing to perhaps keep an eye on is the <a href="http://openjdk.java.net/jeps/266" rel="nofollow noreferrer">reactive streams</a> 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 <em>do</em> 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. </p>

<p>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. </p>

<p>Another thing to perhaps keep an eye on is the new <a href="http://openjdk.java.net/jeps/259" rel="nofollow noreferrer">Stack-walking API</a>. 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.</p></li>
<li><p><strong>Language changes</strong>: the language changes also seem to be <a href="https://docs.oracle.com/javase/9/whatsnew/toc.htm#JSNEW-GUID-825576B5-203C-4C8D-85E5-FFDA4CA0B346" rel="nofollow noreferrer">relatively minor</a>. 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.</p>

<p>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.</p>

<p>Strings are also no longer implemented using a char array -- rather, they're implemented using a <a href="http://openjdk.java.net/jeps/254" rel="nofollow noreferrer">byte array with an encoding field</a> 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.</p></li>
<li><p><strong>Applets are deprecated</strong>: Java web applets are deprecated in favor of "<a href="https://docs.oracle.com/javase/9/deploy/migrating-java-applets-jnlp.htm#JSDPG-GUID-1F95EBB3-D5CB-434A-B069-2261900738F5" rel="nofollow noreferrer">Java web start</a>", 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.</p></li>
</ul>

<hr>

<h1>Details: Changes in Java 10</h1>

<p>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:</p>

<ul>
<li><a href="http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html" rel="nofollow noreferrer">http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html</a></li>
<li><a href="http://cr.openjdk.java.net/~iris/se/10/latestSpec/" rel="nofollow noreferrer">http://cr.openjdk.java.net/~iris/se/10/latestSpec/</a></li>
</ul>

<p>Some changes worth talking about:</p>

<ul>
<li><p>Java now has <a href="http://openjdk.java.net/jeps/286" rel="nofollow noreferrer">variable type inference</a>. That is, it's now legal to do:</p>

<pre><code>var foo = new MyLongObjectType();
</code></pre>

<p>This is treated as being exactly equivalent to doing:</p>

<pre><code>MyLongObjectType foo = new MyLongObjectType();
</code></pre>

<p>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.</p>

<p>This feature also interacts oddly with the diamond operator. For example, the following code:</p>

<pre><code>var foo = new ArrayList&lt;&gt;();
</code></pre>

<p>...is treated equivalently to doing:</p>

<pre><code>ArrayList&lt;Object&gt; foo = new ArrayList&lt;&gt;();
</code></pre>

<p>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.</p>

<p>For these reasons, I think variable type inference is (currently) more trouble then it's worth to teach. </p>

<p>This may change in the future though, if Java were to one day add <a href="https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/anonymous-types" rel="nofollow noreferrer">anonymous types a la C#</a> -- 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!)</p></li>
<li><p>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:</p>

<ul>
<li><code>List.of(a, b, c, ...)</code>: creates an immutable list</li>
<li><code>Set.of(a, b, c, ...)</code>: creates an immutable set</li>
<li><code>Map.of(k1, v1, k2, v2, ...)</code>: creates an immutable map (up to a fixed number of key-value pairs)</li>
<li><code>Map.of(entry(k1, v1), entry(k2, v2), ...)</code>: creates an immutable map containing an arbitrary number of key-value pairs. Requires you to statically import the <code>Map.Entry.entry</code> method.</li>
<li><code>List.copyOf(list)</code>, <code>Set.copyOf(set)</code>, and <code>Map.copyOf(map)</code>: 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).</li>
<li><code>Optional.getOrThrow()</code>: equivalent to <code>Optional.get()</code>, but is now the preferred name.</li>
</ul>

<p>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.</p></li>
<li><p>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).</p></li>
<li><p>The javadocs tool has seem some minor improvements -- there's a <code>@summary</code> tag now; there's an <code>--overridden-methods=VALUE</code> flag you can use to group documentation about inherited methods with no spec change together. <a href="http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html#JDK-8185371" rel="nofollow noreferrer">More details</a>.</p>

<ul>
<li><p>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. <a href="http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html#JDK-8146115" rel="nofollow noreferrer">More details</a></p></li>
<li><p>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. <a href="http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html#Removed" rel="nofollow noreferrer">Full list</a>.</p></li>
</ul></li>
</ul>

<hr>

<p>And finally, I think it's also worth briefly mentioning changes that do <em>not</em> appear to be a part of Java 9 and 10. From what I can tell, value generics (e.g. <code>List&lt;int&gt;</code>), 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,  <em>would</em> have required some changes to a Java-based curriculum, but alas, not yet, it seems. </p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-06T03:58:05.367Z
Applets depend on the NSAPI interface,  which is considered a security risk, and is no longer supported by major browsers.  (Since IE11 is going to be the last of its lineage,  supplanted by Edge,  we can consider it dead for practical purposes.) The Java Webstart mechanism is less convenient to the user, but much more secure.
pojo-guy
CC BY-SA 3.0
2017-07-06T06:38:15.233Z
Excellent details and great information. Very informative and helpful.
Gypsy Spellweaver
CC BY-SA 3.0
2017-07-06T06:45:34.223Z
What you wrote in the API section (as well as JShell and module system, but that's a different comment) is very correct. I had not thought of using the  Process API for tooling, but now I can see all sorts of interesting things the school can do. And as for Stream, well, it's planned all along, and now I have a clearer image of how it can be done properly.
ItamarG3
CC BY-SA 3.0
2017-07-06T01:20:46.097Z
2018-03-21T23:32:15.833Z
2018-03-21T23:32:15.833Z
Michael0x2a
<p>(this is my first answer here, so I hope it's good)</p>

<p>If Java 9 is meant, as you say, to allow better compatibility for older programs, then there shouldn't really be any difference in the way you teach. Some of the features added in Java 9 are just additions to things put in Java 8. You said your school teaches Java 8 but "<em>but for it's worth, it might have been Java 6</em>", so I think there shouldn't be a difference in the way you teach java 9. </p>

<p>But if you are thinking of adding things that are new in Java 9 to your teaching, then you should introduce modular programming as the very first thing. You said 'school', so I'm assuming you teach in a high-school. For high school students modular programming can be a difficult thing to understand. So make sure you teach that before teaching how Java 9 uses it.</p>

<p>Also I think your students would learn a lot if you taught them the stream API which, as Michael0x2a said in his answer gained utility methods. Java's stream API is meant to be used with $\lambda$ expressions. This means that teaching the stream API gives your students experience with $\lambda$ expressions. </p>

<p>In conclusion,<br>
Java 9 gives your students an introduction to a number of programming techniques (modular system, $\lambda$ expressions etc.) that can be useful for them after school.</p>

CC BY-SA 3.0
2017-07-06T08:39:42.977Z
This is an interesting view. Welcome to [cseducators.se], I hope we'll be hearing more from you.
ItamarG3
CC BY-SA 3.0
2017-07-06T08:28:40.323Z
2017-07-06T19:22:20.047Z
2017-07-06T19:22:20.047Z
Harry
<p>The changes are not huge.  However, all of us will like JShell a whole lot.  Java 8 was where the big changes occurred.  I only forsee small changes in how I do things.</p>

CC BY-SA 3.0
2017-07-07T06:42:24.760Z
I thought so at first but then I took a closer look at the Modular System
ItamarG3
CC BY-SA 3.0
2017-07-06T21:30:27.330Z
2017-07-06T21:30:27.330Z
ncmathsadist
<p>Java 9 and 10 were both released recently -- Java 9 was released on Sep. 21<sup>st</sup>, 2017 and Java 10 was released on Mar. 21<sup>st</sup> 2018. These two releases contain some very big changes: Java becomes modular and has REPL, various APIs have been improved, and Java now supports type inference. However, the changes are, partly, meant to allow backwards compatibility.</p>

<p>Currently my school teaches using Java 8 (but for it's worth, it might have been Java 6). I am considering switching to using the latest version of Java in the curriculum, but I'm not sure how useful it would be for the students, in comparison to the current curriculum.</p>

<p>The school teachers are very open to updating the curriculum, so it's simply a question about benefits students might gain if we were to upgrade the curriculum to use the latest version of Java.</p>

<p>So, what significant benefits would the students gain if they were taught Java 10 (and also the effect of a Java 10 centered curriculum)?</p>

CC BY-SA 3.0
2017-07-06T09:34:27.660Z
If your CS curriculum depends on the specific version of a specific programming language, it is broken. Or not a CS curriculum at all. IMHO.
Raphael
CC BY-SA 3.0
2017-07-06T10:28:43.120Z
@Raphael it most certainly doesn't depend on a specific version, but I'm wondering what are the benefits of upgrading to java 9, specifically because of the changes in comparison to previous versions.
ItamarG3
CC BY-SA 3.0
2017-07-06T11:06:38.870Z
For me, leading by example would be enough. You don't use outdated stuff. (I remember a prof explaining concurrency with Java 1.4 -- in 2008.) Maybe not hot-off-the-press stuff, either, (why?) so there's a trade-off here. (What *would* be interesting is to compare the versions together with the students. Why were certain changes made, which problems are being solved? That's bound to lead to insight.)
Raphael
CC BY-SA 3.0
2017-07-07T02:53:15.930Z
As much as i am in favor of using the latest and greatest, another reality is that much of computer programming is maintenance of old code. I recently upgraded a system that was still running java 2, and have maintained and written new COBOL code in the past 5 years. Figuring out how to work without lambda's might be good for an advanced exercise.
pojo-guy
CC BY-SA 3.0
2017-08-08T16:51:05.813Z
Leading edge is often bleeding edge. As an educator I hesitate to update to the "latest/greatest" at the start of the academic year (for us). I'd rather wait and see that things are working before committing to it. Updates rarely have justified that risk for us, and I don't think our students are missing out on anything working on v. n-1 (where n is the latest version) for a bit longer. YMMV.
Levon
CC BY-SA 3.0
2017-08-08T16:51:45.613Z
@Levon Interesting point.
ItamarG3
CC BY-SA 3.0
2018-03-21T19:41:08.303Z
@ItamarG3 -- do you mind if I update your post so it focuses on Java 9, 10, and (eventually) 11? Java 10 came out today + support for Java 9 just ended, so I figured rather then having a new "should I switch to Java x" post for each new release, we have just one, at least up until the next long-term support release (which is apparently Java 11).
Michael0x2a
CC BY-SA 3.0
2018-03-21T19:47:16.860Z
@Michael0x2a all right. Just be sure to change your answer to fit.
ItamarG3
<curriculum-design><java>
The impact of switching to Java 10
# The impact of switching to Java 10

(Asked by: username_0 on 2017-07-05)

Java 9 and 10 were both released recently -- Java 9 was released on Sep. 21st, 2017 and Java 10 was released on Mar. 21st 2018. These two releases contain some very big changes: Java becomes modular and has REPL, various APIs have been improved, and Java now supports type inference. However, the changes are, partly, meant to allow backwards compatibility.

Currently my school teaches using Java 8 (but for it's worth, it might have been Java 6). I am considering switching to using the latest version of Java in the curriculum, but I'm not sure how useful it would be for the students, in comparison to the current curriculum.

The school teachers are very open to updating the curriculum, so it's simply a question about benefits students might gain if we were to upgrade the curriculum to use the latest version of Java.

So, what significant benefits would the students gain if they were taught Java 10 (and also the effect of a Java 10 centered curriculum)?

**Tags:** curriculum-design, java

> **Comments:**
> **username_1**: If your CS curriculum depends on the specific version of a specific programming language, it is broken. Or not a CS curriculum at all. IMHO.  
> **username_0**: @username_1 it most certainly doesn't depend on a specific version, but I'm wondering what are the benefits of upgrading to java 9, specifically because of the changes in comparison to previous versions.  
> **username_1**: For me, leading by example would be enough. You don't use outdated stuff. (I remember a prof explaining concurrency with Java 1.4 -- in 2008.) Maybe not hot-off-the-press stuff, either, (why?) so there's a trade-off here. (What *would* be interesting is to compare the versions together with the students. Why were certain changes made, which problems are being solved? That's bound to lead to insight.)  
> **username_2**: As much as i am in favor of using the latest and greatest, another reality is that much of computer programming is maintenance of old code. I recently upgraded a system that was still running java 2, and have maintained and written new COBOL code in the past 5 years. Figuring out how to work without lambda's might be good for an advanced exercise.  
> **username_3**: Leading edge is often bleeding edge. As an educator I hesitate to update to the "latest/greatest" at the start of the academic year (for us). I'd rather wait and see that things are working before committing to it. Updates rarely have justified that risk for us, and I don't think our students are missing out on anything working on v. n-1 (where n is the latest version) for a bit longer. YMMV.  
> **username_0**: @username_3 Interesting point.  
> **username_4**: @username_0 -- do you mind if I update your post so it focuses on Java 9, 10, and (eventually) 11? Java 10 came out today + support for Java 9 just ended, so I figured rather then having a new "should I switch to Java x" post for each new release, we have just one, at least up until the next long-term support release (which is apparently Java 11).  
> **username_0**: @username_4 all right. Just be sure to change your answer to fit.  

---

## 4 answers

### Answer by username_4 on 2017-07-06. Score: 20 | Accepted answer

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:

Language changes and major new features:

Java 9 introduced a REPL called "jshell". This is probably the most relevant and useful change from a pedagogical point of view.
Java 10 introduced variable type inference -- e.g. if you type var a = new StringBuilder(), the variable a will be inferred to be of type StringBuilder. 
Although this feature may be worth mentioning, I think it's also safe to largely ignore -- see the section below for more discussion. 
Java 9 introduced a new module system (Project Jigsaw). Although this this is a potentially major change to Java/the Java ecosystem, it's unlikely to impact your curriculum in the near future and is probably not something worth teaching (see below). 
At most, if you want to be super-precise when explaining how Java works, it might be worth mentioning Java now includes 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.

Minor new features and quality-of-life improvements:

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. Java 10 followed this up with some additional minor improvements also related to internationalization.
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.
Interfaces in Java may now contain private methods. This may slightly affect how you teach ADTs, Java abstract classes, Java interfaces, and so forth.
You may also be able to use this new feature to actually help minimize the amount of time you spend having to teach Java. That is, Java currently has two mechanisms for encoding the notion of an abstract data type: interfaces, and abstract classes. Depending on the kinds of assignments you give out, you may have needed to explain how to use both. Now that interfaces are slightly more powerful, it's possible you may be able to adjust your assignments and skip having to explain abstract classes altogether.
Java 9 and 10 together introduce a variety of convenience methods for more conveniently creating and copying collection types -- e.g. List.of(a, b, c, ...), which creates an immutable list, and List.copyOf(list), which creates an (immutable) copy of the given list.

Other changes:

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 way foreach loops were translated to bytecode was actually slightly buggy and could prevent garbage collection in some cases -- this issue was fixed in Java 10. This is unlikely to affect you and your students, perhaps unless you are deliberately asking them to work on assignments that ask them to manipulate large amounts of data.
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



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:

http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html
http://cr.openjdk.java.net/~iris/se/10/latestSpec/

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 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 list
Set.of(a, b, c, ...): creates an immutable set
Map.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), 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.

> **Comments:**
> **username_2**: Applets depend on the NSAPI interface,  which is considered a security risk, and is no longer supported by major browsers.  (Since IE11 is going to be the last of its lineage,  supplanted by Edge,  we can consider it dead for practical purposes.) The Java Webstart mechanism is less convenient to the user, but much more secure.  
> **username_6**: Excellent details and great information. Very informative and helpful.  
> **username_0**: What you wrote in the API section (as well as JShell and module system, but that's a different comment) is very correct. I had not thought of using the  Process API for tooling, but now I can see all sorts of interesting things the school can do. And as for Stream, well, it's planned all along, and now I have a clearer image of how it can be done properly.  

---

### Answer by username_7 on 2017-07-06. Score: 5

(this is my first answer here, so I hope it's good)

If Java 9 is meant, as you say, to allow better compatibility for older programs, then there shouldn't really be any difference in the way you teach. Some of the features added in Java 9 are just additions to things put in Java 8. You said your school teaches Java 8 but "*but for it's worth, it might have been Java 6*", so I think there shouldn't be a difference in the way you teach java 9.

But if you are thinking of adding things that are new in Java 9 to your teaching, then you should introduce modular programming as the very first thing. You said 'school', so I'm assuming you teach in a high-school. For high school students modular programming can be a difficult thing to understand. So make sure you teach that before teaching how Java 9 uses it.

Also I think your students would learn a lot if you taught them the stream API which, as username_4 said in his answer gained utility methods. Java's stream API is meant to be used with $\lambda$ expressions. This means that teaching the stream API gives your students experience with $\lambda$ expressions.

In conclusion,  
Java 9 gives your students an introduction to a number of programming techniques (modular system, $\lambda$ expressions etc.) that can be useful for them after school.

> **Comments:**
> **username_0**: This is an interesting view. Welcome to [cseducators.se], I hope we'll be hearing more from you.  

---

### Answer by username_8 on 2017-07-06. Score: 4

The changes are not huge. However, all of us will like JShell a whole lot. Java 8 was where the big changes occurred. I only forsee small changes in how I do things.

> **Comments:**
> **username_0**: I thought so at first but then I took a closer look at the Modular System  

---

### Answer by username_5 on 2018-03-26. Score: 1

While this question is specifically about Java, it is a subset of the larger question as to what version of software should be used for teaching. This involves not only languages (Java/C/C++/Python), but operating systems (Windows/Linux/MacOS), and compilers (gnu/MSstudio/clang).

There are good reasons for any of the choices. What the student is concerned with is how their program will be tested. Therefore, it is important to specify how testing is performed. CSU's blanket statement is that testing is performed on the lab computers, which the students may access both in person and remotely. They are expected to test their program on lab computers, no matter where they actually developed the code. Our system admin provides identical environments on all lab computers.

At least one university provided a VM image to the students to guarantee a consistent environment. At a minimum, one should specify which version of a language (e.g. Java8), will be used in testing.


---

