All the latest news and views from the world of Java

The Podcast

Podcast 5: Kotlin

24-Jul-2017 in Podcasts Kotlin

In this episode Richard and Matt discuss Kotlin and what it can offer to the full stack Java developer. Plus updates on the progress with course development.

Transcript

Richard:Welcome to the Virtual Pair Programmers podcast where we're talking all things Java. This is episode number 5, I think. Episode number 5 and I'm Richard Chesterwood.

Matt:And I'm Matt Greencroft.

Richard:And I'm hesitant about number 5 because number 4, where is number 4?

Matt:So we recorded number 4 and I'm sure I read something somewhere which says never start with an apology, but it feels like we should apologise. We've not yet published number 4.

Richard:There are thousands of listeners wanting to know where number 4 is.

Matt:I think you underestimate the number of listeners Richard. So, what happened? Number 4 is done and it is pretty much ready to go. Number 4 is an interview we made with Ian Massingham from Amazon AWS. He has a really impressive job title, something like head of worldwide evangelism or something like that.

Richard:He does, yeah.

Matt:So unfortunately because of the way Amazon works, we need to get their sign off before we can publish it to make sure that I guess he hasn't said something that they wouldn't approve of. We know he hasn't. I'm sure he knows he hasn't as well.

Richard:But also I should, to be fair, it was also stuck with us for a week because ...

Matt:That's true, yeah.

Richard:... I thought you were sending it to Amazon and you thought the opposite, so we both sat on it for a week.

Matt:Yeah, so he's had it for a week to review and I guess if when we come to record number 6 we still haven't got it back we'll start being nasty about them, but so far it's more our mistake maybe, so hopefully we'll have that out quite soon.

Richard:That's quite a scary experience really talking with, I mean, he was a real expert in, I kind of thought he'd be a sort of sales person, but he really did know every single AWS service so we were on the back foot throughout. We were, several times we said "Oh, our minds are blown," and what we actually meant was "We can't think of a thing to say."

Matt:That's funny. I remember probably about somewhere between 18 and 20 years ago going to a Microsoft conference where they had these Microsoft evangelists and they were bouncing all over the room, full of energy and isn't Microsoft wonderful and actually, you're right. He was all about the technology and different experience.

Richard:Which works for us.

Matt:Works very well, and you could absolutely see. If you're a big company out there and is thinking of making a major change in architecture, getting someone like that in, just to reassure you are doing the right thing, talk you through options before you start. I was very impressed in that respect.

Richard:So looking forward to episode 4, but let's get on with episode 5 then, and I think the main theme of this talk is going to be Kotlin.

Matt:Indeed, so Kotlin for those who don't know is another language that runs on the JVM and off the JVM as well, but we'll maybe mention on that. Why Kotlin though is pretty much because we went to a meet up last night. I think we've mentioned meet ups before, so these are community led get togethers publicised through meetup.com. There's loads of them all over the world and there's one that happens in Leeds which is where we're based called That JVM Thing. It's organised by a local recruitment agency actually, but it's interesting because you get to meet a lot of the big companies locally or people from the big companies working as active developers and last night was a session about Kotlin. I think might be worth commenting before we even talk about Kotlin, they started up the session by asking you to raise your hand just to see whether you were actively doing different things and I would estimate it's probably about 100 people in that room and of those how many people are coding up Java? Pretty much everyone raised their hand. How many people are being paid to code up Java? Again, pretty much everyone.

Richard:We didn't.

Matt:And then they talked about other ... Right. They talked other JVM languages so Groovy, Scala and then Kotlin and what was interesting actually was that certainly Groovy was there. I was surprised how many hands were raised up actually for Groovy. Scala, again, had a handful. Wasn't a massive amount and maybe this is stupid to say because it was obviously the topic of the talk but there were more Kotlin developers or people experimenting with Kotlin.

Richard:Right.

Matt:The number of people being paid to develop Kotlin was smaller.

Richard:Okay. That was a very small yes.

Matt:But I found it an interesting talk and we're certainly, or I'd like to go away now and build something with Kotlin, so let's talk a bit about I guess what we discovered, why it's something that might be of interest to our listeners.

Richard:Yeah, so the chap who presented Kotlin. Are we allowed to name him? I mean, we don't know him, so ...

Matt:Well, his name's publicly on the internet on the meetup site…

Richard:And of course, we'll put on the show notes a link to his slides so this was Andy Bowes presenting for The JVM Thing. I forget which company he works for.

Matt:I'm trying to remember as well. If it comes back to me while we're recording, I'll say it out loud.

Richard:Right-o. And what I don't know is. The crux of his presentation was, I mean, we'll talk about in a moment why we think other JVM languages exist. Why don't we just stick with Java? But the way he structured the presentation was, Josh Block has written one of the best books on Java called Effective Java. I'm sure many of our listeners will have read it. If not, definitely buy a copy.

Matt:Well, should you not buy it just yet.

Richard:Just hold off because yeah, it's in edition two and that's been out for years and edition three is due out in October. But, yeah. Every Java developer should have a copy of this book.

Matt:Can I just say before we go on, Richard is holding a copy right now.

Richard:I'm touching it. I suspect I'm going to need it many times on this podcast if we get technical and so the angle of the presentation was there were many best practises that Josh Block identifies, some like 75 rules that you should follow and he was saying that Kotlin has absorbed those rules, so Kotlin has the, you don't really need to follow these rules anymore because Kotlin will make you follow those rules. Now what I don't know is, is that just his perspective or have the Kotlin, the people invented Kotlin, did they sit down and think the way we're going to design this language is by following Josh Block. I'm not sure which of those two it is.

Matt:No, I mean, the inventors of Kotlin are Jets, the people behind Jet. Sorry, JetBrains is the company so it's the people behind the IDE called IntelliJ and as I understand it from what was said last night, it was they created this language because they were having issues with Java and therefore wanted a language that better suited their needs, so part of the IntelliJ IDE is developed in Kotlin. That's where it came from. They subsequently open sourced it. The way he described it is that what Josh Block identifies as being best practises are really weaknesses in Java that he believes are a good way of overcoming those weaknesses and so he presented it as Kotlin overcomes these several weaknesses of Java.

