All the latest news and views from the world of Java

The Podcast

Podcast 2: All things Java

31-May-2017 in Podcasts

In this second podcast, Richard and Matt talk about the upcoming JavaEE 8, what it is to be a full stack developer, langauges such as Kotlin and updates on progress with Thymeleaf and Docker courses.


Richard:Yes. How do we start, then?

Matt:We should actually start with you saying, "How do we start?"

Richard:How do we start? Hello, welcome to the second Virtual Pair Programmers podcast, covering all things Java. I'm Richard Chesterwood, and here is ...

Matt:I'm Matt Greencroft. Hello. Nice to speak to you again, Richard. That doesn't sound genuine at all, does it?

Richard:It was even worse than last week, I think.

So what's happening in the world of Java, Matthew?

Matt:Well, I know the big news is ... And I know it's big news because we were talking about it just before you pressed record ... The big news is that yesterday, the ballot review process started for the latest JavaEE specification, JavaEE 8.

Richard:Wow. That's really exciting.

Matt:Yeah. I'm not sure how exciting it is, but would you want to talk a bit about ... Should we talk a bit about what's in JavaEE 8 and whether we should be excited about it?

Richard:Well, the last I looked was probably about three months ago. I do not keep my finger on the pulse of what's happening in JavaEE, as it's a very long and slow process, and I think unless you are probably a member of those committees, it's very difficult to track what they're doing and where they are in the process. For instance, do we know when this is due to be released? It's kind of hard to unpack all of that, isn't it?

But the last time I looked, they were making noises that JavaEE needs to be more relevant for modern development, so they were thinking mobile, they were thinking microservices, that kind of thing, and they were talking about removing things like JMS, the Java Messaging Specification, from the standard completely, which I thought was hilarious, because JMS can actually form the backbone of many modern microservice-type systems. There are a lot of other things out there, there are a lot of alternatives, but to say that it's not modern and relevant is nonsense, really.

But it seems they've gone back on that. We've had a look at what's due to be in.

Matt:Yes. So it looks like JMS is still in.

Richard:Basically everything. They're talking about removing some really horrible old dated stuff. EJB 2 is finally going to be removed, which I can't believe anybody on the planet is using, and there was a lot of CORBA stuff, very legacy 1990s-type stuff. We don't need to go into detail about what CORBA is. I think we cover it ... We must cover it somewhere.

Matt:We certainly talk about CORBA when we are first introducing the concept of an EJB.

Richard:Yeah. We touch on it.

Matt:We touch on it, yeah.

Richard:So a very dated, legacy way of working, really, so that's going to be removed. Other than that, it all looks like it's still in, including, interestingly, the MVC framework.

Matt:I'll confess, I was actually alerted to this because I'm working on Thymeleaf, and the guys behind Thymeleaf make a point of saying that when the MVC framework does come in, they expect Thymeleaf to be made compatible with it. So you'll be able to use Thymeleaf as an alternative to JSP, or possibly JSF. We might look into that, but as an alternative way of creating your views using JavaEE. But the fact that the specification is coming close to completion, if you like, or approval, and there's a reference implementation available, we believe ... isn't there Glassfish 5?

Richard:Oh, sorry. I thought you were talking about MVC or-

Matt:No, of Java EE8-

Richard:Of the whole JavaEE. The reference implementation for MVC specifically, though, is called Ozark. Ozark. Have I pronounced that right?

Matt:Who knows? Could be Oz-ark or-

Richard:Ozark. So you can, if you're interested in learning this stuff early, you can go and get the reference implementation now and start work on it today.

Matt:I guess the other providers of application servers ... We use WildFly as the Java application server on our courses, so ... WildFly's JBoss, isn't it? So I guess JBoss ... I'm not saying anything publicly at the moment about when they're going to create a Java EE8 version of an application server until it's actually finalised and they ... I don't know, but I've not seen anything.

Richard:Again, that's the kind of thing we don't keep our finger on the pulse of that, because we've got lots of other stuff to do as well. So I don't know where WildFly is. I don't know how long it will be before they release Java EE8. I haven't got a clue at all, but I am interested in the MVC, I've got to say. I know a lot of people are very ... dismissive isn't quite the right word, is it? Or just dismayed, really, that here in 2017, MVC is being added to JavaEE. MVC kind of has a feel of being a bit old, a bit dated, and a bit ... It's not something that we're excited about today. It's a solved problem. It's a long-solved problem.

What do you think?

Matt:I guess it comes back to who uses JavaEE as the basis, as the framework, if you like, for their applications, and why. The fact that you're using JavaEE doesn't mean it is the only system within your architecture, does it? It could well be that you are using JavaEE as your base system. You're using messaging as the principals, but actually your web front end might not be-


Matt:- running JSF, for example.

Richard:If you have a web front end. So yeah, and this is why, although I'm not a fan of JavaEE, as you probably know, and I'm certainly not a fan of JSF, the reason for JavaEE's existence is, if you're running a project and you decide, for political reasons, for whatever, for safety reasons maybe, "We want to be standards-compliant ..." And JavaEE isn't really a standard. It's the de facto standard. It's not a legal standard, is it? But it's the closest we have to a standard. If you adopt JavaEE, what you're getting is the comfort that you know you're working to agreed standards, and some module that you rely on isn't going to suddenly disappear, their GitHub page vanishes and all that kind of thing. So you're looking for the comfort of knowing that you've got a large set of agreed standards.

And for me, it's been an absolute nonsense that never, in all years of JavaEE's existence, can you build a simple MVC front end in a standards-compliant way. It's just not been there, and okay, it's far too late, but thank goodness at least it's going in now.

