Matt and Rich run through what they think are the exciting features of Java 9, but they're not allowed to mention Jigsaw.
What will Richard find to moan and rant about most this week? Java's new genius numbering system? Or people who want to keep their lists mutable?
Richard:So welcome to, we think it's number eight of “All Things Java” from Virtual Pair Programmers. Around the table are ...
Matt:Matt Greencroft, nice to speak to you again Richard.
Richard:I'm Richard Chesterwood. So, this week, I think, Matthew is all excited because he wants to talk about Java 9 - obviously the big news in Java.
Matt:Very formal calling me Matthew, but there we go. Thank you. Well, obviously it's big news. Today is the 28th of September and three days ago, there were two big important releases: Java 9 and JavaEE 8. I guess we'll talk about JavaEE on a future podcast. The one thing, obviously, everyone is talking about is the fact that as of the 25th of September it is now open source and is being hosted by the Eclipse Foundation. But again, we'll probably come back to JavaEE on another podcast.
Richard:So, the Eclipse bit was JavaEE, you were talking about?
Richard:And not the Java standard edition?
Matt:No, there is something ... Well I noticed something, actually, about the Oracle JVM has become open source, I don't know any more than that because I don't use ... Sorry, not the Oracle JVM, the IBM JVM has been open sourced and I think that Oracle are talking about open sourcing the parts of theirs that aren't currently, but I'm not really up to speed on that.
Richard:I could get lost in that. I thought they were pretty much the open JDK but with additional, I don't even ... We've done a previous podcast on that and we got ourselves in knots that time around... It's not interesting as programmers, is it?
Matt:So, I that this should be a Java 9 special, and we've previously talked about some of the big features in Java 9, so modularity, and the ability to create your own cut down versions of the JVM.
Richard:Can I interrupt there? Sorry, you were getting into your flow there. So, it was right back on our very first podcast, we explained that we were nervous about podcasting because it's not our kind of natural medium we like to review things and edit things. That was ... Immediately we gave a good example of that when we started talking about a modular JVM. How you ... And we got ourselves in knots a bit, and we should have stepped back and realised, we are talking about a modular Java runtime, rather than a ... the JVMs a tiny little bit, it’s the thing that executes your byte codes.
So, just to be clear, the idea with Java 9 is that you can deploy a modularized runtime environment so you'll still have the same JVM, which is a tiny little bit of executable code, but you don't have to ship all of the standard Java libraries, which, you know, you don't need 95% of them for any application.
So, I'm sorry to jump in there, but I was quite ... I remember listening back to the previous podcast and just cringing when I ... It was obvious but when you're in front of a microphone you just keep saying JVMs a sort of short hand for the runtime environment.
Richard:I do apologise.
Matt:You know, now you've said that, I'm pretty sure on Java Fundamentals, we actually say these are interchangeable terms. And of course, I guess until now, when you can create the cutdown version of the runtime environment, they were.
Richard:It felt that way.
I know there's a lot of people in IT, naturally, because it's sort of very left brain way of thinking isn't it, programming. You tend to have these really precisely defined and people can get quite pedantic about things, but sometimes we use terms interchangeably and JVM and JRE, we'll be clearer in the future.
Matt:Yes, it's becoming more important to be clearer. So, what I was going to say is we've talked about that, so let's not talk about that today.
What I thought might be interesting to talk about is what are the things in Java 9 that might be the kind of things that would say "actually, it's worth us adopting Java 9 because this feature is going to be quite useful for us in this project." And what will come out of that as well, or we could start with this maybe, is what might make you adopt, or not adopt Java 9 - how quickly, what are the issues going to be?
Now Java 9 has only been out for a couple of days so ... And I've not looked in massive detail, I've not tried to upgrade in any projects yet, I don't know if you have?
Richard:I have done literally one day on, well one half day really, I'm busy working on Reactive and a few other courses. This has been something I've had to jam in. I'm really nervous on this podcast that I'm not going to have a lot of deep information. But I have attempted to port one of our projects that we've shipped with previous Virtual Pair Programmers courses just to see if it will run.
Matt:And should we start with that: did it then?
Richard:I want to keep my powder dry on that and reveal it a bit later on.
Matt:In that case, let's start with the killer news, I think, that Java 9, that was released two days ago, is not going to be a version that's going to achieve ... That's going to be given long term support by Oracle.
Richard:This is interesting.
Matt:So, are you aware of the new numbering scheme for future Java versions?
Richard:I just saw it this morning, and I didn't understand it at all.
Matt:No, it's a bit confusing. So, rather than ... The way Java version releases have happened up until now is you have a big Java release, which 8 was, which 9 is, and then lots of these little interim ones, which are primarily security patches - little incremental things that you don't really notice.
Oracle have decided they're going to move to a six month release cycle, so the idea is to become a bit more agile in terms of ... I knew you'd laugh at that. In terms of the ... How features are going to added to Java. They're going to number these releases as a two digit year, followed by the month of the release.
So, in theory at least, the next release is going to be in March 2018, and that will be release 18.3. So, 18 for 2018, three for March, and the release after that will be 18.9. So, very odd numbering scheme. So, Java 9, or 1.9 you might think of it, is the last of that numbers. Then we'll going into 18.3, 18.9 ...
Richard:Will it be ... But it won't be Java 10?
Matt:No. So, there'll be no Java 10, it'll be Java 18.3.
Richard:Are you sure? That sounds absolutely bone-headed, brain-dead nonsense.
Matt:That seems to be what everyone is saying, what I've read online, absolutely.
Richard:Is it not going to be Java 9, edition 18.3, and then eventually they'll tick that up to Java 11?
Matt:No, so, from what I understand, because they want to make it so there isn't these massive long releases between 9 and 10, there's just going to be a six month long release cycle now.
And 18.3 will get long term support. So, I think what they've done here is, they've said "look, we know that Java 9 is going to have some real issues on the day of release, so we're not going to offer long term support until six months later, when we've got a new version out, which we hope is going to fix some of those initial issues."
Richard:I've got to say, I'm really impressed, I'm really, really impressed with that because the amount of ... I've got to say this without swearing, I can't think of the right words. I'm just going to go with the amount of brain-dead nonsense that has gone on through the years, with Java's numbering, and they have topped themselves and come up with something even worse than what happened before it. Amazing, absolutely amazing.
I mean, do you remember when we were doing Java Fundamentals, the training course? One of the most common, frequently asked questions by a newbie to Java ... Actually I'm probably going to say to people who worked extensively in Java is I don't understand the numbering, because we start with Java 1, then it was Java 1.1, then Java 1.2 - which was also called Java 2. And then we have Java 1.3 - which was also called Java 2. Just a total mess ... Then it got to ... So we had Java 1.4 - which was Java 2, and then we have 1.5 - which was Java 5. 1.6 is Java 6, 1.7 is Java 7, and they kind of settled into this.
So, the release three days ago then was Java 1.9, but actually Java 9.
Matt:I haven't seen it called 1.9 anywhere, but obviously it is. Well, I assume it is, I don’t know?
Richard:Yes, I have, because in my ... Yes I'm fairly certain that ... One of the first things I did when I was running the spring boot app under Java 9 was ... I wasn't sure ... I got something running, that's a little taster of what I'm going to reveal. But, I got something running, but I was like "maybe I've made a mistake here, and I've just compiled on Java 9, and my runtime is still Java 8."
So, all I made this app do, was you just went to a controller and it did System.getProperty , Java version, and output that to the webpage. I'm fairly certain it outputted 1.9.
Matt:I'm sure you're right.
Richard:So, are you absolutely certain that what you're saying here is there won't be a Java 10? This is the last of the Java?
Matt:You're asking me to put my neck on the line here, and I would like to say I'm 99% certain.
Richard:Because that's huge, that's massive, isn't it?
Matt:It is. It's not just the whole numbering changing, it's the fact that actually, to me, they're saying they haven't got confidence in Java 9, because they're saying they're not even prepared to give it long term support in its current state.
Richard:But they're kind of saying it's a little bit like going ... It's going to the Google Chrome system of numbering where there isn't a number anymore, it's just Google Chrome. You don't know what version of ... What version of Chrome are you running? Obviously there is a version, but it's all hidden because you just get drip feed updates, and you expect it to always stay updated, and it sounds like if it's true what you're saying, it sounds like that's what ...
Matt:Yes, which will be interesting because obviously companies today have got to have this decision of when do we move to Java 9 ... Well you have to, I suppose, for security reasons eventually, but when are you going to move to Java 9?
If they go to the six month release cycle, are companies going to be willing to keep either six months behind the latest version, or up to date all the time. But there's going to be a whole thought process to go in there, and I guess if the releases are smaller and more incremental than they are today with this huge amount of changes in Java 9. The list is massive now, isn't it?
And of course, a lot of the things that are changing are things under the hood to do with performance of ...
Richard:I made that point on the previous podcast, I think it's ... I don't understand why they don't separate ... There's two completely separate things, there's the runtime tools, there's the platform, and there's the core language. And they've tied the two things together. Now, what most programmers want are new programming features, but we have to wait for the entire platform to be updated.
Conversely, things like garbage collection improvements have to sit and wait in this queue until things like Jigsaw are ready. So, if they just separated those out, and let them have their own life cycles, things will be a lot more agile.
Matt:One of the things I want to ask you now, Richard, is I want to know if you're willing to take a bet, right?
So, Oracle is saying they're going to release 18.3, followed by 18.9. So, my question is, if one of those slips ... First of all, are you willing bet that one of them is going to slip, and will they call it 18.10, or will they say it's 18.9 but it's three months late?
Richard:Good question, I mean who knows? We don't know what their ... It may well be that on the 15th of March, whatever is in their current build pipeline gets shipped.
Matt:The things have been accepted, and I assume there'll still be a committee process so anything that has been accepted by a committee at that point gets shipped. Yes, it could be.
So, it would be interesting to see how that develops over time. Quite a major change obviously.
Richard:It is such a huge ...
Matt:I think, at least in the short term, because of the long term support issue I've already said, if I was a company sitting here today, I would be saying "right, well we are not moving to Java 9."
Richard:Absolutely, there's no question, based on ... We haven't done a lot, as we've said, but it is not production ready today. I'm saying there's not any bugs in it or anything. But, it has been ... You said don't talk about Jigsaw, but the massive change due to modularization. Also the ... Probably don't want to get into this, but the removal of the unsafe features that you're now not supposed to use has broken so many libraries that it's ... I mean there's no way you're going to be able to run an application server under Java 9 for some considerable time I would have thought.
Matt:I'm sure that's right. Interestingly, I don't think the ... Although the ... I mean, I had a quick look at Eclipse and IntelliJ to see how ready are they with Java 9. Interestingly, IntelliJ says "Yes, it's fully supported." Eclipse is supported via a plugin right now, release 1a of Oxygen, which is due on the 11th of October will fully support it. But, my sense of that is that, although they're saying it'll be fully supported, there will need to be some future improvements to IDEs to make it easier to use.
So, for example, in IntelliJ there is now the option to, as well as create a new class, as well as creating a new ... All those different file types you can create, they've added a module info.java as a file type you can create.
Richard:I didn't see that in Eclipse so I was using the plugin for Eclipse, which I assume you've done as well?
Matt:No, I haven't actually, but you're right ...
Richard:It took me ages to instal lit ...
Matt:Did it? It's not easy.
Richard:I'm not sure what the problem was, but once I got it in ... I couldn't see any way of creating new modules.
Matt:Because modules require a specific file structure, from what I can see the current releases don't create that, you've to create your own structure to match it. They might ... the IntelliJ helps you create a module-info.java, but that's not that helpful either. So, I think there's some more work needed around creating the wizards, if you like, that create the structures for you. But that's not difficult I'm sure for them to do.
Richard:Well, we say that because we don't have to do it, do we? But I imagine they are running around at the minute, like, all this stuff to do.
Matt:But, then this has been reasonably stable for a little while, so I'm sure it's in their plans. But, again, it's one of those things that, until it's there, until the tools are ready to support you, it's unlikely you're going to want to move - unless you've got some killer feature that means if you're were going to start a brand new project today, that needed to be module based ...
Richard:But why would you, then you would use OSGI. You know, because you're not going to have your tooling, you've got all these broken libraries, you've got all these broken frameworks.
I predict it's going to be years before this settles down. Which sounds like a big thing, but I think you were working in .NET around the time of Java 5, so I think we're talking about the year 2005-ish then, so you might not remember that Java 5 was not a massive update - now that we're looking back on it.
At the time, it felt like a huge update. It was the first time that the language had any kind of serious upgrades. The new keywords added, for example. But, looking back on it, it was next to nothing. It was a new for loop, you didn't have to create integer objects anymore - I'm talking auto boxing here. And the biggest change was generics - which wasn't a great implementation, but it's not a great big deal.
I thought at the time, maybe it's just because the version numbering has changed from 1.4 to 5, it looked like a gigantic leap. For years, my perception was companies were not moving across to Java 5. At the time I was running live training courses, and I was always asked for "can we have a Java 1.4 course, please?" That was two years after the release. The reason I was always given was "well, our application server doesn't support Java 5, so there's no point."
Things are very different now, I guess fewer projects rely on application servers. But, I've sensed this is going to be a very long process.
Matt:I think you're right, to have the confidence that your application is going to work in Java 9. The amount of testing that some of the companies out there who've got big, complex applications are going to need to do. It's not a completely straightforward migration, obviously.
Richard:Definitely. As of today, your application is simply not going to run. It won't even start.
Matt:You’ve spoilt the reveal now then!
Actually, I've picked out to talk about, some of the features in Java 9 that I think are ... I'd describe them as useful, they are things I think I'd actually want to use.
Richard:We should do that, because we've talked a lot about the politics and a lot about why I think this is all a really badly implemented process, but from a programming point of view there's going to be interesting things in there, and we should be positive.
Matt:Exactly, and thinking about when we went from Java 7 to Java 8, the things that stand out for me as the things that were really useful, probably were the Time libraries. So, you no longer need to use Joda Time - the same sort of functionality, slightly different but pretty much it's now part of Java.
I was looking at ... Well, okay, well of that massive of things in Java 9, what are the things that I am likely to use on day one. My number one is the new syntax for try-with-resources, which is purely a readability thing. So, I don't know if you've seen this?
Richard:I don't, tell us all about it.
Matt:So, lets go back to the Java 8 way. If you want to ... so try-with-resources, in case anyone is listening who is not entirely sure what that's all about. If you are using a resource, which needs to be closed at the end, to keep things safe, Java 8 brought out this new try-with-resources construct, which auto-closes any resources. So, you don't need to the ugly try-catch-finally, embedded-try-finally-catch type blocks to make sure your resources get closed. So, it was a big thing.
Richard:A massive thing, yeah.
Matt:So, the syntax in Java 8 is that you open your resources within the try block, so you have ... This is going to be really hard to do verbally, but you've got the word try, open bracket, then you declare your objects that need to be opened, close your brackets - this is round brackets, and then you have your curlies for your try block. So, you're declaring the objects within the ... Almost as an attribute to the try, or as a parameter to the try statement. That's the Java 8 syntax.
If you've got three or four of these, it looks a bit ugly. You've got try, open round brackets, three or four lines of code, closed round brackets, and then your try block. It's a bit ugly.
Richard:Sorry, let me just ... So if you've got three resources that you're going to be working with in that block ...
Matt:Which all need to be closed.
Richard:Right, yes, I see what you mean. You’ve got 3 lines of code.
Matt:So, all they've done in Java 9 is ... Well I'm about to explain how it works, but it's much more readable. So, how it works in Java 9 is you can declare those objects before your try block, now, and then you do try, open brackets, name the resources. So, for example, if you've got ... I'm trying to think now of a typical sort of object that would need to be closed, say a database connection, you'd declare your database connection, you do try open brackets, variable name, and then you would close brackets.
Richard:Fine, yeah, good.
Matt:Much more readable. It's a very simple change, but it's going to make code a lot more readable, and in a way, it's almost easier to understand because of that. I really like that. I'm absolutely going to switch to that when I start using Java 9, and that was my number one.
My number two is that you can now have, and this is gonna sound a bit odd at first, private methods in interfaces. So, again, Java 8 allowed you to create default methods and implementations in interfaces. So, prior to Java 8, your interface was just a list of public methods. For Java 8, you could actually provide a default implementation. So, if you chose not to override that method, you'd be allowed to do so. You could use the default.
Private methods in interfaces sounds a bit bonkers, but actually, what that's about is you can now reuse your code. So your default implementation in an interface, again, this is really hard to do when you can't see the code.
Richard:Yeah. It's a difficult medium, podcasting.
Matt:Yeah. And the example I saw actually was about logging. Let's say you're writing a logg ing platform, and you're creating methods that your people to override called logWARN, logINFO, logDEBUG, your default implementations might all share the same four or five lines of code. Well you don't have to now copy that lots of times. You can have it in a single private method, but your default can call, and again, I think nice, sensible useful, not going to be used all the time, but when you're doing default implementations now, well, that's a useful feature.
Richard:Brilliant. And you heard it here first on the podcast that Matthew is planning to implement his own logging framework, which is exactly what Java needs, another one.
Matt:I said that was the example I'd seen. That was an example that made sense, so I thought I'd repeat it.
Richard:That was one of the private methods in interfaces, was like the first thing I picked upon and I thought wow, this looks really interesting. Do you think this is a bit of an edge case though, is that really a day to day thing? Maybe it's because I haven't personally used default methods in interfaces very much at all, which just for legacy reasons I guess, don't do a lot of Java 8 really.
Matt:No. I guess one of the systems that I look after actually uses abstract classes, and I think with this, I could have done it using interfaces, it just feels nicer, so it just gives that extra ... there's another way of doing the things you might already be doing. It feels like it makes sense to me.
Richard:Oh yeah. I think the default methods in interfaces is a great thing, and will tie into what my number one feature is going to be, by the way, but you're bound to come to it, sure. Yeah. I mean, it's an incremental improvement on that feature that came from Java 8 I think.
Matt:I like those first two, because they make sense, they're easy to understand, and you can see that actually, if you're going to be doing default methods in interfaces, it's actually potentially going to be really useful. So, nice. So, my next one sort of actually follows on, 'cause I think this must be how they've done it, but this is the new methods to create immutable collections.
So again, let's just recap how it works in Java 8, which actually still works in Java 9. They haven't changed this, which is that you can call Collections., for example, unmodifiableList to create an immutable arraylist, and there was similar methods for maps and sets.
Richard:Yeah. And you have to pass in an existing list. So, your create a list first, which is a regular modifiable one, and then you pass it into this factory method, and out comes an unmodifiable list.
Matt:And that is still, I believe, the only way to create an unmodifiable list in Java 9, if your starting point is an existing list or existing map. What they've created, however, are new static factory methods for creating an unmodifiable list. Let's just talk about lists now. Either from an array or from the actual elements that are going to form that list. So, the syntax for this is List with a capital L, so the interface List dot-of, and then, in brackets either a commented limited list of elements or an array of elements can go in there. And that creates a new immutable collection. So, this is the one that I wasn't sure Rich, what your reaction to this was going to be.
Richard:This is my number 1 feature by a million miles. It's the only thing that I have any interest in, in Java 9.
Matt:So, why? Why is this your top?
Richard:First of all, I think the unmodifiable bit is ... that's fine, but for me, it's not the important bit. It's the fact that you can now declare the list inline, which has never been possible to do in Java. So, just to create a list of five elements. You're needing to do this all the time, by the way. It's not, this is not an edge case. All the time, you need a list and I need to pre-populate it with five elements. Up until now it's been, line one is List myList = new ArrayList(); You can't put anything in the round brackets into the constructor, then you've got another line, list, myList.add(something); myList.add(something); repeat, repeat, repeat, repeat.
Really tedious, and every modern language, groovy, I'll just pluck up as an example. You would just do def myList =  and groovy knows you're instantiating a new list, and you do it in line, in one line.
Richard:So, it's the one line that's the important thing.
Matt:So, that's interesting. So, that is, and I agree with you, a nice feature, what I'm not sure about though, is that this is an unmodifiable list that you're creating -
Richard:And we like immutability, don't we?
Matt:We do. However, the object that gets created is an object that implements the List interface. Therefore, it will give you the ability to call the methods like add and remove, and if you try to call one of those methods, you'll get an UnsupportedOperationException.
Richard:Indeed you will, so don't do it!
Matt:So, that's all very well, but I thought what a shame that they've created the ability to create an unmodifiable list, and yet, there's no ability at compile time to check that you're not trying to call a method…. Why even expose those methods? It's so annoying.
Richard:I mean it's very difficult to architect. So, you would have to have the parallel inheritance hierarchy of unmodifiable lists, which didn't have the method. It's because you can't remove a method when you do an inheritance effectively. So, that's always been a ... I don't think that's the Java. Well, okay, other languages would have mixins and things that would do things better, but for me, that's like the argument. People got very excited about generics and oh, you don't have to do a cast anymore, because you might get the cast wrong when you take an object back out of the collection.
Actually, when you examine that use case, you've got a collection. You know what's inside it. You know the chances of having a class cast exception error, that's so tiny, and unit tests would expose that anyway. And it's a similar argument at least for the unsupported operation. I've created that list, probably, all right. I might have been sent it, from somewhere, so I might be writing a method that accepts a list, and I get sent an object at run time and I call remove on it. I get a run time exception, big deal. Your unit tests should pick that up.
Matt:Well, I'm please we've got something we disagree on, 'cause I'm disappointed with that.
Richard:You're an immutable programmer, Matthew. You shouldn't be expecting to be able to remove elements. And actually, genuinely, I would say and this goes back to all the kind of things we talk about in our Advanced Java course where if you've been sent an object, you've just been passed a reference to that object. So, doing things like removing elements from a list that you've been given is really dangerous, because you're modifying the underlying collection, and the caller might not want you to do that. So, the fact that you're going to get a run time exception, good. It serves you right, you shouldn't have done it in the first place.
Matt:Okay. Well, I'll buy that.
Richard:I think people in Java, and maybe this is why doing a few years of programming in a dynamic language helps change your mindset a little bit. I am all for strong typing and catching errors at compile time, don't get me wrong. I love that. It's one of the reasons why we're currently working on moving an entire application from I think it's Groovy and Grails based back into Spring Boot which is going to be using Java. One of the nicest feelings of doing that is: ah, the compilers telling me so many problems that exist within that legacy code?
So, I'm all for it, but I think people get too ... The idea of a run time exception, it's the worst thing that can happen, catch them in the unit tests, and then ...
Matt:But how much nicer could it have been if it could've said well, you can't call new on, it can't call add rather, it would've been so much nicer.
Richard:Yes, I'm just loathed to way, because I've not sat down and attempted to re architect the existing collections liable to fit in an unmodifiable collections parallel hierarchy. I've got a feeling that would be a world of pain that would just ... I mean you wouldn’t be working with lists for a start, because lists, by definition, from the legacy that's gone on, you can't remove remove from the list interfaces. So, they've had to create a new interface called UnmodifiableList which I don't know, it's easy for us to sit here and say they should have done that, but I think that's one of those things they would have…. send a memo to Josh Block!
Matt:Okay. So, that's your number one. That's interesting. Anyway, I'll just mention my last one that just caught my eye really, which is the new HTTPClient object. And I guess this is just relevant to me particularly right now, because as you know, I've been working on the replacement for our Java Web Development course. And at first view, what HTTPClient lets you do, is it makes it much easier to, I'm going to say consume a web page. So if, for example, you're writing code which is going to be polling a webpage, looking for a particular string, and then going to do something when that string occurs. That's a typical use case. You'll be able to do that now with much less code, much neater. You don't need BufferedReader objects anymore. It sort of uses a factory style, sorry a builder a style process to do all of that very, very nice.
And certainly, I'm doing some work at the moment on websockets for the course, and certainly, it's doomed to be much easier to write a websocket client using the new HTTPClient object. So again, I think that's interesting. I've not, at this point, worked out what difference it makes to writing the server-side of web sockets. I'm sure there will be improvements there as well, but I've not looked at those yet, and I'm hoping that I will get to that in the next few days, so that when module two of Java Web Development comes out, there will possibly be a here's the traditional Java 8 way of doing it, and then a Java 9 way
Richard:So, some Java 9 in there. Very nice.
Matt:I'm hoping. And I think it's worth doing, because I think it's interesting to see what they've done there, and see how much nicer it's going to be. I'm not absolutely promising it, because I want to test it and make sure I can get it to work first.
Richard:Well, of course, yeah. It's certainly a risk that you need to de-risk.
Matt:It is, but again, if you are doing something that is going to be consuming web pages, and actually I've, just for my own benefit, been thinking about writing a little application to do that, to save me a little bit of time. Say I just want to check a particular webpage every day to see if something's changed and I can be automating that. This will be a lot quicker to do that. So, I think that's again, a really useful feature. I like the look of the new HTTP client object.
Matt:Anything else you've spotted in Java 9 that you think's ... happened to look at?
Richard:I have. I've just managed to close my page of notes. So, I need to very quickly, yeah. So, for me number two that stuck out was they have erm, I’m really on the edges. I'm working on a course on reactive technologies, and that's my number one priority, as opposed to Java 9. But I noticed that there is Java.util.concurrent.flow, which has been modified to incorporate, and I'm really not sure what's in there, because I've not had time to explore it, but they’ve absorbed some of the RX Java-style features in there. So, you can tell I am skating on very thin ice here. That's going to be kept dry for the upcoming course. I won't talk any more about that.
Richard:'Cause I don't know any more about it. I think the only other thing that ... Oh, sorry. Two more things. They've improved the deprecated annotation. That is so minor, really, but this signals a political change in the way Java is going to be managed in the future, which looks quite promising. So, in case you don't know, the way that deprecation works in Java, Matthew always calls it depreciation, by the way.
Matt:And you have to edit it every time I say that don't you, yes.
Richard:Because you're from a finance background. So, deprecated means to make less important, and the tradition has always been nothing's been removed from Java. So, even the horrible rubbish that was in Java 1.0 has fallen into disuse, rather than removing it which could break any number of millions of lines of code out in the field, they put a marker on it which says you probably shouldn't use this any more in the future.
However, nobody anywhere has sat down and defined what deprecated means. Does it mean you should refrain from using this method? Or you should never use the method? Or what? No one really knows, because it was never defined. I've always taken it to mean this method might be removed in a future version of Java. So, find something else, but it means other things to other people.
So, they've decided to take a bit of a stand on this now, and it looks very promising. They've added a parameter to the deprecated annotation, which is forRemoval, you set it to true or false. It will default to false. So, what they're saying is that the existing meaning of deprecated is that no, it doesn't mean it's going to be removed, it's just you shouldn't use this method.
Matt:Why should you not use a method if it's not going to be removed?
Richard:Probably that they have an alternative version of that method that they'd rather you used, but they're not planning on removing the old one.
Richard:So, for example, the vector class in Java, actually is not deprecated, but they could and should have deprecated it, but I don't think they had any intention of removing it, because it retro fits it to work exactly the same as an array list. So, if you use a vector in Java code today, you've pretty much got an array list, no difference, but people will laugh at you. It's like you're wearing out of date clothes or something. So, what they've said very specifically now about the forRemoval tag is you've said forRemoval = True in that tag, you mean 100% this will definitely be removed in the next version of Java.
So, this is the first indication of finally, we're going to see things removed out of Java, which has got to be a good ... There's so much cruft in there that doesn't belong in modern Java anymore. Whether that actually plays out remains to be seen. It's just an annotation. They can't force you to remove it.
Matt:And going back to what we said earlier then, that means in six months, does it? Because there's going to be the six month release cycle. So, if you are using a method which is deprecated, and it's had that false on it for years, and all of a sudden it becomes true-
Richard:They set it to true, yes.
Matt:You've got six months to-
Richard:That's my understanding of it, yeah.
Matt:Interesting. That is interesting. We just need to monitor and see how many things ...
Richard:No one will use it. Everyone will ignore it.
Matt:You don't think parts of the core libraries that have been deprecated for a long time, they will start making those true, you don’t think ?
Richard:Let me think about that. I'm sorry. I thought I saw something saying the following packages or the following classes are going to be marked for removal, but I might have got that wrong.
Richard:But it's clear there's an intention to move in that direction. If I were a gambling man, I would be guessing that it'll just be ignored, and in 10 years time nothing will have been removed, but we'll see. The other one is multi-release JARs. This could be nice. So, they've made a change to this. Forget about Jigsaw and all that. They've made a changed to the JAR file format, which is you can now supply multiple versions of the same class in the one JAR. So, imagine you have a class, which depends on a feature of Java 9, but you want that JAR to support Java 8, then you can supply the legacy version and the new version in the same JAR, and the correct one will be chosen by the run time.
Richard:Which could be, for people who ... As an application programmer, that's probably not exciting, but if you're producing libraries, if you're writing Spring Boot, for example, then that's huge. It means you can support legacy platforms.
Matt:Yeah, interesting now. I'm just trying to get my head around what does that mean for Android?
Richard:Oh, you had to do it. What does that mean for Android, okay.
Matt:Sorry, because obviously Android has that issue where you are going to be having people using your application likely who are fixed on older versions of Java, because their device doesn't support newer versions. And Android have had this sort of a work around to allow you to use newer version, newer features of Java in older versions.
Richard:And you cover that really well on the Android Training Courses.
Matt:We do talk about it on the Android Training Courses. So, I wonder, it'd be interesting to see if that impacts the ability, or makes it easier to make a backwards compatible Android application. I know we don't do much with Android.
Richard:Of course, that would mean that Android would have to be running Java, because this feature will only be supported in Java 9 onwards, because earlier versions of the run time don't know about this feature, of course, they can't go back. But the way it will work is if I get a JAR file which has got a legacy class and a Java version 9 class. I was going to say a Java version 10 class, but-
Matt:18.3, you mean, yes.
Richard:If I then feed that into a Java 7 Virtual Machine, say, the way they've structured it is the legacy class is just at the same level it always was, and all of the later versions are in sub folders, and those sub folders will be ignored by the legacy virtual machines.
So, they've been quite clever about doing that. Is that backwards or forwards? I'm never sure. So, we're compatible with the older versions, but to actually get the dynamic I've got version 9 or version 10, you have to be on a modern version, I think. Does that make sense? I'm not explaining that brilliantly, but it was an eye-catching feature, but I don't think the application programmers should be excited by that particularly, so I am not.
Matt:No, but it will mean then that if you are building a ... If you need to use some killer feature of a newer release of Java, you can sort of continue to support the earlier version at the same time, which I can see that has some uses, definitely, yeah.
Richard:If you're the creator of Log4J, for example, you can now start shipping your JAR file as a single JAR file without having two alternative downloads, one for Java 9, one for legacy, just bundle it all in the same JAR and then the run time will pick them up, which is quite good. So, that was it for my, these what are what I think are in interesting at this stage, but it's certainly, I don't think that there's anything in there, however, that is going to make you desperate to convert to Java 9, and we can see. So, my task yesterday was go and convert some legacy Spring Boot applications, and see if they run.
Matt:Yes. So, how did it go?
Richard:So, I did one with no ... You know, just the basic controller, and that worked actually fine, and gave me Java 1.9 on the control.
Matt:When you say converted ... So, you've taken an existing?
Richard:Sorry, no, that was a brand new one, built up from scratch with nothing more than one method in one controller class, it was just a hello world. That worked. I then took the Vehicle Tracking Application, the stand alone one that we used on the last Docker course. So, it's quite nice, because it's rich enough to ... It's got web sockets and all sorts of stuff in it, but it still simple enough to, it should just stand up and run.
t doesn't simply because and I've made loads of notes about all of the run time exceptions. Right. So, there's two separate problems here.
The first one is that there are libraries such as CGLib, which is a common library which is used by millions of frameworks, that are doing things that are now illegal in Java 9. So, they do illegal accesses. And what that will result in is a warning. It will say warning, an illegal reflective access operation has occurred. In other words, those libraries are now doing things that are now illegal under Jigsaw.
Matt:So, this is a compile time warning?
Richard:This is a run time.
Matt:A run time warning?
Richard:Yeah. Because this is just an external. This is not my code.
Matt:Of course, right. Yes.
Richard:I'm using Spring Boot, which itself, has a dependency on CGLib. I'm not directly interested in what CGLib is doing. CGLib does code generation on the fly and creates classes for proxies, and things. And things like Spring absolutely depend on it. It's a very clever library. And it's doing illegal access. So, that's going to appear in your server logs. So, this could be a problem for dev ops people, not dev ops, sorry. I should say ops people. If you have a separation between development and operations, and operations say we're getting a warning here saying an illegal reflective access operation is happening on my server, get this code off my server, is a potential ... You'll remember when we did the London session on Java 9 that was the big thing they were all-
Richard:And what you can do, is you can use a run-time virtual machine flag, illegal access equals warn will-
Matt:Because then that suppresses those warnings, doesn't it?
Richard:Actually, I'm thinking now that's to switch it on. That doesn't really make sense to me, but the last warning is you get four separate warnings. Warning, all illegal access operations will be denied in a future release. So, this is the smack of firm government coming down hard. So, obviously, libraries like CGLib are now going to have to scramble around to sort this problem out. One thing we've never looked at on any of our courses or podcasts, and we're certainly not going to do it now, is this infamous com.sun.misc.unsafe package, which is the package you could use to do unsafe operations that are considered illegal by the Java Virtual Machine spec, basically.
And they've been used for years, and years, and years, especially by things like CGLib, and now effectively, that's banned. That's a real headache for people, but that's for other people to solve, I guess. As far as I can tell, and I'm sorry I'm supposed to be a Spring Boot expert, but I don't keep day to day tabs on what they're doing with versions.
As far as I can tell, Spring Boot are not supporting Java 9. I've not found their road map. If anybody's listening to this, and they've got better information, do tell me. Even the milestone release. So, I ran this again. So, the very latest milestone release, version 2 of Spring Boot, and still get the same. So, that was just a warning. I have not told you that I am also experiencing a run time exception, which is a class cast exception. It doesn't mean anything to me. It's a Boot problem. I've found the bug on the GitHub, and they've just said we're not supporting yet, so you've got to wait for a future version of Spring Boot. I don't know what their roadmap is. It's all too up in the air.
Matt:So, interesting. So, if there was any doubt about are we going to switch to Java 9 today, the answer's definitely no then, it sounds like, well certainly if you're a Spring developer, but you could actually, a lot of developers are going to probably be seeing the same sorts of issues, I guess.
Richard:Eventually, Spring Boot will release a version that supports ... I mean, I can't imagine what kind of a headache they've got, because they've got to wait for CGLib, all these other libraries, and now, probably thousands of them. I'm pretty angry that the amount of breakage that's going on here, and the amount of technical debt that we've now got, and we're going to feel it as a business. We've got dozens of courses. I think we're going to be roughly okay on the Maven, anything where we're using Maven, you would upgrade your Maven POM to use whatever the latest version of libraries you need to run on Java 9 and it should all be fixed.
But where we've got courses where we've shipped JAR files, and then somebody's going to come along and run them on Java 9. And we've got to support that, and it's also we can have Jigsaw, which we were all demanding and wanting.
Matt:Yeah. It's something we need to think about our strategy for that, and how we're going to deal with it.
Richard:But it's a wait and see strategy for now, because everybody who creates libraries that other people are using, of feeling less pain, it's going to be a long time before it settles down, I think.
Matt:One thing I haven't looked at, is that if you are downloading the JDK for the first time. You've got yourself a new computer, and you’re going to the Oracle website, how prominent is Java 9, and how hidden is Java 8?
Richard:That's fine. So now, I can test this now, but it takes you to Java 9. Yeah. I've just pulled it up on the main Java, Oracle download page, and it takes you straight to Java SE 9. And to find Java 8, you have to scroll down a fair bit, and it's just listed as Java SE 8 U144. So, there you go already. We have a serious business problem that people new to ... If they're doing the old Java Fundamentals course, they're going to go here, download Java 9. Probably be okay for Java Fundamentals, because you're just doing the programming, which is ... That's fine. Something like Java Web Development ...
Matt:Well, somebody coming along today, starting on the Spring, if they've done Java, they've never done Spring, and they go and start, let's just say the Spring Boot, do a quick start, they're going to have a problem. So, we need to think about, maybe what we'll just do is literally a 30 second video that appears on every course that says-
Richard:We don't support Java 9.
Matt:No, and if you're starting today, and installing of a JDK, make sure you pick Java 8, here's where you can find it. Just a really simple short thing that we'll have to have a think about that. But yeah, we'll need that strategy.
Richard:We will. We'll wait until the first support call comes in about it and it will not be long.
Matt:I guess. Please, anyone listening out there, don't take it as an invitation to send us a support call! The last thing I wanted to mention to you, one feature we haven't mentioned, and I just wanted to see what your reaction was, is the fact ... because the Oracle guys are making sort of a dance about the fact about Java 9, for the first time, has a REPL built in. Those who are not aware, it stands for re-evaluate print loop. Some languages, particularly CloJure, it's a very important part of ...
Richard:Yeah, any scripting language. The idea you can go into command line, and start executing commands from your language on the command line. Absolutely.
Matt:Do you see a great need for that in Java?
Richard:No it’s solving a problem that doesn’t exist. Have you ever oh, I wish I had a REPL here. So, presumably you can write Shell scripts now with a she-bang/bin/java on the top. I would guess that's the way it's going. It's a great thing to have a REPL. It's a very immediate thing you can get straight in. You can start experimenting with your language. Great, but another problem that didn't really exist. I'm going to ask one last question before we wrap up this podcast. So, we're trying more and more to keep this generic, and not about our business, but we'll do a little business chat on the end. Now, I promised a few podcasts previously, that as soon as Java 9 comes out, we should do a video on it and be first to market.
I'm going to be honest. I can't see anything in here that I'm excited enough about to want to record a video on. Especially given that we can see, and we're fairly certain that the massive amount of legacy that is going to have to move over before real applications can be built using Java 9, it's not going to be next week that programmers working on projects need Java 9. I'm not going to stop working on reactive to do a course on, “you can now create a list in one line”.
Matt:I agree. As I've already mentioned, I think the HTTP client is different and better enough to warrant a chapter on it the Java Web Development course.
Richard:Yeah, where it's relevant.
Matt:Where it's relevant. But I think you're right. A course on moving to Java 9, and it may be we actually look to do that in six months time, as a course on moving to 18.3.
Richard:So, I'll do the same with my reactive course. If necessary, I'll have a chapter on Java.util.concurrent.flow, if I think it's necessary. But the thing is though, as a business, marketing, SEO and all that, if we had a video on YouTube the top Java 9 features. That would go. I mean, people are obsessed with new versions of languages. So, that would go down a bundle. So, if our marketing ... Our lead marketer in the company is listening this far, she'll probably be telling us you need to do one.
Matt:Well, my argument to her, if she came to that would be, but actually though, it would be under false pretenses. Because a nice, flashy video all about the key features in Java 9, but actually, what's there to back it up? Because we're about the core of the language, which hasn't changed. There's some nice features there, and yes, we'll work them in.
Richard:That's a good way of thinking about it. We're not actually. We have courses on Java Fundamentals, because we want to give people a way of getting started, but then we want to get them onto the frameworks, and that's where we're at. We're interested in the full stack, and the frameworks in particular, and from that point of view, Java 9 is just a headache. So, it's fine that we say this is a headache. It's not great for us working at this level. I'm quite happy with that, yeah. When there's a new version of Spring Boot that supports Java 9, great, we will fill our boots and do a video on that.
Matt:Absolutely. And I could see that we might do a little top tips of things you can do differently in Java 9. So, particularly, the try with resources syntax which is really quite nice. We might want to do something like that. And quite a long time ago, we did a top tips when using Eclipse. And it may be something like that.
Richard:That was our Christmas video, for-
Richard:For two years, and I'm disappointed we didn't do one last year. So, we're going to reinstate the tradition of a Christmas video. But I want Christmas bells and things on it.
Matt:Okay, because our thinking was we would try to do a video that would go viral. You know those kind of things you see on Facebook where-
Richard:Oh, my God, I can't believe-
Matt:Yes, you're not going to ... I watched this and it made me cry. That kind of headline.
Richard:Our videos often make people cry, I suspect.
Matt:Yeah, but not enough for them to want to share them. So, we'll have a think. That will be our challenge for this Christmas, then, is to create a viral video ...
Richard:No. We'll create a video ... Yeah. That might be. We'll do some ... We'll definitely do that as a tradition though.
Matt:Okay. That would be nice, then.
Richard:So, yes. We've got ... It's been a month since the last podcast, but we'll still keep them regular. We are planning to do a session on Agile. Certainly, a lot of the feedback I've had on these podcasts has been can you do a video on Agile? So, we've got that coming up, possibly, it's not in the diary yet.
Matt:Yeah. We're hoping to talk to a local, I would say, expert on Agile.
Matt:One of our customers. We're hoping to get him in and talk to him about Agile.
Richard:Might not be the next one, but certainly coming up soon.
Matt:Yeah. I'd say I think we might do something JavaEE 8 just because that's out as well.
Richard:Oh, I'm off that week. I'm not doing that.
Matt:We'll see. I did it. To be fair, I don't think there's that much in there to get excited by, but we will have something on that. Partly, because it will tie in with me doing something on JSF.
Richard:Right. That's it. That's the end of this podcast. I hope you've enjoyed this. The final All Things Java Podcast... There will be another All Things Java podcast. We reckon in about two weeks.
Matt:Yeah, we'll aim for two weeks. We'll see how we get on. Should we just very quickly Java Web Development module one went live yesterday. I'm working on module two. You're working on ...
Richard:I think I released the second edition of Docker course. I released that after the last podcast. It's worth mentioning that, isn't it? That is a great course. I absolutely love it. That's turning your Docker into a swarm, so you've got your Docker all clustered across multiple instances, and we do it on a real Amazon stack. It's absolutely beautiful. There's a lot of stuff in there about if you're using the Netflix tools. Do you need them all when you're working in Docker, and I don't think you do. And there's some real deep stuff in there, and some stuff that's not covered anywhere else, and I'm now working on Reactive, which is, I suspect is going to be one of those that's going to take longer than our three week release cycle.
So, I might be releasing a short module on how to use the Amazon EC2 container service. I don't like it. So it's a difficult video for me to produce, but it's something we should have probably. And a short video on how to manage sessions when you're working in a clustered environment, which I've got a lot of feedback on that, how do you do that? We've never covered it. But that again, it's only half hour course, but it may be a little interim release.
There's a lot in the boiler, and then Spring Integration after that. I want a course on Apache Spark-
Matt:Yes. Once I've got through Web Development, then, that'll probably be next on my agenda, I guess. So, good, lovely. As we get more and more people asking for different things-
Richard:We can't keep everybody happy.
Richard:And the alternative would be let's hire 50 trainers, and get them all working on courses at the same time but A, we can't afford it, and B, the quality would go down. So, we've got to -
Matt:Yeah, we've ... Sorry. We've tried to get other trainers involved before, and we've really struggled. It's been challenge. And the Git course is the only one we've managed to do, which somebody else wrote for us. We recorded it.
Richard:Matt Strawbridge. Brilliant job.
Matt:Yeah. If he's listening and wants to write another course for us, please get in touch. We've never managed to work with another trainer who can -
Richard:It's a very difficult medium. It's not like writing a book, where you can do copying and pasting, and you can do editing, and you can do multiple drafts. Recording a video is so time-intensive. I reckon it's probably about three hours of work for one hour of video, at least.
Richard:I've massively underestimated actually, and you can't easily make changes. You make one little mistake at the beginning of that video, the whole video is trashed and you're back to square one. So, round-tripping with a trainer in the United States, say, I don't see it as a viable.
Matt:No, the other thing I guess, as well, as I'm now talking recently to one of our larger customers about this, is that what we are offering here is a package where there is almost no repetition in that library, but also there's this logical progression, because we as trainers know the entire library of training, we know that we can refer you to a particular chapter in a particular course, if you want to know more about a particular topic, and there's no, therefore, obvious gaps. Whereas, as soon as you start increasing the number of trainers beyond say three or four, that becomes quite difficult, because we've then become full time editors, effectively, don't we? In which, lessens our productivity. So, it's a challenge. It would be nice to get a third one on. We'll see.
Richard:Even with the two of us, we have a problem of fragmentation. So, AWS, Amazon Web Services is hot. People are demanding it from us, but there's going to be a large proportion of our viewers who are not working on AWS, and they're not interested. And suddenly, we have a long list of releases on AWS, and we're leaving them in the cold. So, keeping everybody happy is an incredibly different thing to do. So it's just having a round library, I think.
Matt:Absolutely, and that applies to everything. Your frameworks as well. If you're not a Spring person, if you're not a Java EE person, and we do a Java EE release, then you'll ... There's always going to be releases not relevant to you, but that said, of course, if you're trying to be that fully rounded programmer who has an appreciation of everything. Well, it's the kind of thing you might want to look at in your spare time, and just skim through. Certainly, I know a lot of our customers look at the Android courses and know, in that way, they're not planning to do any Android, but they want to have that overview, and that provides a service there for us. So, anyway, good stuff.
Richard:Helpful. So, Java 9 is here.
Matt:Use it at your own risk.
Richard:Yes. Thanks for listening and we will see you next time.
Matt:Cheery bye? Cheery bye? Leave that in!