Richard:So it's almost like by accident rather than by design.

Matt:I don't know.

Richard:In fact they haven't slavishly followed Josh Block or anything like that but either way it was a very nice way of structuring the presentation I think. It was very good, so throughout you would have a slide again, they'll be in the show notes, but he put a slide up. He'd show a bit of Kotlin code and at the bottom he would put a reference to, and this is upholding item number 74 of Josh Block. A nice way of doing things.

Matt:Yes.

Richard:Good on you, Josh and good on you Andy.

Matt:So, I guess the first thing possibly just to mention then is that it's made by the people who make the IntelliJ IDE and although there wasn't a demonstration of it in IntelliJ particularly and we haven't had a chance because this was literally last night to have a look at it in any detail. It seemed that there were a lot of, there's a lot of functionality built into IntelliJ specifically to aid your development with Kotlin, so as an example and they were stressing you probably wouldn't use this much, but it just shows the power. Kotlin is fully interoperable with Java and one of the things you can do is take some Java code and from what I understand highlight it, click a button in the IDE and it will convert it to Kotlin code.

Richard:Yeah.

Matt:So that level of functionality's built into that IDE and he did say of course one of the reasons they've open sourced this and they want people to take on Kotlin is because it will hopefully help them sell more copies of the IDE.

Richard:Sure, sure.

Matt:Which makes sense.

Richard:I think that's a good thing as well. We need commercial pressures like that to make people innovate and we could get political and talk about why the development of Java is so glacially slow. There were several points made in that talk about, there was some really good features in Java 10 that we're waiting for and we have no, there's no road map. We have no idea when Java 10's ever going to land and we can't wait that long for really important features that should be part of really any modern language.

Matt:Absolutely.

Richard:So, the fact that JetBrains, I don't know a lot about JetBrains, so I did a little bit of dealing with them about, gosh, a long time ago, maybe 10 years ago and they came across as thoroughly, really nice people, but they are true developers so they know what it is to develop code. They're not committee managers and so yeah. They innovate.

Matt:So one of the things I want to go off and do anyway is just understand how Kotlin might work with other IDEs, so we've done all of our courses with the exception of the Android course which we're going to mention Android in a second, but we've done all our courses using Eclipse and primarily I guess because it's free, it's easy to obtain and it is used in production environments.

Richard:Well, really all the IDEs now are free and easy to obtain. Most of them anyway.

Matt:Well, so IntelliJ has a community edition which is free and easy to obtain and Kotlin is fully integrated into the community edition and they have a professional version which you can buy a licence for. Now, I'll confess. I've only ever attempted to use IntelliJ in recent times to work with a Grails project and unfortunately I was using the community edition and Grails integration is really only supported in the paid for version, so depending on ...

Richard:And unless you've done Grails it might be difficult to get that across, but you really do need some commercial tooling to help you with that but I would say that's an exceptional case. Oh, and Android as well, possibly, but if you're working on a Spring project for instance, the community edition will be beautiful. We're planning a future podcast on IDEs. I'm not actually sure if we will have enough material to fill a podcast to be honest, but it is a controversial choice. We fairly regularly get people saying well, why aren't you using IntelliJ? And the reasons why was just at the time the company launched, Virtual Pair Programmers launched, it was by far and away, Eclipse was the most commonly used on professional projects, so it was just sort of a no brainer. I think probably NetBeans would have been the big competition then. IntelliJ was kind of a distant third. My sense, as usual, I don't have figures but my sense is that IntelliJ are really knocking the ball out of the park at the minute. Really kicking some backsides and doing really good business I think.

Matt:Yeah.

Richard:And really coming up.

Matt:It does seem whenever we go on these sorts of meet ups where you meet lots of developers who are actually doing development at the meet up so we go quite regularly to another one of these meet ups where they set you a programming challenge and you choose what language you're going to do it in for that thing and a lot of people there are certainly using IntelliJ aren't they?

Richard:There's a very real sense, again, I'm probably using material for a future podcast here but there's a very real sense that Eclipse is, you know a, how to put this the right way but you're not a proper developer if you're using Eclipse. Proper developers are IntelliJ.

Matt:It's a bit like if you're going to edit a text file. Unless you're planning to use, what is it? Emacs or vi whatever it's called, which I cannot use. I always Pico or Nano. I can't use that awful editor but that's what make you a proper developer. Yeah, I get that.

Richard:We'll save that for a future, and ...

Matt:I'm sure you can do Kotlin on any of the IDEs.

Richard:You can, but IntelliJ's tooling will naturally be ...

Matt:Yes, the place to go I guess, and the other thing though is, as we said, is not just IntelliJ, but it's also Android Studio which we use on a couple of Android courses and Kotlin is available as a, what do they call it? A first level language now for Android development. It didn't sound like actually it's fully there just yet, but it's pretty close.

Richard:Okay.

Matt:Now, we have a little bit of Android. We're not planning to do much more on Android and they were stressing that it's not just for Android. It's for backend server development as well. You could build rest web services with Kotlin and if we do a course on Kotlin we'll look at some of that probably more from the backend side. But the, what they were saying was the fact that Google have made it a first level language for Android will obviously help its adoption and also it's available out of the box now for Spring Boot, from the Spring initializer so it's very easy to get started with a Kotlin application.

Richard:And it will be very tightly integrated with Spring 5 as well.

Matt:Yes.

Richard:I believe you can configure your, so the equivalent of Java config which I think is absolutely horrible in Java is not a good tool for doing configuration. Kotlin much cleaner and simpler. I think I haven't seen any of that yet. I will have soon but clearly it's very well supported, Kotlin is. It has some big players behind it and all of the big frameworks are in some way, things like Maven and Jenkins according to the slides. We haven't tested this but according to the presentation, they're just supported. It'll just work.

Matt:I mean, to be fair, he did show a Gradle script working with Spring Boot, didn't he? But I mean, I suppose it's worth saying then so I want to talk actually about why would you even consider another language and why Kotlin, but before we get to that, it compiles to completely compatible Java byte code so you can create jar files. He didn't mention war files but I'm sure if you can create a jar file you can create a war file and he was saying fully interoperable, so you can call Java code from Kotlin code, Kotlin code from Java code, and then we'll talk about what's wrong with Java if you like and what they've changed but he explained it brings together some of the best features of other JVM languages like Scala and Groovy and you could certainly see some of that included there.