This all goes back to Struts. Struts is the reason for all of this.

Matt:Do you want to expand on that comment?

Richard:Until Java EE5, if you did want to build a Java web app, then you have servlets. That's the standard. That is a standard, and as you know ... Anybody who doesn't know, you can use our Java web development course where we talk about how servlets work. Servlets are neat, in a way, in that ... I will be pilloried for that. They're not neat at all. They're very ugly things, but it's neat in a way that it's built into Java and they're very simple and straightforward, very easy to understand. I would say it would be a massive challenge, if not impossible, to build a real professional application using servlets alone. You need more stuff on top of servlets.

The easiest thing to grasp hold of is re-presentation. Very simple requirement. Any web application, you have a form, you fill in the values. If you get any of the values wrong, fundamental requirement is you've got to re-present that form to the user with the values that were correct and allow them to correct their mistakes. Obviously, this is 101 stuff, very simple. Nightmare to do with servlets. It would be horrendous. I've tried to do it in the past, but you just wouldn't want to do it.

So that's where Struts came in. This is about ... Can't remember now. A very early 2000s framework that was built on top of servlets to fulfil that kind of need. Other things as well, but those kind of very basic requirements. The problem is, for whatever reasons, Struts never became standardised. It never became part of JavaEE. It was always an extra bolt-on that you had to put in. So already, if you've bought into JavaEE, "I want to have standards. Oh no, I've now going to go outside of JavaEE and plug in another framework on top." Which, it's not a killer, but it's sort of going against the whole ethos of what you're doing.

Matt:But presumably, the same things are true in PrimeFaces. That's a third-party framework. It's not part of the standard, and yet ... When we get requests, because we've not done the module yet that covers JSF for WildFly, every time we get a request, a lot of them say, "Will you be covering PrimeFaces?"

Richard:Yeah, that's a good point. You're talking JSF here.


Richard:So JSF is almost designed to be a ... It's a component framework where you're invited to plug in third-party view components. So that's part of that model, so that's fine. But we'll come onto JSF in a minute. That sort of fits in.

So if you were a developer in, I don't know, 2004 or whatever, there's a problem in Java in that you've got to go choose an MVC framework. We've got our standard JavaEE, but it doesn't come with a framework for a very important part of the stack. So what do you do? Which do you choose, the Struts, which is getting old and dated? So then, every Java developer on the planet, I think, decided, "I can do a better version of Struts," so everybody did. Hundreds of them, thousands of them probably. So everybody was faced with this huge, crippling dilemma of, "Which framework do we bet on?" The point of JavaEE was supposed to be you don't have to make that decision. You get the full stack.

So that's where JSF comes in. In Java EE5, the committee decided, "We're going to have a standard web framework," and this is where it went wrong, I think. They decided, instead of going for the simple, instead of just fixing the thing that 90% of web applications needed at the time, was just a simple control layer, simple view framework to plug in on the top, they just went mad and completely over-engineered the whole thing. "Let's have a component framework and components where you can put widgets on your page, and ..." Great, but not many projects really needed that, but they put it in.

So it had the kitchen sink in it, and JSF was way overcomplicated. And to do an MVC application in JSF was like trying to turn a ... It just wasn't the right tool for that job. So there's been this ... I'm rambling on a lot about this MVC stuff, but it's something I feel quite passionate about, that it's never really been part of JavaEE, and finally, finally, years and years later, when it's now become kind of irrelevant, they finally added it in.

Matt:So if you were using a JavaEE back end today, and your project suddenly needs a web front end that it's never needed before, prior to MVC coming in, my guess is you're not going to go down the route of JSF. You're going to go down the route of some other web front end that can just communicate as-

Richard:At first, when JSF was added, the feeling was, "This is a Struts killer. Great. We've now got a standardised web layer in JavaEE." And unfortunately, a lot ... And I have real war stories about this and real projects experience ... A lot of projects went through the thought process of, "Oh, JavaEE are telling us that JSF is the solution to this. Therefore, we must go and adopt it." And I worked with quite a lot of projects at time ... I'm talking about 2006, 7-ish here ... a lot of projects where, "Well, we have to do JSF," and they didn't realise that it wasn't the right tool for what they wanted. They just needed simple controllers, really, and a lot of projects got heavily burnt by that. Years of reworking and backtracking and taking JSF back out.

And of course, the reason why a lot of this is irrelevant now is that a lot of architectures are ... Your Java ends at the rest interface, and then you go and build your web front end in something completely different that's calling your back-end Java. It might be a JavaScript framework calling the back-end Java, so that's why a lot of people are saying, "MVC shouldn't be being added to JavaEE, because it's not needed. It's not relevant today."

Well, I argue it is. There are a lot of projects out there who are doing a traditional MVC. Just because it's not cool, it's not glamorous, it's being done, and this is at least a good thing for them.

I can't believe we spent like 20 minutes on JavaEE.

Matt:For the people who are listening out there, if there are any listeners, I'm very sorry you can't see Richard's face that he makes when he tries to express his displeasure with ...

Richard:Yeah. It's for those kinds of reasons. I understand that for some projects, it is a great comfort to have a standard that you can work against, but my goodness, does it slow you down. All of these problems are long-solved problems, and when is JavaEE 8 available? Some time in the future.

Matt:Again, what ... I like this sort of question. If you were starting a new project today, what technology would you choose? If a bank or some major organisation where the integrity of its data as it passes through various systems is critical, came up and said, "What would you use? Would you recommend ..." Is there any instance where you'd want to recommend JavaEE?

Richard:We'll edit the long silence out there.

I wouldn't, because being an architect is always about tradeoffs, and you would need to know ... I can't think through the requirements of this hypothetical bank. Obviously, when you think "bank," you think "conservative, stable, slow-moving, don't want to have big changes." So it does feel that JavaEE is right for that kind of organisation, but even then-

Matt:I think, again, it's also though about you're buying an application ... The word's gone. "Server," is it?


Matt:Application server from a supplier who would also provide you with support, and it means that if the system is meant do something, and it's part of your code, and you find it does not work, you have recourse against somebody.


Matt:And I guess that, to me, would actually be what the big selling point is.

Richard:Absolutely. Absolutely, and actually, the traditional way to get round this is that, yeah, we have an application server, and we buy it from Oracle, and we pay them, and we're indemnified and all that kind of thing, but we can still load any JAR files, and WAR files we like onto it. So we send Spring or something similar in as a Trojan horse into it. That's the wrong word, actually, in this instance, isn't it? But we slip in Spring through a WAR file and just deploy it to an application service, so we're not really using JavaEE, but it looks like it from the outside.

Matt:Interesting. So it's about politics, maybe, and

Richard:Yeah, so from a technical point of view ... I think that is my point. You've struck on it brilliantly there. JavaEE is not technically interesting, because all these technologies exist. It's just an umbrella, really, for other Java libraries, and so we're, as a company, Virtual Pair Programmers, we're not going to get excited about JavaEE being released. In fact, it's a pain in the neck, because we've got to go and record all of our old courses, even though they're probably all still technically valid and don't really need updating.

Matt:I guess until the major application servers start providing, or shipping rather, JavaEE 8 versions, which there is no date for at all at the moment, that at least is something we can put on hold for our workload.

Richard:But it's worthwhile being aware of it.

So from a business point of view, the big topic for us in the last couple of weeks has been ... We've been talking about how we market ourselves, how we brand ourselves, and it's very difficult for our business because we have a lot of different types of customers. We've got a wide library of courses covering JavaEE, but also covering the kind of fast-moving stuff, and we've often debated, "Who are we? What's our message, and who are we talking to, and are we talking to experienced contractors, people new to Java, people in the middle, maybe?" I think we finally, finally, have settled on a common message.

Matt:Absolutely. I've been reflecting, actually, that when people ask me what do I do, for quite a few years now-

Richard:Yes, I often-

Matt:But for quite a few years now, I've been saying, "I teach Java," because it's one line, it's easy. People, even if they're not programmers, at least have heard of Java. They get a sense of it. And actually, that isn't what we do.


Matt:And it's not what we want to be doing, and I'm trying to reflect on ... And it's exactly the same issue, isn't it?

Richard:Yeah. Java is ... It's a massively overloaded term. There's Java the language, there's Java the platform, and Java the language is not ... It's an old language. It's dated. If it were built today, it would look completely different, but that doesn't matter. You've got the whole Java ecosystem, which is an incredibly vibrant area to be working in, and that's where we're at.

Matt:Yes, absolutely. You said to me probably a week or so ago that if somebody wants to learn Java, they can do our "Java Fundamentals" and our "Java Advanced" courses, and they're pretty much there. Actually, that's not enough, and if you want to work as a developer where Java is one of the languages in your armour, because you probably do need a bit more than just that one language, actually yes, it's about knowing the frameworks, it's about knowing a bit of architecture, it's about knowing a bit of front-end stuff.

We've been talking about doing front-end in JavaEE. When I first started as a developer, we didn't do front-end work. We worked on back-end stuff, and other people did front-end. There was this division between your skillsets, and I think today ... I've still assumed that division exists, and it's obviously completely breaking down. I think possibly mobile development, so developing apps, is a separate skillset to pretty much everything else, and we've seen that, because certainly the Android courses we have ... We can see on the stats on our system that the people who watch those don't tend to watch the JavaEEs, the Spring Boot type courses, and the people who are focusing on Spring Boot or JavaEE don't tend to watch Android. It is a different audience.

Richard:I didn't ... That's very interesting.

Matt:I think there is still a definite ... App development is a separate niche skillset, but certainly-

Richard:I presume one that we won't go into any further. We kind of don't-

Matt:I think yeah. Again, looking at, certainly, the amount of time people spend watching different courses, it is the smallest part of our library, and yes, we get ... I can't remember the last time ... I'm going to regret saying this, because we'll get loads now, but I can't remember the last time any of our customers asked us for further courses on app-related stuff.

Richard:Great. That's good. I feel ... Yeah, I'm not a fan of Android development, so that's not bothering me at all, but I feel it's a good thing that we've got it in the library. It's rounding it out, and if I were a Spring developer, I would feel a bit like it was missing something if I'd never written an Android app. Even if I just go and do a "Hello world" Android app, that's kind of enough to scratch that itch, I think.

Matt:It's about being a professional developer. It's having knowledge and getting a sense of what's involved without ... Which actually allows you, in a confident way, to say, "Yeah, I have an understanding of app development, and if I need to do that, I wouldn't be starting from zero. I'd be confident I could do it, because I've got that overview." But it's almost professional knowledge you need, rather than the-

Richard:Yeah, that's a good point. I could imagine I would be maybe managing a team where I'd bring in some Android developers, and the fact that, so I was the one who recorded our first Android course, and I could do that because I knew enough about the basics, and I'm very comfortable at recording Android Course 1. When it came to the follow-on course, I knew that I was out of my depth, so you very kindly took over and did the second Android course. And so I watched that course, and the message I took away from that was, "Wow, there are so many constraints and difficulties in building an Android app. Every time you rotate the device, you've then got a whole new set of problems." I was vaguely aware of this, but it was good to go through it and see.