Richard:If you've done any Groovy for example and we have a Groovy course. I always have to put a plug in for our course.

Matt:But we like Groovy to be fair, don't we? We do a lot of Groovy work.

Richard:Groovy has its faults, but once you've done a little bit of Groovy, you start thinking functionally and things like closures become every day and become natural and so many things in Kotlin are recognised from Groovy and it's like a no brainer. Great. I'm glad that's in there but I don't have to worry too much about it and yet one of the things that if you've done Groovy, one of the things that differs if you like, which just felt nice to me, was the fact that it's a statically typed language, so every variable is defined as a string or an integer but it has, what was the word, inference.

Matt:Type inference.

Richard:So you don't have to say this is a string, but there's no concept of the dynamic typing that Groovy has which is a nicer way of doing things, I think.

Matt:Well, it's a very bit of a religious thing to whether you prefer dynamic or static typing and my first language was one of the most statically typed languages that's ever existed, so I'm very much into that way of thinking.

Richard:I enjoyed working with Groovy and I enjoyed the freedom that the dynamic, the duck typing gave me but I never felt comfortable, I was always nervous that I'd mixed object types up somewhere and you do with the best will in the world, when you're running Groovy code. I'm not having a go at Groovy, I'm just talking about dynamic typing you are at runtime going to get more runtime exceptions that would have otherwise been caught at compile time in a statically typed language like Java or Kotlin, so I'm going to feel more at home with Kotlin than I ever did in Groovy personally.

Matt:Yeah. Some of the other, let's just mention maybe two or three then of the other things that impressed you or I about Kotlin compared to moving from the Java starting point. One of the things I quite liked was if you're creating a typical Java class that's going to represent an object, so you've got data fields, we always create a hash code, an equals, a toString, constructors, all of that, in Kotlin is done for you. Now he was making the point that all IDEs can generate that code for you as well, but the point is that you don't generate the code, so if you're creating a plain old Java object, a POJO class right now in Java, sorry, if you're doing it in Kotlin rather, you would literally have your list of your fields. Your attributes for the class. Everything else exists out of the box but you never see it and the nice thing about that is if you then create a method in that class, when you go to review your code, that method isn't hidden amongst all the junk of your getters and setters and your toString and so on. There's other benefits to that as well, but to me that's nice.

It means you can glance at a class, I mean, I'm sure everyone does. We have classes where you know there's a method in there somewhere but you're searching and searching to find it.

Richard:I think, as a rule of thumb in programming, it served me well for 25 years and I'm sure it'll last another 25 years, is anywhere where you have to generate code there is something really badly wrong. Generating code is a bad fix for a problem.

Matt:Yes.

Richard:And I was slightly surprised that the presenters last night were all very, they were being very careful to explain why it's not a good solution to just right click and generate equals and hash codes and all that. I didn't actually sense any antagonism in the room and I don't think there should be but clearly it's the case that a lot of programmers are very happy with that. I can generate it. I don't need to go to another language but he was preaching to the choir last night I think definitely that ...

Matt:Absolutely. Yeah.

Richard:... boilerplate code is just the worst. Ruins a language.

Matt:Indeed. So that's one of the nice things. I guess the big thing for me is it does a lot to reduce the likelihood of getting null pointer exceptions.

Richard:Right.

Matt:Now, we're going to get a bit in knots here if we try and talk about this too much, so I'm going to have to be careful, but when you define a variable in Kotlin by default, if you set up a string for example, by default that string cannot contain a null value. You have to explicitly say that this is a nullable string.

Richard:Yes.

Matt:When you define it and there is a, it's a very easy syntax to do it. You're just using question, and adding a question mark on to do that, but the combination of that, so by default you can actually specify variables can't be null and also that it has, I'm pretty sure this comes from Groovy, doesn't it? The ability to, when you've say got an object, you're doing object.property, you can do object?.property which then would return null if the object is null or so it's a way of avoiding a null pointer exception. You can say this could be null and if it is that's okay, but you can chain them in Kotlin. You can have a whole long string of object?.method?.whatever which is very hard to explain orally, which is what we're trying to do here, but there were features there that are built in to minimise the risk of getting a null pointer exception and I like that.

Richard:I'm slight, I'm always slightly concerned. I mean, you probably know this from Groovy that you get a null pointer exception and so you go and look at the code that generated, that raised that exception and I've seen it happen. I don't do this, honestly. I've seen it happen where I would just slam a question mark in and then the null pointer exception goes away and actually all you've done is you've just moved that null up to another level. So I get slightly concerned when I hear that, but actually I think the, yeah, the fact that a variable is not nullable by default is a very good pattern.

Matt:Yes.

Richard:I must admit I haven't picked up on that until the talk last night. I hadn't noticed that in Kotlin before. I think that's a very powerful ...

Matt:It forces you, as you're building your variables, to think about ...

Richard:Exactly.

Matt:... will this ever be null?

Richard:Exactly. And really, it shouldn't be. Why should a variable be null? It means there's nothing there. Why is there nothing there?

Matt:Well, if you're creating a customer object and you've got the date the customer left and they haven't yet left, how would you deal with that without it being null?

Richard:Well, there's better ways, isn't there? Null is a bad, it's just, you know…eugh.

Matt:Don't know how well that comes across on a podcast but ... You can't see Richard's face as he makes that noise.

Richard:It's woolly. It's woolly thinking to use nulls and especially methods that return null. That I think is a very bad ... If you've got a method that says it's going to return a customer object, then it should return a customer object. Returning null is just… well I’ve failed but I can't, I'm not bothered, have a null, and that's where null pointer exceptions arise.

Matt:Yes.

Richard:So there's a lot of woolly thinking around, and the fact that they're tightening this up. I mean, obviously Scala's done this and other languages have done it, and actually one of the sort of, it's not quite, it's more a pattern and I think it's in Josh Block's book where he suggests you shouldn't return a null. You should return an object representing a null and therefore sometimes just moves the problem up a layer, but so yes. It's good that this is built in and it's being thought out properly.