So if I were managing a team now, I would know not to be too hard on them when they haven't delivered in a week or whatever. It helps me to get a better feel for ...

Matt:And I think that, again, the same sort of concept applies for ... If you were building a website, and you're really working on the controllers and the services and the data layer, and you've got a web design that's going to come up with some nice web pages for you, there's a whole thing around responsiveness, around making it work on different platforms, around what happens if the user hasn't got JavaScript, all these things that go into front-end development, that is a specialism. That's why we have web developers, if you like. They're more than just designers. They're thinking about that user interactivity, but as a general developer working in the Java ecosystem, a sort of an understanding of those kinds of issues is useful.

Richard:So the thing that we're scrambling ... We've always known this, but it's about putting words around it. It's about having a single sentence that we can tell people, that we can have as a strap line on the front page of the website. For a long time, the front page of our website said, "Be a better Java developer." That's a really rubbish collection of words. As you've said, we're not in that business. We're about being a full-stack developer, and a good developer today ... I'm just paraphrasing what you just said there ... A good developer today has to be comfortable, really, at every level of the stack, to varying degrees, but you can't just say, "Well, I only write the Java code. I'm not interested in anything else."

And I would say, a good developer ... And let's face it, all of our customers are good developers by definition or they wouldn't be paying a subscription to a Java trai... Now I've done it ... to a software development training library. They're good developers. A good developer has got to have an open perspective. They're happy to learn new frameworks, new techniques and languages, so it's not one language anymore.

Matt:We've got a local recruitment company near to where we're based, and they described it nicely, I think, because some of their employers are looking for people with a “modern Java skillset”. And I like that phrase. I think it's about ... Yes, it's about the language, but it's also about the things you need to know that make that work, make you able to actually build production quality, functioning applications, that cover that full end-to-end process.

We have a customer who I've been talking to by email, actually, and he's been asking what courses he should do to cover certain things, and he's saying, "Look, there's a job application who I want to apply for, and it's saying you need ..." and then listing all these things. For example, JPA is in there, and Spring is in there." Interesting, the guy lists Oracle as a skillset, and I'm saying, "Well, Oracle's a back end. Once you've done JPA, actually, whether you're using Oracle or MySQL, is there that much of a difference?"

Richard:I don't know. They may well expect you to do the tasks that a DBA traditionally would have been expected to do, so they may well expect you to, I don't know, re-index tables or something like that. So some ...

Matt:That's it. I'd not even thought about that.

Richard:Which brings it into the whole ... And again, we cover this in our library. We're doing more and more devops material as well. I know not every project ... In fact, I would say most projects aren't a devops shop, but the cutting-edge ones are, the ones who are the most effective are, and therefore the ones that our customers want to work for are very likely doing devops. So it's not just the Java stack. You also need to have an awareness of, "How is this software going to be deployed?" And probably, actually, able to deploy it to real, live hardware as well.

Matt:If you're working on a microservices framework, that's critical, isn't it?

Richard:Yeah, absolutely.

Matt:As soon as your build is ... especially, yes, if you've got your continuous integration setup-

Richard:Which you have ... I'm passionate about this. We're starting to see now ... I knew this would happen ... we're starting to see the microservice backlash, with war stories appearing on blogs and so on about how, "Microservices destroyed our project. It was a terrible disaster for our project." And we knew that would happen. Actually, to be fair, these reports have been coming for a couple of years now, but it's getting louder and louder, and it's obviously going to be the case. You're going to get a lot of projects who just chase the latest and greatest buzzwords or whatever, dive into microservices, but they haven't got a continuous integration pipeline, for example. That will be the main thing, probably, and yet they think that adopting microservices is going to magically make them agile. Well, it isn't if every time you build one of your microservices you've got to manually deploy the thing. You're very quickly going to get paralysed with hundreds of microservices being manually deployed.

You've got to get the basics right, and we're very clear about that on our microservice courses. Get that sorted before you start building microservices.

I forgot the point now of my little rant.

Matt:We were talking about continuous integration and having to have a knowledge of how to deploy something is important. Yeah, absolutely. So people, in order to be able to get the best jobs and to keep up-to-date with what's going on, need to have that more rounded sense of, or rather ... Yeah, the scope of what you need to know as a good developer has grown, and it's not now just about a programming language. It's about the whole platform that sits on-


Matt:- things that interact with it.

Richard:Absolutely, so I wish there was a good name for the platform and the ecosystem around it, there was actually a single word for it, and I'm not aware of one. "Full-stack Java" is the closest we've got, I think, and that's probably what we'll go with for the time being, but there must be a ...

Matt:We'll have to come up with one.

Richard:"The JVM platform," I suppose.

Matt:That opens another can of worms, because the JVM platform, of course, isn't ... They're not just about Java. There are now obviously a number of other languages that you could be using.

Richard:But they run on the JVM, but they're not Java, so-

Matt:But should a full-stack Java developer have knowledge of some, or how many of these other languages? For example, I don't know if I've mentioned this in the first podcast or not, but I've been looking at Clojure for a little while.

Richard:You are a Clojure expert. Matt is very modest, and will never-

Matt:I wouldn't go that far.

Richard:I would.

Matt:But would you expect a Java programmer to know much Clojure? Interestingly, my feeling on this that Clojure is not that widely used. There could be various reasons for that, but it feels like the reason to learn Clojure is because it's actually a really good intellectual exercise, and if you were a Java developer who can also do Clojure, it really puts you a level above, because you have a, first of all, fundamentally really good understanding of not just object-orientated, but genuine functional programming, and it's such a different way of thinking that you ... In a way, it helps solidify what you can and can't do in Java and what things Java is good or not so good for. And even though you might never build a production system in Clojure, it again elevates your ability levels, I think.

Richard:Absolutely, and again, if you're working on a microservice architecture, then that's just perfect for things like ... You can drop the notion of building an application in clojure. It's more going to be, "Is clojure a good fit for certain microservices in your system?" And of course it will be. You have another tool to work on.

Matt:Yes. I guess what I haven't got my head around is building a full microservice, though, in Clojure. Because it's a JVM language-

Richard:Bear in mind a microservice can be like eight lines of code. That's big enough to be a microservice, so-

Matt:Yes, but the infrastructure to fit it in ... In order for it to be ... I can see that I could build a Java application that, because of the interoperability between Java and Clojure, passes some data across to Clojure for it to run some functions against. I can see that. I haven't got my head around-

Richard:You can send a message to a ... Could even decouple them completely. You could have a Java service that fires off an event. "Something has happened." Maybe drop some data in it, in a shared storage somewhere, and then a Clojure service hooks into that event, fires off, and starts running on its own instance, on its own machine.

Matt:It's obviously doable. I guess I'm just saying I haven't got my head around the structure of a Clojure application to make it monitor something or be triggered by something. I feel like it almost needs a framework. There's a framework for clojure to do web development. It possibly needs some add-on at the core. It's obviously not part of the real core Clojure, which is just functional programming but yes, it's doable.

Richard:So you're clearly at that point in the learning curve with Clojure where you've got the fundamental language principles. I've seen you code in Clojure, and you're very hot at it, and you've got into that functional way of thinking. It's lovely to see, but it's just about ... Again, I'm just paraphrasing you, really ... It's what tools are available to integrate that into a system operationally.


Richard:You're nearly there then. So my take on it would be you don't have to be ... There is a bit of bragging going on, isn't there? When we go to our coding meetups, people are always dropping in, "Oh yes, I'm working on Kotlin this week," and, "Oh, you're Kotlin? Have you not tried Ceylon? There is definitely a little bit of gamesmanship going on, and I would just think, as a developer, you mustn't be closed.

If I were interviewing ... That's often a good way of thinking about it. If you were interviewing for a developer, and you had a developer come in saying, "I'm a Java developer, and I'm not interested in any other languages. It's Java, Java, Java, Java," then they're clearly a less good developer, unless we have any other information. They could be ... What's he called? James Gosling. Assuming they're a regular developer-

Matt:They could a concurrency expert. They could have particular niches of expertise.

Richard:A concurrency expert who hasn't gone on to learn some functional, to improve their ... It would be very suspicious if you just say ... And then developer 2 comes in, and they say, "No, I'm only skilled at Java. If you give me a whiteboard exercise to do, I'm going to do it in Java, but learning Clojure is on my to-do list, or learning Scala, or I'm going to buy a book next week on Kotlin and I'm just going to get a feel for it." It's about being open to it. Rather than actually having the skills, you can easily acquire the skills once you've opened your mind to them. So all you have to do is sign into a library like Virtual Pair Programmers and get them.

Matt:That was a plug well done.

Richard:So that's the mindset for me, which is just absorb these things.

Matt:It feels like you need to pick the right ones. We went recently to a open day from a local, very big employer of IT people, and they talked about what technologies they use amongst their staff, and interestingly, they showed ... I don't want to name them, but it was an international broadcasting company, and they showed a slide of, "These are all the different languages we use," and a lot of them were JVM languages, but then they made a point that they are slimming that down and they are ... Yes, they're keeping Scala, but they're certainly ... Groovy was no longer one of their cores.

Richard:No problem as an organisation level maintaining a focus. I get that, but as a developer ...

Matt:Do you need a bit of everything rather than-

Richard:No. I'm just saying be open to it. There's no problem ... I'm the most cynical, miserable ... You've heard me already on our ... We're in our very early days of podcasting, and I'm far more vocal about the things I hate than the things that I love. I would have no problem with a developer coming into that interview, saying, "I hate Groovy. I think it's dreadful," as long as they can back it up with reasons. If the reason is, "Well, I do Java, and I'm not interested in anything else, and Groovy is a bit of a threat to me," then bad developer. But good developer is somebody who can say, "Well, Groovy is, let's say it's too slow," and they don't like dynamic typing. If they can justify it, no problem with that at all.

Matt:Yes. There's a mindset thing going on here, though, because when you start something like Groovy, if that's the first language you're doing, having only ever done Java first, there's always this sense of, "Wow, this is amazing. You can do all this with such little effort," and if you don't get that sense out of it, then to me ... That was the sense I got from Clojure. "Isn't this clever? You can write such little code and do all these amazing things," and to me, the energy, if you like, you get from it, the enthusiasm, is what's important.

So where do we go, then? What do we do next?

Richard:It's clearly something we need to do, in that, yeah, we've got the frame, we've got plenty of frameworks, Spring and Hadoop, etc., etc. We've got the devops. Good, good, good. We don't really have multiple languages. We have got Groovy, of course, and you can talk about why did we do Groovy.

Matt:The reason, I think, we did Groovy was simply because our original website was built in Grails, which is a web framework for the Groovy language. We can talk about the demise of Grails or otherwise at some point.

Richard:Yeah, we'll keep that as a future podcast discussion, I think.

Matt:But Groovy is ... And I came to this as a Java developer without a huge amount of ... Well, there was no Groovy knowledge initially, and again, I got excited by the fact that you could do the stuff you could do in Groovy, learn to ... You taught me part, I taught myself part, and then I had to start writing the course, and I think it was that sense of, to be a good Java developer, Groovy helps. Even if you're never going to write any Groovy code, having that knowledge of it shows you the constraints of Java and the pluses as well. It gives you quite a good grounding.