Matt:Interestingly of course, Kotlin has an object that represents a null.

Richard:Exactly.

Matt:So it's everything, let's not go into ...

Richard:No, we're not going to do that. If you want, again, we'll put the link on the show notes but try.kotlin.com is fantastic. That is a brilliant webpage with a built in IDE where they have worked examples down the left hand side and the guy last night said it would take about a day to work through it and you'll be a reasonable, if you're coming from Java, actually you'll be a decent Kotlin developer by the end of that session, so it's as easy as that to get started.

Matt:And I guess actually a part of that then is that because it's sort of built on top of Java if you like or you can think of it that way in your head is because it's fully interoperable and you can convert from Java code to Kotlin code that the point then is that although you can do that, it's not idiomatic Kotlin. You shouldn't be doing it and there would be a great example there which is there wasn't too much detail on this last night and I don't know if this one of the things that's in development in Kotlin but whereas you might do threading in Java, they will have a different concept to do it in Kotlin of asynchronous calls and so I didn't got a sense of whether that's still in development or whether it's there just yet, but it is obviously an evolving language still, but the other big thing I guess is functional programming. We covered that in our advanced Java course when it was launched in Java 8 and it is, having done functional programming with Groovy, certainly the Java version is a bit of a fudge in a way. To achieve functional programming, you're implementing interfaces, right?

So, it's a little bit of a fudge to make it fit within the Java language, so Kotlin have done it in a better way, so you have the genuine choice of object oriented, functional or a mixture of the two in a Kotlin project and it looked quite nice.

Richard:It's funny that, and his slide last night, if I remember right, he said that functional in Java is a bit of an afterthought. Actually looking at the slide right now. It's right in front of me. But, it is a funny thing that and I must admint, I was very, very impressed with the implementation in Java 8 - Lambdas. Very impressed. I thought it was going to be a dog's breakfast. A bit like generics was. A total mess. And I think they did a pretty good job and yet I can't quantify this at all, but when I am doing day to day Java code, I never think of using lambdas. It just doesn't feel, it doesn't occur to me to use it and then I switch to something like Scala or Groovy probably for us more likely, and you're banging in closures around all over the place.

Matt:So, but I think that's because within, say within Java, unless you're using Streams, your closures can't mutate the value of a variable. Now, the times when we tend to use closures, or at least when I tend to use closures in Groovy, it's completely something to do with calculation. That tends to be a typical example. It's not always, but the fact you'd have to use a Stream in Java to do that just makes it's that little bit more complex.

Richard:I must admit I still don't fully understand the Streams business in Java.

Matt:Again, that's an illustration of how it's yeah. It's something of a fudge as you say in Java and certainly looking at the code last night, it just, in Kotlin functional very natural, quite straightforward.

Richard:And very readable, so even if you have never seen Kotlin and somebody shows you some Kotlin code, you're coming from a Java background, yeah, you need maybe a minute's worth of explanation of a couple of the keywords, but you can read that code and understand what it's doing. It's very readable. Perhaps the only, we've gone back to I think it's called Pascal style declarations where in Java it's C style which is int variable. In Kotlin, it is like function colon datatype.

Matt:So it's variable colon datatype.

Richard:Variable colon datatype. Yeah. So back to the Pascal days.

Matt:But of course, you don't have to specify the datatype because it can be inferred, so that's optional, but yes and I wonder why they made that choice actually because it is a different, that is a very different structure and ...

Richard:Scala does that.

Matt:... that is consistent so even when you're creating a method which in Kotlin is called a function.

Richard:A fun.

Matt:Or fun. Yes, exactly. Kotlin is fun, full of fun. The structure of that, so you're, whereas in Java you would be doing your return type before your method name. Well, I think in Kotlin it's the other way around. The return type comes at the end of the method name, so yes. I'm looking at an example from Andy's slides on screen actually which is creating a method called toCamelCase. The return type is a string that comes at the end of the function declaration line rather than at the beginning, so it's a consistent restructuring there. But that's very easy at least to see it and understand it and I'm sure you'd get very familiar with that very quickly.

Matt:So interesting. So I think we're certainly, well I'm planning to go off and, I've actually got a little project to do anyway to do with one of our internal reporting modules that we use which I’m going to have a go at writing that in Kotlin just to experiment with. Certainly, I sat there last night thinking this looks really good. It's got all the pleasure of Groovy without the pain and there's obviously more to it than that but ...

Richard:I have to mention the S-word. A few people, one of the questioners was clearly a Scala expert but other than that, Scala wasn't much mentioned but one of the presenters, can't remember if it was Andy or the other guy that was presenting said, it was quite a nice pithy little statement of well, Kotlin is being developed by software developers who develop software, not some academics. I'm sure that must have been a dig at Scala, so it feels to me very much like this is Scala but just made a bit gentler.

Matt:Yeah, I think that was the second guy which might be interesting. So, the second guy worked for a major broadcasting company that has a very big development centre in Leeds where we're based and they have created an app in Kotlin. So they're using it in a production scenario for Android development.

Richard:And they are recruiting, so we can say who they are, can't we?

Matt:Yeah, I'm sure we can. They're called Sky.

Richard:Which is, so that wouldn't be known real well with it.

Matt:I'm not sure, so they run the only major satellite television broadcasting company in the United Kingdom and they also run that throughout Europe I believe, but they also provide broadband and telephone services, all that kind of stuff, in the UK as well, but they commission television programmes. They have their own television channels, so they're very big.

Richard:And the way they did it and this is the way it's going to be I think for most. I mean, no one's going to switch to Kotlin for their entire development overnight and convert all existing code, so they had one area, one subsystem or whatever, that they built purely in Kotlin from the ground up. I think it was they're “my account”.

Matt:That's right. So it was like this sort of billing type management app. There was an app that sits on your phone that the customers are going to use.

Richard:Yeah, and they've clearly enjoyed it and sounds like they've developed it far quicker than they would have done it in Java.

Matt:Yes, he felt it would make them a lot more productive simply because you write less code because of all this boiler plating. If for no other reason, I'm sure there's other reasons as well, but he felt it was a very easy learning curve and they are very pleased with it.