Richard:It does, but perhaps it has now been superseded by other languages that have become popular since then. It's kind of difficult to put your finger on exactly what's wrong with Groovy, but certainly if I were picking my ... If I know Java, and I was picking my next JVM language, it wouldn't be Groovy.

Matt:No. The people I know who use it are using it as a prototyping language, so they do something very quickly in Groovy, just to prove a point, but they don't stick to it as the production system.

So what would you pick?

Richard:I would pick probably any of the other vibrant ones, and the leading ones are, of course, Clojure, that you've mentioned. Not used in production particularly much, but as you've brilliantly identified, a great language to learn intellectually. Scala has a lot of talk around it, and there's what I would probably think of as the middle ground language, which is Kotlin. We're hearing a lot about Kotlin at the minute.

Matt:Do you want to ... I actually haven't heard much about Kotlin, so do you want to give us a bit of an overview of where Kotlin sits?

Richard:Yeah. I would say, at first glance, it feels very much like a simpler version of Scala. Scala is a great language. No doubt about that. It is great, but I think anybody starting with Scala definitely gets the feeling that it's a very ... What's the word? It has a feel of academia about it. It's very ... It's hard. I'm just going to keep-

Matt:Intellectually demanding?

Richard:It's very, very demanding. All languages are, of course, but Scala is particularly that way. With Kotlin ... And bear in mind I've done very little on Kotlin so far, but I'm looking forward to doing more ... I have a very similar feeling to what you were talking about with Groovy, in that it's very light in terms of syntax. Your "Hello world" is much simpler than a Java "Hello world," and all of the modern language features that you would expect in a modern, vibrant language are right there. And if I could be cruel, it's what Java would look like if they'd done what C# had done, which is actively modify the language and keep it fresh and keep it current and keep it up-to-date.

Obviously, on a podcast it's not a very good medium for teaching Kotlin or telling you about Kotlin's features, but what I can say to anybody listening is, if you just ... I don't have the URL. We will put the URL in the show notes, but obviously you can Google "Kotlin." You go to the Kotlin homepage, they have got just a brilliant tutorial on there with an embedded compiler right there on the page, and you go through the examples. The code is written for you, and you compile it on the fly, and you can change it and modify it. I would say within an hour of playing through that, you'll have got the syntax, you'll have got the feel for Kotlin. You'll be up and running, basically.

Matt:What's the use case for Kotlin? This is one of the things I've struggled with Clojure, is I can't come up with an example where I would absolutely say, "Clojure is the right tool for this particular job."

Richard:Kotlin is strongly typed, for a start, so it's not like Groovy, in that you don't have dynamic duck typing. If anyone's confused by that, just check out Matt's Groovy course at

Matt:This isn't meant to be a constant plug for our company, by the way.

Richard:But I genuinely think it's the best place to learn Groovy.

So, in other words, any use case that you have that you could satisfy with Java, you could satisfy perfectly well with Kotlin. There is no major philosophical shift. It has functional features, just like Java 8 has lambdas, but it doesn't have the feel of a functional language, particularly. It's OO, as well, but just as Scala does and just as Groovy does, if you want to write a class in Kotlin, it's far simpler, far quicker. You don't have to write get sets, for example. You don't have to write an equals implementation. The equals operate ... A double equal, equal works as you would expect it to work, so it's things like that.

I don't need to come up with a use case specifically. It's just any app that you would do in Java, you could do in Kotlin. My argument is you're going to develop it faster. It's cleaner, simpler, more straightforward, and as usual with all the JVM languages, at runtime, a Java class, to the JVM, looks identical to a Kotlin class. It's identical to a Clojure class, so from a kind of runtime, operational point of view, it's just JVM. It's JVM classes.

Matt:So if I wanted to start a Spring Boot project, I've never tried it, but I know you can develop Spring Boot with Groovy. Can you develop Spring Boot with Kotlin?

Richard:Good question, and I'm fairly certain that Spring 5, which I don't think is released yet, but we do need to do a feature on that ... It's getting close, at least ... has now added Kotlin as one of its prime supported languages. As you know, I'm not that interested in Android, but Android ... Kotlin is now an official language for Android as well, so it's one of only three languages supported by Android. There's C++, Java, and Kotlin.

I've got a feeling, actually, it's the Android area where Kotlin is really ... That's where it's become popular, and now other people like me are following along. So I think Kotlin's very promising, and we will ... That's where we need to end this discussion, really, but we need to make a decision. Are we going to support these languages? Are we going to cover them in our courses? Are we the right people to do it?

Matt:It feels like ... If what we're saying is people need an overview for that intellectual challenge and just that sense of it, then maybe that's the level we go to, at least for now. Maybe we need a little section. We have what we call our tracks on the website, so just core Java is a track, and Spring framework is a track. Maybe we need an "Other JVM Languages" track. We can stick Groovy in there, maybe do a, again, introductory Clojure, introductory Kotlin, just getting a sense of getting started, and then, if the demand's there, we can always go further. If not, then at least we are helping people get a more rounded knowledge, which I think is our goal, really, isn't it? To support people.

Richard:Yeah. I think one of our problems historically has been, whenever we've done a course, we've always wanted to do the full, all-singing, all-dancing roller coaster of a course with absolutely everything in there, and that's paralysed us a little bit. And yeah, we do need to do smaller, quick-start courses.


Richard:And I also think we often wait until we've got some project experience before we ... And sometimes these days, because we are now busy running a business, sometimes we have to force a requirement into our Virtual Pair Programmers system, and we sort of use the technology that we know isn't right for Virtual Pair Programmers, but we need to test it ourselves, so we put it in anyway. Then we get the experience, then we do the course on it, which is great. That's good for authenticity. We're talking real war stories, we've got real experience, but doesn't half slow us down.

Matt:Absolutely, and for me, doing this Thymeleaf, it's taken me weeks and weeks and weeks, because we had a need, actually, to build a new system for ourselves-

Richard:Oh, we have a need. We have a need for that.

Matt:- to do with managing our accounting.

Richard:We are desperate for Thymeleaf.

Matt:But I needed to build a new system anyway, so I was doing it in that, and yes, you stumble across problems that take a while to work out, which is great in terms of what we need, because when we come to teach it, we can say, "You're likely to encounter this. This is what it means."


Matt:And that's the key. That's the real value.

Richard:It's where our value is, without doubt. So our microservices course, in particular the deployment course, is just riddled with real-life problems that are never mentioned in the books, but these are things that's happened to us, and this how you might get round it, and these are the tradeoffs. So as a business, we must never lose sight of that. We've got to keep doing that, but I think there's nothing wrong with ...

If I can back up a little bit, we both have experience ... Our background is training, and when I was a live trainer, the number of people I met who were professional trainers who would teach anything, they’d just take any gig going ... If I said to one of those trainers, "Can you do a course on Kotlin next week, please?" He'd just say, "Well, is there a book available on it? If there's a book available, I'll teach it." That's why live training has such a bad name. I think we've all probably worked for companies where we're sent to a course, and it's clear that trainer doesn't know the first thing about this subject. They're one page ahead of you in the book. That's all. And throughout my training career, I've been terrified of ending up like that, and I've always avoided it.

So I'd hate for a Virtual Pair Programmers course to be, "We're just one page ahead in the book." But would I hate it? Actually, if we're honest about it, I think if we had a branding, if we had a track of courses where, "We're new to this, but let's give it a road test. Let's try this out." We could certainly do it with something like Kotlin, where we're not going to probably give you war stories on how it is, and we can't necessarily recommend it for projects, because we don't know yet. We haven't tried it, but let's go through the features and compare and contrast it. But it needs to be a ... It needs to have a special name.

Matt:Yeah. We'll come up with a ... Like, "This is a workshop rather than a course." We need something that separates it. I agree that part of what we are about is that we are being authentic in what we do, so we are absolutely not just reading a book, reading up on how to do it, even if it's a new topic. The Hadoop course is probably a good example. I knew no Hadoop before I started working on that course, but I probably spent the equivalent of three months full-time building different things in Hadoop to learn it. I wasn't just reading a book and regurgitating.

So this won't be that, because we haven't got ... And especially if I take the Clojure example, there are things we could absolutely do. We have a lot of internal reports that analyse how many videos are being watched, when they're being watched. We could absolutely be building Clojure systems to feed that data through, but there's no obvious need to, because what we have works fine. So it's coming up with a sort of compromise, I guess.

But then we're certainly going to focus now on, or try and move forward a bit more on coming up with the things that developers need to be that genuine, full-stack developer or developer with a modern skillset.

Richard:But we always done that, though. Apart from we don't have many JVM languages, we've always been that from the start. Our first course was Spring, and it's always been around. In fact, Java fundamentals was quite a late addition to the library, so this discussion really has been about how do we sell this to people. Somebody brand-new to Virtual Pair Programmers will just think, "Oh, you do a Java course, do you?" Which we don't. We've got 250 hours, is it? 250 hours of-

Matt:It's over that, yeah. I lose track of what we're up to, but-

Richard:And like five hours of that is core Java. And that's very valuable. It's good for somebody getting started, but the real thing we should be selling is all of the stuff around it. Our customers get it. The people who are with us get it. It's the new people we want to bring in. That's the point.

Matt:Yeah, and I guess we want to be, we need to be the most comprehensive or the largest online library of skills that Java developers need to be-

Richard:Java full-stack developers.

Matt:I can't even say it right, but we need to cover the complete modern Java skillset. That's it.

Richard:Absolutely. Absolutely.

I get the sense it's been a slightly duller podcast this week. We were laughing and joking last week, and it's all got serious suddenly.

Matt:Well, you started by asking what the news was. Maybe we'll start the next one with a more lighthearted question. But yeah, it's been a bit of a different sort of set of topics as well, really. It's about where we're going as a company, about what's needed out there, so I think it's been interesting.

Richard:I think over time, I hope people are going to find this podcast valuable, and I think over time we'll find the right balance for what we're going to talk about. There isn't generally ... in a two-week cycle, there isn't a lot of Java news as such, so I think what talking about what we're working on is probably going to give us plenty of material.

So just very quickly, you're working on Thymeleaf, which is-

Matt:I'm still on Thymeleaf. I'm about halfway through recorded on that. Obviously, there'll then be a process to edit that, so it's not going to out within the next few days. I'm apologising. It will be a little while.

Richard:It's pretty close, though, I think, isn't it?

Matt:I would hope ... It's now the end of ... I was about to say, "By the end of the month." I've just realised it's the 31st of May, so I would hope middle of June. I'm probably targeting for that. It is close. I'm actually working at the moment on ... There's going to be a couple of what I hope are going to be really good worked exercises at the end, one to take some HTML and CSS as though it's been given to you by a web designer for to integrate into your system, and a second to convert from JSP to Thymeleaf, which I think most people would probably not go through that last process, but it's a great way of knowing you've really got to grips with how Thymeleaf differs, how it works. So that's the bit of it I'm working on right now.