Matt:Which again, is nice to see something like this being used by a major company in a production environment. It gives you the reassurance it's a stable language that you can actually start switching to and using.

Richard:We got to be a little cautious. New things always have this honeymoon period where everything's wonderful and we're going to be this much quicker and only when you're a couple years down the line do you start to feel, I mean, I felt exactly the same about Grails a number of years ago and you won't find me evangelising about Grails these days, and to a lesser extent Groovy as well. So, we've got to be a little bit cautious I think not to get too fan boyish about it.

Matt:I agree, but what, I guess the fact that Google are effectively now promoting and supporting Kotlin means that, this is always the question, right? Do you adopt something like this? I mean, we adopted Grails years ago and unfortunately the Grails project has for various political reasons, very much faded into the background and nobody's starting a new project now. Well, I would assume very few people starting a new project now would go to choose Grail.

Richard:Controversial.

Matt:Controversial.

Richard:We're going to get letters from the Grails people. That's bad.

Matt:But you know, we said on our Groovy course, there will be a Grails course coming soon. Now that course was written a few years ago and we never did the Grails course. Actually at the time, we were waiting for a new version of Grails to come out and Grails was known for each new version broke something. It was never forward compatible and the new version got delayed and then actually in that process we saw the community having a severe decline, so it never became a viable course for us to do.

Richard:And that's what you don't know in advance that that's ... I do think that the way Grails, and I'm not sure about Groovy. I mean, you've got to have breaking, a vibrant language has got to have breaking changes. Java has been, I think it's very praiseworthy that Java have been very good at not having breaking changes and this is one of the reasons why Java's development is so slow. If you want to add anything new to the Java language you've got billions and billions of lines of legacy code to consider. How does it fit in with all of the other things? But they have been really quite admirably reluctant to break things.

Matt:Until now because Java 9 is going to break things.

Richard:Well, we're still not clear are we what the extent of the break is, but ...

Matt:No. I mean, well they were talking about they've got in a command line switch to allow you to not break it for now, but by Java 10 it'll break. It seems so. We don't know where that's going to go.

Richard:Still don't understand that fully, but certainly until now they've been very admirable about that, but a downside of that is you end up with lots of cruft and lots of things that should be removed, so striking a balance is probably the right way to go and certainly with Grails, their attitude to, I forget the version numbers but 2 point something and then 2 point something plus one, so it's a point release would break everything because they've renamed a package somewhere and they've broken every single plug in in the world for Grails and it's that kind of mismanagement that I think caused them to lose the goodwill and so we have to hope this kind of thing doesn't happen with Kotlin. I'm sure it won't. I'm sure it will be well managed but it's, what I'm trying to say and I'm stumbling around this a little bit is it's things not at the technical level, the important things in the future, so I hope it's going to be well managed.

Matt:Yes. I guess one of the other things that will be as Java updates because this is compatible with Java, it's got to update to stay compatible and one of the things that was being mentioned last night is that on the Android platform, Android, or the most of Android is compatible with Java 6. They never moved a lot of it onto 7 and 8, so my understanding and I'm not an expert on this by any means, but I certainly got the impression that one of the issues on the Android side is that you can't do, for example, lambdas on an Android application because that functionality's not in the version of the equivalent to the JVM that sits in the Android platform. They're sort of stuck on Java 6. Now, I'm not entirely sure on that, but there was some issues around that which Kotlin sort of solves because they're explaining that Kotlin has extra libraries to use everything in Java 6 and the Java 7 and 8 features, so it was bit confusing that for me, but I guess, the issue with Android actually of course is that you've got older devices that can't be upgraded which you are trying to build.

Of course, when you build an Android application you have to specify the version of Android you're building for. Well, if there's a significant number of Android devices that can't be upgraded past Java version 6 compatibility and that is probably a majority still, that's your issue, I'm guessing, so anyway. So we're getting a bit technical about things I don't really know, so I should stop talking now.

Richard:Well, if we're running out of steam on Kotlin, I thought we're going to get a lot more technical, things like final classes. That was the thing that really peaked my interest last night.

Matt:Okay.

Richard:So all classes in Kotlin are final by default.

Matt:Yes. And variables can be defined as immutable or mutable.

Richard:Oh, absolutely. I mean, that today has to be a, can I do a rant here? Because this is where Java's going so wrong. There are fundamental low level features that should be added and wouldn't be breaking. You should have in this day and age, support for immutable variables and yet Java doesn't have it and it doesn't look like it's ever going to have it, and why can't they add that? They can't use backwards compatibility as an argument against it because they're doing the Jigsaw stuff, massive ivory tower re-engineering and yet they can't sort out things like that, so yeah, we've got to go to languages like Kotlin or Scala just so we can have a keyword val and a keyword var, so we can decide do we want this to be a variable or do we want it to be an immutable.

Matt:Yes.

Richard:It's a no brainer today in a language.

Matt:Especially, it's obvious that if you're thinking, I mean, how much of our work now concurrency is important. You're building websites. You've got to have immutable variables.

Richard:And I'm sure some people might be thinking well, we've got final, use final in Java. Now we won't do it here because it's not the right medium but on our advanced Java course we talk about why final is absolutely not, is not doing what a lot of people think it's doing. You can't finalise on it. You can't make an object be immutable is Java. All Java objects are mutable unless you very carefully designed it not to and it's just awful and it needs language support, but not in Java. So, yeah, all classes are final. I'm trying to tease you on this one but that was ... So, yeah.

Matt:There's a lot obviously to Kotlin and we've just touched on the very basics here clearly because what we've had is one, well all I've had is one presentation.

Richard:Well, I've gone through the try.kotlin.com is as far as I've gone and every bit of it I thought, yep, that's good. Yeah, I need that. I want that. Lovely. I don't remember any kind of clunking of gears where I thought, oh, what have they done there? I think the only thing I bristled about was that classes are final by default. So I'm going to draw you into this. Classes are final by default in Kotlin. In Java classes are not final. Now, I don't think anywhere in any of our courses we've ever talked about final classes ever.

Matt:Right.

Richard:And many development shops and interestingly Josh Block's book basically recommends that you should make all classes final and so I thought we'd do a little because we should do some technical stuff and so final, so we'll do the old thing of where you interview me and tell us about ...

Matt:For the benefit of our listeners, not for my benefit, so just remind us, what effect does making a class final have?

Richard:A final class means it cannot be extended.

Matt:Okay, so if I am creating, let's say for example, and I want to give a genuine example actually, so all I have is just what we use to manage our accounts, so we have a number of different bank accounts, so I have in the system the example of a bank account class and then I am extending that to create different types of bank accounts. That's what I'm doing, so how would you, if my underlying bank account class has got to be final, so I can't extend it, what's the reason why either that's a bad architecture or what would be the better way to do it?

Richard:So, oh dear.

Matt:I put you on the spot now.

Richard:It's not always a great, a podcast isn't always the ... I have always been in the camp of, I mean, there are sorts of two camps that inheritance should be open and the other camp is that inheritance should be closed, so open inheritance means if you write a class without any extra, a normal class, it should be extendable.

Matt:Right.

Richard:Which anyone could take it and extend it. And the closed camp think the opposite. Classes should be not extendable unless the author of that class has allowed it to be so.

Matt:Okay.

Richard:So they would have to put a key, and that's what happens in Kotlin. If you want a class to be extendable in the future you put the key, I think it is the keyword open.

Matt:Yes. Yeah. I think it was, yes.

Richard:The keyword open. Now, I've always been, possibly until last night actually, it kept me awake a bit this as well, I was thinking about this. I've always been in the open camp and my reasoning for that was how can you possibly know, you've written a class and you are now going to make this decision that I am going to allow future generations to extend this class or the opposite. I think this class isn't ever going to be extended. Maybe it's so perfect it could never be ... I could never get my head around well, how do you possibly have that information to whether a class should be open or closed? So, if we like inheritance and people want to use inheritance and extending and so on, then they should be open. That's always been my thinking till now really.

Matt:Till now. But my, so actually my challenge to you just there, in reality that underlying class that I'm extending from is an abstract class, so abstract classes are classes you can't instantiate. You have to extend them. So how does that fit within the concept of an abstract class? Should we be using those?

Richard:We'll come back to abstract, possibly. It's difficult this, isn't it? We'll come back to that possibly. They're the two schools and two camps basically and I think C++ that Java's syntax was based on was closed interestingly.

Matt:Right.

Richard:So, when I started in Java I was like wow, brilliant, great. I like the fact that it's open. Just out of interest, if you want an example of a final class in Java, the Stream class was declared final.

Matt:Okay.

Richard:Back in Java 1.0 and has always remained so and in the early days, so I used to use this example when I was teaching Java, in the early days I used this as an example as why this is a bad thing. Making classes final because we want to take that Stream class and we want to extend it and we want to specialise it and actually I confess it's a while since I've picked up Josh Block's book. I've had a good read of it now, so item 17 in Josh Block's book is design and document for inheritance or else prohibit it. Now, Josh Block is, I defer, Josh Block by the way was the man who designed the Collections API in Java, so LinkedList and ArrayList and all that kind of thing. He added that in Java 1.2. Before that it had been an absolute dog's breakfast mess of a collections library and he improved it and on a podcast, I won't go into detail. Read the book and he talks very interestingly about how basically when you're writing a class if you allow it to be extended it can break in very strange and interesting ways and things that I'd never thought of and he's got some good examples.

But actually I'll go all the way back to on our Java fundamentals course when we teach inheritance, we make this point, inheritance is coupling. Your worst enemy in software engineering is coupling, so you have class B extends class A. Those two classes are now welded together. You make a change to class A you may well break class B.

Matt:Yes.

Richard:Now when you write class A, you have no knowledge of what class B's going to be. You don't it even exists and of course, it's not just class A and class B. You end up with entire forests of inheritance hierarchies all coupled together, so actually I've realised, so I've had this oh, I prefer open inheritance so I don't see why classes should be final. I've realised abstract aside, we'll come back to abstract, I never ever use inheritance. So you're example of a bank account, a special bank account, never and I call that concrete inheritance to distinguish it from abstract classes. I'm not sure there is a formal term for it so I call it concrete inheritance. I never ever use concrete inheritance for that reason and I've realised oh, right. I'm actually doing this final. I just don't put it. I don't put it in as a keyword. I'm just careful not to and it is because it sucks as a reuse. People reuse, reuse. Oh, inheritance.

Matt:And interestingly, the reason I did it is purely because I would otherwise be repeating lots of code which of course, if this was done in Kotlin, this is the whole point is that you're not writing all this boilerplate code that you've got to reuse.

Richard:Oh, sure. If you've got a class and you want to reuse it and you reuse some of its proper methods, not its boilerplate then item 16 and this one is an absolutely, this is one of the fundamentals that's emerged over the last 20 years is you should favour composition over inheritance.

Matt:Yes.

Richard:It's a far more powerful way of doing things is for object B to use an instance of object A and in B you've got complete control over the interface and we can't do it here but again, check try.kotlin. There's built in support for delegation which again, should be in any modern language. C# did it years ago. There's language level support to allow you to pass through a method call basically from object to the other without having to write lots of boilerplate. So, that's just built in. So, I kind of realise although I was bristling last night. Oh, they've gone for closed inheritance. I've realised, well I've always favoured that as well, and I think it's a very good sign that when people talk about inheritance, concrete inheritance and these stupid shape examples and we've got a shape and a square and a triangle or you've got ...

Matt:It’s always insects, isn't it?

Richard:That sort of thing. Oh, yeah. And I confess that on our Java fundamentals course, of course we've got to teach it. Before you reject these things, you've got to learn them. We're doing a, I seem to remember we did a library and we've got special, you know, we've contrived it. We wouldn't have done it like that. There's usually no need for concrete inheritance. Now, abstract classes. That is a different thing and really what you're gunning for are interfaces, purely abstract, that's just method signatures. It's the implementations that are the problem. It's coupling with implementations. So interfaces are okay. Now abstract classes are sort of halfway house between concrete and interfaces and Josh Block talks about skeletal implementations, so in his Collections API, he uses abstract classes a lot, so we get an abstract List, which is a sort of a midway, it's got its interface at the top and then his abstract List has got some basic implementations at the very high level functions and then the concrete classes work from the abstract. That's okay but it's done very mindfully.