And then, we might change this, because we've just talked about Clojure, but I've got in my head we need to re-look at Java web development, which is our oldest course. Maybe a little refresh. I feel like we need to do an hour on JSF, just something to touch so that we fill in the gap there. Richard is sticking his tongue out as I say that, but that's where I am. And then possibly it might be Clojure then next.

Richard:Okay. That's bold.

Matt:I can change my mind.

Richard:This is the problem. We've got far too many things. If we had a hundred trainers, we'd still not be able to cover it all, but I'd love to see your Apache Spark course, because that is just right up your alley and it's just perfect for what you do. I love Spark. I've done a little bit of work on Spark, and I'm not great with aggregations and I never was very good with databases generally. It's not about databases, but I was always rubbish at doing “group by” in SQL. But that's the way your mind works, so Spark is going to be fantastic from you.

So there's obviously decisions to make about what you're doing next. I'm still on Docker. That's going-

Matt:How's that going?

Richard:- very well so far. The thing is with Docker, there's a million courses out there on Docker, and Docker's not that hard really. I have a feeling that a lot of our customers, a lot of our subscribers, have probably already done Docker, so I have a bit of a difficulty there on, "Do I do this quick and dirty? Do I just do Docker 101?" Which would be good. At least it would be quick, and all the rest of it, but I think our customers probably want to see Docker 101, but then Docker tied into the kinds of things we've done on previous courses.

The microservice deployment course gives us a brilliant case study for Docker. One of the selling points of Docker is the idea is instead of, at the end of your build cycle, if you like, out pops a WAR file or JAR file, and then you go and deploy it ... I don't know. You might ... Certainly on the deployment course, we have a script to provision an instance and install all of the software onto that instance, and then the WAR file gets plopped on top. With Docker, your unit of deployment is now a container. It's not a virtual machine, but you can think of it like that. It's a complete environment.

So the developer is specifying this part of the build, what software is going to be in this container, and all the rest of it, and it's that that gets deployed. This has massive benefits. It simplifies the deployment process, but it also means that locally ... Think about the traditional way of developing. You have to set up a local environment. "I have to install MySQL," or whatever database you're using, "and I've got to ... Oh, my environment variables are wrong on this machine." And then you've got all that sorted, and then you send it off for deployment, and it doesn't run there because ... That goes away, because you just run a Docker container locally, exactly the same Docker container that you're going to be running in production. So it's all about bringing ... It's devops again. It's about bringing the dev and the op closer together.

Matt:Is running a Docker ... I don't know if "architecture's" quite the right word, though. Just purely from a business point of view, is that also not more either cost effective, because you can run more microservices on fewer machines-


Matt:- type of thing?


Matt:It makes sense from that side as well, doesn't it?

Richard:Yeah, definitely so. Having a container gives you the isolations that, on the microservice deployment course, keep things simple more than anything. We deploy a microservice to a standalone EC2 instance, and that's the only service running on it, and that gives you a lot of isolation. Sure, you can achieve the same thing with containers, so you could have multiple containers on one instance, and that could well be a lot cheaper to run. So we'll look into those kinds of things.

But actually Docker goes even further than that. There's things like Docker Swarm, which gives you orchestration as well. For example, you can say, "This container needs to be deployed to three different physical instances, and if the CPU load on a particular instance is too high, then spin off another one." It's doing the kinds of stuff that you could do with Amazon Web Services. You could use all of their tools and monitoring systems to do that, or you could do it yourself using Docker. That's very attractive.

Matt:Interesting. Very interesting.

Richard:And it's attractive because the last thing you want to do, if you're using a platform like AWS, is don't rely on AWS. Can you move your architecture to a different platform in a reasonable amount of time? If the answer to that is no, then you got a problem. So tools like Docker should help there.

Matt:Interesting. Very interesting.

Richard:So I want the course to cover all that kind of thing, and I'm quite ... Well, I'm getting on with it.

Matt:When we first started working together, I always used to ask you, Richard, "So how long will it be until this next course is released?" And I now get why you can't answer that question, and again, it's going back to, "If I answer that question with a date, I'll be doing half a job, and that's not what we're about."

Richard:Yeah. I did promise in the last podcast that I'd have Docker out in June, and I'm still going for that. It might well be it's Docker module 1, which will be the 101 version. Might not satisfy everybody, but at least it gets everybody to the same level, and then we can do a Docker 102 or whatever after that.

But for me, the next course, I would like to be Reactive, which I did want to talk about on this podcast, but we're well over time, I think. It is time to wrap up, so we'll maybe defer that until the next podcast. But what I want to say about Reactive is our courses already cover Reactive. We've just never mentioned it as a specific term.

Matt:That's the spoiler for the next podcast, in that case. We'll go into a bit more detail about that next time.

Richard:We're also planning to go to the Amazon Web Services summit in London, but I think that's not before the next podcast, is it? That's towards the end of the month.

Matt:No. I think it's about the 28th of June, I've got it in my head.

Richard:Be quite good if somehow we could maybe do a podcast from the AWS conference. We'll find a room or something. It's in a massive arena-type place. We must be able to find somewhere

Matt:It could be a challenge, but we might be able to do something. We can have a look into that.

Richard:We're all about challenges. Challenges are the parents of solutions.

Matt:Oh, dear. I think that is definitely time to finish, in that case, if we're going down that kind of route now.

Richard:Definitely time to wrap up.

Matt:If you've been listening, thank you for listening, and-

Richard:Thanks again. See you on the next one.

Matt:See you on the next one.

Richard:Now what do we do?


Listen via:

Be notified of new posts