Matt:Right.

Richard:And I would say usually for domain modelling business purposes, you don't really need all this.

Matt:I can't remember which version of Java this came in but of course you can now put implementations in an interface can't you?

Richard:It can default implementations, so yeah. Actually that is a good point. I had forgotten about that. I think that's probably a good thing so yeah. Default implementation in an interface probably removes the need for a lot of skeletal abstract classes. So that's a yeah. A good point. Thanks for reminding me of that. And what I actually like about this is having gone to that talk that is has sort of just fired up this, gets you thinking again and old habits that I'd got into force me to rethink them. I'm very pleased about that.

Matt:Good. Good. Well, I've got say I found that a really interesting conversation. Thank you for that. Now we know. It feels like we ...

Richard:Now we know.

Matt:Now we know, so let's maybe just talk a little bit about what we're doing right now.

Richard:As usual, it's a sort of a traditional on the podcast that I mean, I hope that some of what came before would be useful to everybody and anybody working in Java but then we're going to talk to our customers towards the end of the podcast and talk about what we're working on and what we can expect from Virtual Pair Programmers over the next couple of weeks.

Matt:Do you want to go first or shall I?

Richard:So you've recently released ...

Matt:So we recently released Thymeleaf.

Richard:Brilliant.

Matt:Which has had some really nice comments actually from people. There was one guy ... I just have to say this because it was really nice. One guy out there who's one of our regular customers who has made the point that he's recently started on a new project, had never heard of Thymeleaf.

Richard:Wonderful.

Matt:And found he was able to get going really quickly and it was a project using Thmyeleaf obviously, and it's a nice thing to use, so that's nice. I've now moved on to starting on, we've always wanted to refresh our Java web development course. It's currently the oldest course in the library.

Richard:It is indeed. 2009 I think it's vintage.

Matt:Yes, I think it was. And it's been fascinating for me watching it back and seeing, because we, for example, reference websites like Amazon and eBay on it and actually Amazon hasn't changed much in its layout and eBay has but it's interesting to see some of that. So the course is going to be similar to what we had with some new additions and some go into a bit more detail. The way I'm looking at this course is very much you're never going to build a website using servlets. You're going to use a framework but to actually be really good at whatever framework you're using, you do need to understand underneath the bonnet.

Richard:I think so.

Matt:Under the hood, so this is going to be a ...

Richard:It's a debatable point, but yeah, I think so. Yeah.

Matt:Well, do you know what? I think it's a professionalism point. If you understand where this started, how the underlying things work, the interaction between a servlet and a JSP page for example. To me, that's a, it might not change what you do, but that level of knowledge brings you up a level.

Richard:It will also give you a very strong reason for why you wouldn't want to use JSPs in a model project because you've got Thymeleaf, but learning how JSPs are generated gives you a very good reason to avoid them.

Matt:Absolutely. Absolutely. So I'm currently in my scripting phase for this. So it's going to be, I'm looking at a couple of new topics, so hopefully we're going to talk about asynchronous servlets. We're going to talk about web sockets. I'm going to mention this. This may or may not make the final cut because I right now don't know anything about it other than that I went to a presentation about this recently which is something called progressive web apps which is a way of building more interactive applications that run through the internet, so more than just like what you'd think of as a web page, almost like having a proper desktop application, but that it can continue to work even if you're offline.

Richard:Right.

Matt:And I believe Twitter’s using this. It's particularly good for environments where data is or sorry, transmission of data quantities is restricted.

Richard:Okay.

Matt:So, third world countries. If you want to create an app or a website that's going to be used where there might not be huge amounts of great quality data connectivity this is the way to go. I don't know at this stage whether there are Java frameworks for it so I'm being bit hesitant but if there is I'd like to have a look at that and then we'll do a light touch on a couple of frameworks just to get a sense of I don't know which framework you might need to use. Obviously we cover Spring in a lot of detail. I'm going to be doing a refresh of the JSF part for JavaEE, but we'll probably pick a couple just to have a quick look at just enough to get you started but really I don't know what framework you're going to use. If you're going to use one we've not covered well, hopefully it's a framework that you can get quickly started.

Richard:There's so many of them that it's very difficult to ... and you think it's not that easy and there's a few sites that show. I noticed that GWT was very high up on the list and I thought that had gone away quite a bit.

Matt:Well, that list also had Grails very high up and it might well be widely used but as I say, it's not being, I would be surprised if it's widely used for new projects, but anyway, we'll pick a couple as I say, but this is more of a, I've got in my head this is very much more of a let's fill in the gaps in knowledge type course.

Richard:It's an entry level course and it should remain so, so I tell you, if the web sockets thing does get a bit complicated, I would just cut that out and make a standalone course on it. Don't get stuck on it.

Matt:No, the original course didn't cover Ajax but we covered it in one of our other courses.

Richard:It's on Spring MVC, yes.

Matt:Yeah. I'm putting in Ajax. At the same level of, it's a different example but the same level of complexity as we covered it in Spring MVC course. My belief is I can do web sockets at the same sort of level.

Richard:Okay.

Matt:So it's not going to be everything you want to know about web sockets. It's enough to get you started. That's my goal here.

Richard:Which is where that course, so yeah. Oldest course nearly ten years old.

Matt:Incredible.

Richard:And it's done well. And things at that fundamental level don't change that much. They don't move on. We've had people say "When are you going to cover servlets 3?, well we’re not that interested are we?

Matt:No, and actually other than the asynchronous bit, which came in in servlets 3, I don't think I've spotted anything else.

Richard:Well, there's the web.xml and the fact you can run without web.xml

Matt:Oh, of course, yes and we do cover that. Move into the annotation based configuration.

Richard:We kind of slight some people, so that's good. It will be good to refresh that, so that will make Spring MVC course then the oldest in the library and this is a problem we have. It's a bit like, I'm going to use a UK expression of painting the Forth bridge, that you are just constantly going round and we're going to have to keep refreshing all the old courses and how do we make new courses if we're still working on the old ones and I guess we have to abandon some don't we?

Matt:We do. I mean, we abandoned the old, we had some courses for JavaEE on running JavaEE 6 on the Glassfish web server which we had to replace. We were always in the process of replacing them and we've got some courses on Java EE7 with Wildfly live on the site right now but we actually had to abandon. There was one bit we haven't yet done which is the JSF part. We've had to abandon it purely because it's not compatible with Java 8 and every time a customer went to use it they were really struggling to get it to work. So, I am, once web development's finished I am promising you it'll be a very short module on JSF, just simply JSF PrimeFaces and on top some JavaEE security because we've not covered that either. Very quick. Just to get it done.

Richard:That can't be short enough. It's not possible to ...

Matt:And do you know what? I've had so few customers asking for it but I'm conscious there's a gap and I'd like to just fill that gap, so that's my plan but I won't give you a date on that one.

Richard:All right. And so I'm working on Dockers still. I have a sense I have a lot of angry customers screaming at me for it. You're telling me it's fine really, but ...

Matt:And then we have got some customers. They're not angry and they're not screaming but they're asking, so ...

Richard:It has, I've hit some really horrible problems not with Docker. Docker's great. It's really fun to work with and I hope the course will be fun to watch, but as usual with Virtual Pair Programmers we don't just want to rehash, you can go on the Docker.io page and there's the cheats for real on Docker and you can get going, a little bit like Kotlin, and we need to have more, we need some more, some deeper stuff and this is how you get something working on the production stack and it's when you start doing that, you start hitting problems, so I've lost a week, pretty much the entirety of the last week was stuck and all I was trying to do was deploy a stack of Docker containers to Amazon EC2 instances, a natural thing to do and it just simply wouldn't work and every time I got to a solution it wasn't that. That wasn't the problem.

There was lots of minor problems that weren't quite right and it took all that time to get to, I still don't know the exact reason but it's something to do with the subnet, so the subnet was misconfigured which ugh, really painful, really nasty. It's something to do with the Docker defaults don't work well on EC2. Now, someone with more intelligence than me would have said "Why are you doing all that? Why don't you just use Amazon ECS?" Which is a built in service to Amazon, Elastic Container Service and you can just do it. It's a wizard. Click, click, click, click and there you are, you've got a Docker stack. Well, I don't want that. I want people to know how you do it manually. How all this stuff works without relying on Big Brother Amazon doing it all for you. Great. By all means, once you understand it, go over to Amazon but we want to teach people how to stand for their own and for themselves.

Matt:Absolutely. Yeah.

Richard:So, it's kind of like we have to go through that pain so that our customers don't have to which is a bit of a marketing message I suppose, but in reality our customers are going to find their own set of problems as well that they've got to go through so there's going to be a video on that course definitely which is right, I've got a problem. How are we going to solve this and we'll go through that entire war story. So, that's a waffly way of saying I am delayed for those kinds of reasons. I think on the previous podcast I said this is probably the plan anyway. I've got to release something, so I think what I'll do is I will release a basic Docker course. This is how you run a container. This is how you push a container to Docker hub.

The basics and we'll just release that as a warmup, so there will be a lot of people saying "Come on, we can do more than this," but I think, I mean, in my head I'll be mentioning that everybody's already using Docker and it will be "Well, that's rubbish," but I think a lot of customers will find that a nice good useful, gentle introduction and then in part 2, which I mean, it's written and I've got the stack running and we'll be using the fleet man application that we used in the microservice course, which I have improved a little bit. I've made it look nicer and I've used Thymeleaf on the front end thanks to your excellent course but I don't want people to get, I mean it was, the microservice course was too hard frankly and I don't want people to get in that mire again, so basically we'll have some pre-configured containers already contained in the running system and you'll just download those containers. It will be a gentler course to work on.

Matt:Okay.

Richard:But yeah, so the part 2 will be a little bit more this is Docker in the field so that's where we'll do Docker swarm, Docker stacks and all that kind of good stuff, so it's coming very soon. I'm not going to put a date on it, but the website says released in July, so that should be okay. It should be released in July for that first part.

Matt:Okay.

Richard:The second part shouldn't be too long after that, so we might hold onto it. If you've got a release coming, we might just stagger it a bit.

Matt:Okay. Just to make it clear to people, if it's not obvious. We are very much about making sure we understand it and we can get it working. We're not here to regurgitate books and just teach you what we've learned, so everything we do, we are creating our own projects first if it's not something we already know. With Thymeleaf, I created, I have just a need to create new system, so I thought well, I'll do that in Thymeleaf. It's a great way to learn it. You find all the pitfalls that way, which actually, to me, what we're about is, yeah, taking the pain away but also getting you up to speed quickly and we can only do that if we go through the level of pain ourselves, so if you are out there waiting, apologies, but it will be worth it when it comes.

Richard:It might not be. We'll see.

Matt:That's a really positive way to wrap up, isn't it?

Richard:We'll let the market decide. We'll let the customers decide. I'm sure it will be brilliant.

Matt:Great. Okay. We'll I think we're probably getting close to our time. Our cut off point.

Richard:Fantastic, yes, so next podcast will be in two weeks this time because this will not have to be checked by the lawyers.

Matt:Well, it might be sooner than that if we get the okay back from Amazon of course.

Richard:Oh, right, so that one we could use as a ... Yeah, all right.

Matt:Well, we'll keep the numbering as we said, so that will be number four. This is number five. But they'll probably be released in not quite the right order.

Richard:But number six will be in two weeks.

Matt:Yes. So around about then.

Richard:Whatever happens to number four, we'll do number six in two weeks.

Matt:Absolutely. Good.

Richard:And around that time, Spring 5 is close to being released, I don't think it's actually out yet, but it's the Reactive framework is going to be the big deal in that, so we need to talk Reactive.

Matt:Reactive in the next one. Good. I look forward to that.

Richard:So, we'll see you. We'll speak to you next time.

Matt:Next time. Thanks for listening if you've been with us and of course, as always, any suggestions, things you'd like us to talk about, anything you want to say, please do contact us via the webpage. That will be great.

Richard:We can't return any of your letters.

Matt:Thanks for listening.

Richard:Bye-bye.

Listen via:


Be notified of new posts