In our first Podcast, we discuss the current state of Java 9, and Jigsaw in particular, plus we touch on thymeleaf, JSF, and there's an update on what we're working on too.
This is the full transcript of the podcast, for those who prefer to read...
Matt:Hello this is Matt from Virtual Pair Programmers.
Richard:And I'm Richard, from Virtual Pair Programmers.
Matt:Well that didn't work, did it? As our entry point… Can I just say, for the listeners out there, if there are any, we've just spent the last half an hour discussing how do we start this podcast.
Richard:We're so used to working from scripts that we've maybe worked on for six or seven weeks it's just do it off the hip like this. It's quite a challenge for us.
Matt:It is and Richard has this idea that we're not going to edit what we say on here. If this stays in, we can't do a "Let's restart this. Hello, I'm Matt and welcome to the first podcast from Virtual Pair Programmers."
Richard:It is our first podcast. It's 2017. We've been in business for nearly ten years. What took us so long in doing a podcast?
Matt:Well I've think we've reached the technology of podcasting as it's probably going out of fashion, I imagine or is already out of fashion is that? That's not fair is it.
Richard:The potential, I mean, obviously there are a lot of businesses doing probably more video podcasts these days and we will I think go to a video podcast. That's the general plan but we're starting as simple as possible. But yeah, why haven't we've done podcasts? What stopped us?
Matt:I think that we sort of know what we're good at, right? It doesn't feel to me up until recently we thought we'd necessarily be good at this.
Matt:Why is that, and I think it's ... We teach in a way where we can go back and repeat something and edit something and say, "Well actually, I'm not sure that really made sense, let's redo that." It's not a completely natural style. It's not like teaching in front of a live audience. I guess this is trying to have a conversation. We've talked for a while about we should record our conversations.
Richard:Yes, yes. Absolutely. I'm inspired very much by ... Going back 10 years now, roughly about the time Virtual Pair Programmers was starting, Stack Overflow was starting as well. Jeff and Joel, the founders of Stack Overflow decided they were working on opposite sides of America so they had a weekly team meeting by Skype I think and they decided they would simply record that and use that as a podcast. It was basically an hour and a half of Jeff and Joel showing off about how clever they are and being very pompous but there was actually a lot of interesting stuff in there as well and they didn't edit. They just shot from the hip and I think they had an agreement that "Okay, we're gonna need to talk financials, we won't include that in the podcast but everything else apart from that we'll just leave it in." There was no need for scripting, there was no need for editing and it was a fascinating podcast. It's still running today but it's nothing like as interesting. I'm very much inspired by that.
Matt:Were they talking about where they were taking their business and what challenges they had and that kind of thing?
Richard:Yeah, they were ... It was completely from the hip, so yeah, there was a lot of that but then they drift off into other things. They talk about the industry. What it's like to be a software developer. That was probably most of it actually and it was a fascinating ... You got a lot of insights into what kind of decisions they were making and scaling up a business and we should do the same.
Matt:Their business at that point because obviously this is before things like Stack Overflow careers, so their business at this point was to create a new forum, right? A new way of doing forum type things.
Richard:Yeah, it was going to be a combination of forum and the Reddit style ...
Richard:... commenting and up voting and down voting, so it was a combination.
Matt:Yeah, but their business was presumably to generate advertising revenue to fund that, was it?
Richard:I have no idea. Certainly Jeff Atwood would have simply been into the vision of doing the better version of Experts Exchange. That was very much his drive, right? Guess Joel possibly had a bigger idea where they were going to take it but ...
Matt:Yes. Okay. So, that was interesting from a these guys are running a business point of view. Were they talking techy stuff?
Richard:Oh, absolutely. Yeah. They were talking a lot about what is it to be a good software developer and what should software developers be doing to improve themselves and the usual opinionated stuff from Joel Spolsky but some real good, so that's a decision we need to make. Is this podcast going to be about Virtual Pair Programmers, the business or is it going to be about Java or is it going to be about the JVM ecosystem or is it going to be about software development?
Matt:I'm going to regret saying this but my instant reaction to that is it should be sort of about all of them actually but it's, somebody said to me recently that young people today aren't on Facebook, right? Facebook is for our generation, right? I'm going to say the ...
Matt:Yeah, the over 35s let's say. Let's be generous, right? Because all the young people, they're on Instagram and whatever are the Snapchats, the new things that we don't get as older people but the people who are on these things, they live their life through social media and actually from what you've just said about Stack Overflow, maybe what's interesting about it is the fact that they're not just talking about one aspect, they're talking about their lives or an aspect of their lives, their business lives and maybe that should be what we're trying to do, talk about the issues we have in running a business, the things we're working on, the issues when we're building our own software for our own business that we're coming across.
Matt:Plus of course, and yeah. Absolutely what's happening in the industry when we go and meet other people and we learn things, let's talk about that as well, so let's live our lives through this medium. As I said I'm going to regret saying that, but ...
Richard:Yeah, and as Stack Overflow did, it's effectively a team meeting but we may as well record it and there you are, we've got some free material. Great.
Richard:So obviously the big news in Java circles right now is Java 9 and I know you know quite a lot more about it than I do, but we've both attended a hack day. What would it be, about two weeks ago now?
Matt:Yes. Two or three weeks ago. Yes.
Richard:So we went to London and we're on the 24th floor of a very swanky building, fantastic view and it was a full day with about 50 pretty serious Java hackers and we gave Java 9 a good road test.
Matt:So I think it's fair to say we gave parts of Java 9 a good road test and one of the things I have no clue about is what really is in Java 9, so I feel like I know about three aspects of Java 9 which are the bits they covered on the hack day.
Matt:And I guess they are the bits that are most in the news because of the fact that they either aren't working yet properly or there is some controversy about the way that they're being done, but it's interesting because I think compared to, my sense of it is going from Java 7 to Java 8, it wasn't that much in Java 8 that was of great, okay, the things in Java 8 were big, right? So the idea of lambda functions was a big issue, but ...
Richard:It wasn't a breaking change. It was a new toy that you could optionally use if you wanted to go down the functional route. If you didn't then ignore it.
Matt:Absolutely. And there is a use for it. I mean, I was talking to somebody actually funnily enough at that hack day who was saying "Well, the advantage of streams is for multiple processor processing."
Richard:And I love functional programming, so it's a great thing to have. It was a big thing. It was a big deal but it wasn't something that was going to cause you pain. You did not want it. If you had no interest in functional, fine. Not a problem, but obviously the thing that we're skirting around is there is a long list of features in Java 9. I've actually got a list in front of me but the monster in Java 9 is of course, Jigsaw. It has a Sunday name as well. It has a formal name.
Richard:Java Platform Module system. I think, JPMS?
Matt:I think that sounds right.
Richard:So, no one will call it that. It's going to Jigsaw, and I mean, it's hugely controversial. I think it was slated for Java 7, possibly even Java 6, My memory doesn't go back that far but it has been delayed and delayed and delayed and we assumed it was a definite to be in Java 9 and yet ...
Matt:Well, so the current news of today is the 18th of May and 2017 and the current news at this point is that the Java committee has had the vote on whether or not it is I guess ready for release. That's a layman's way of describing it and the vote did not go in favour, so I think they actually needed two thirds majority and it was something like 13 against, 10 for. It was that kind of proportion and some of the very big well-known names like IBM and Redhat voted against. At the hack day, they sort of demonstrated it and it seemed quite good to be honest with you. I mean, the idea, we'll talk maybe a bit about what the idea of modularization is, but I felt at the hack day, okay, this sort of works. I can see the idea and then came away and tried to use it to convert a system that we use internally at Virtual Pair Programmers to try and make it modular. I thought, well let's give it a go onto real software that we've built and we understand well and it's not that big a programme, but it would suit working in a modular way.
And it's a spin boot application. Immediately, you encounter all sorts of issues and they range from the fact that the IDEs are not yet ready for Java 9 and for modularization so you cannot have two modules in a single project in any IDE at this point as far as I understand it. Certainly in Eclipse, IntelliJ, they can't cope with it and in fact Eclipse have said, you'll never be able to do it, so every module will be it's own project in Eclipse
Richard:Every module will be it's own project.
Matt:Which is not at first view a major issue.
Richard:No, that sounds reasonable. We should explain before we go on, I guess, what a module is.
Matt:Yeah. Do you want to have a go at that or shall I?
Richard:Ugh. No, no. You go.
Matt:Okay, so the way I see it is that modularization is trying to really solve the same problem that microservices solves. So it's rather than having a monolith application all in one big jar file, it's a way of splitting it up into smaller self contained units.
Richard:Of course we already have jar files in it, so an average application is Java might be composed of 50 or more jar files but the problem is jar files are a very weak form of modules in that at runtime all the classes inside the jars all get unpacked and they all get combined together and there's absolutely, at runtime there's no separation between the jar files at all so a class in any jar file can go and look at, can start calling the methods of the class in any other jar file and you can get, I mean, every Java developer has had jar file hell where you accidentally end up with two versions of the same framework in a jar and you get runtime crashes and all sorts of horrible things, so this is a way of ...
Matt:It's a way of dealing with that, so you get better what they call encapsulation. So it's actually still driven by jar files but they've changed the structure of the jar file to make this work, but you get better encapsulation so ...
Richard:And the way it works is there's new java syntax, so when you write a package. I think it's at the package level, is that right?
Matt:It is. Yes.
Richard:You have a companion file. I forget what they call the file.
Matt:Module-info.java I think.
Richard:So it is a compiled java file. It's not an XML file or anything like ...
Matt:It has its own syntax format but it is compiled to a .class file. That's correct, yes.
Richard:And this defines what parts of this package, I keep calling them packages, a module.
Matt:It's a module.
Richard:What parts of this module are going to be exported to the outside world and which parts are going to be private.
Matt:That's correct and actually there's an extra little bit there which is worth understanding because this is where part of the issues come from which is that modules can be dependent on other modules and the idea is that you can say, for example, in due course, some of the logging framework, so say log4j will be a module and you can say I'm writing a module that has a dependency on the log4j module and allows me to use it.
Matt:And so the people behind log4j to make that work, they will say in their module-info.java these are the classes that we are allowing you to call from your code. These are the ones that are public and everything else is hidden. One of the ideas though is just to finish this little bit off is that in the monolith application made up of lots of jars today, if you've got your simple java entry point jar for the application, the bit you're going to run, if you change any of the underlying jars you've got to recompile the header jar, haven't you?
Matt:Whereas in a module based application you don't, so you can swap out one or more of the jars for a newer version. You don't have to recompile anything other than the jar you're swapping out. Now, right now you do still have to restart your application, so there isn't like a hot swap thing which some other modularization frameworks have and we'll talk about that probably in a bit more detail, but at least you only have to recompile so if you're working in, so if for example, there is a new version of log4j and we decide well, we're going to upgrade to that new version, all you have to do is replace that one jar file. There's no compiling required. It should seamlessly work. So the dependency is on a, do you see what I mean, whereas in today's application you would have to recompile.
Richard:You'd have to re-. I'm not sure about that. You could just swap the jars around in the lib directory. You could rerun a Maven without recompiling I think, but I get the general.
Matt:You get the general, so the idea is it's a much easier process to replace a module.
Matt:So the other thing about that as well is that if you're building your system so that you're using different third party components and one requires a particular version of let's say log4j and a different component requires a different version of log4j today that gives you real problems. In the future that will also be possible. You can say this module uses this version of the module, that module uses another version of the module.
Richard:And they're in their own class loader systems so they don't ...
Richard:Right. Great. So going back then to the Eclipse problem. You're saying that for some reason, Eclipse will never support, so in a project there's going to be one module.
Matt:Yes, and actually the way it works in Eclipse is you're only allowed one module-info.java file.
Richard:Which sounds reasonable ...
Richard:... because the idea of a module is it's going to be an isolated ...
Richard:... single unit of development.
Matt:So the issue then comes with the fact that we talked about the fact that modules expose what are the public interfaces to that module. What are the external classes you're allowed to call and there's another level as well actually which is called services, so you could create a module that exposes a typical Java interface and say another module that can implement that interface and there is syntax within the module-info system to say I can consume this module and provide an implementation for it.
Matt:So there's a whole dependency system that's built up around what I can expose, what I can consume and so on. If you're building a module in Eclipse and you're building a module that is going to consume another module or have a dependency on another module, for the syntax checking to work, Eclipse has to know about that module.
Matt:And the only way today it can do that is if you've compiled that module to a jar file and put it in as a reference library. You're making the noise so there is, right now, because Eclipse has this sort of requirement for single module projects, you can't, there's no obvious way around it.
Matt:Now, okay, so if in what I was working on, that's not a major problem. I can build a module as the, you have to think about it then in terms of your tree and you start at the bottom of the module that has no dependencies and work upwards, but you can do that. It's not ideal but you can do it. When you start trying to edit two modules simultaneously because you're building an application, then it becomes really horrible because you have to keep building new jar files to replace the ones that are dependencies. It's horrible, but we can live with that. But then the issue comes to okay, well this is a Spring boot application. I can't build at the moment a module in Eclipse easily so actually that's not quite true, but you need command line parameters to the javac compiler to say this needs to be built as a module.
Matt:It's not the out of the box compile, so okay, we can sort of do that in Eclipse obviously, but it's not completely straightforward but in order to build a module, you have to tell it, sorry, in order to build the top level entry point to your application you have to tell it, and it doesn't call it a class path. There's a new word for it now to describe, probably module path actually I'm guessing, but you have to tell it where are the modules that it has the dependency on.
Matt:And so you need a file structure that supports building modules or the jar files that you're creating to a particular location that the other project can then access, so you create this whole file structure that doesn't really work in the traditional workspace, right?
Matt:So you need a file structure that sits somewhere out of Eclipse for Eclipse to access and it gets very, very messy but then actually you realise when you come to build your application, the whole thing falls apart because Maven doesn't work with modules.
Richard:Right. Well, that was the, at the hack day, nobody mentioned build tools, Ant, Maven, Gradle, none of them got any reference at all, but all the way through I was thinking well, this is great, but without the tools structure that we have, this is all a non-starter but I'm reading today, just today in InfoWorld actually, that the Oracle's java chief debunks misconceptions about Java 9 and the headline states that new version of Java will work with Maven and favourite libraries and code conversion won't be required. So that comes from, I guess, it's Mark Reinhold himself. Now, you have done a project in Java 9 and you're, the first thing you said to me was "It doesn't support Maven."
Matt:Okay, so I think the key word in the sentence you just read out there was the word "will." It will work. I don't think it does today, or certainly it didn't the day I tried and the issue is, is that if you're running a Spring boot project, so you're dependencies are defined in Maven, you've got to really build your application with Maven. Otherwise you're writing a script yourself which is what you would have to do today to say I want to compile this application that has a dependency on these modules and of course all its Maven dependencies. Now using Maven, it does download all the Spring dependencies and it hides them somewhere on your file system, but you've got to go digging to see where they are if you're going to write this yourself, so in order to build your application with Maven you've got to be able to write something in your pom.xml that says this needs to be compiled as a module and as far as I can see, there is nothing right now in the Maven syntax that let's you do that.
Matt:Now, the word as I say was will. I'm sure it will work because it'd have to. Otherwise ...
Richard:From what I can tell and I really I've only just skim read this article. It does seem to be saying that it works today because he's saying there are some problems with Maven plugins including a minor problem with the testing plugin, so it's kind of implying that, but this is the point, it's not clear, I don't think what the real impact of Java 9 is going to be and we're kind of on top of this and we've done hack days and all that and we're still not sure. Now up until now, it's always been the case that in general a Java project, if you upgrade from one Java version to another in general it will in the main work.
Richard:It will compile and it will run just fine. And that's been a joy. It doesn't feel like that's going to be the case with Java 9.
Matt:Well, I got the sense that it will be the case because it's only if you try and do things in a new Java 9 way, you're going to have these problems. If you took an existing Spring built project, compiled it with a Java 9 JDK and run, it will run fine, including Maven.
Matt:So it's the modular bit that I think was a problem because actually my first step in this process was to say well, I've got Java 9 on my machine. Let's just try and run it and I seem to remember it ran fine.
Matt:And there is, I remember they mentioned this at hack day, there was a command line option you can put in your compile which says ignore any Java 9 specific aspects to make sure it runs.
Richard:Yeah, but didn't they call it a kill switch?
Matt:That's right. It's a short term thing that's going to only be there for Java 9 and will be gone allegedly by Java 10.
Richard:Yeah, well I don't know if you remember but when the, there was one of the developers of Jigsaw there or of the reference implementation and he said "We have a command line option and it's -killswitch" or something like, I can't remember now, but there was an audible groan from everybody in the room and the reaction was there is absolutely no way I'm going to get that past my operations guy who's just going to say "What on earth are you doing putting kill switches into production code?" And it was a terrible choice of I wouldn't be surprised if they've changed it by the time of release but clearly things are up in the air. We don't even know if it's going to make the July release date. It was July the something.
Matt:So, yeah. So, I mean, I guess the option's there or either it will make it even though it's not perfect and they'll be providing patches reasonably quickly to improve it. It won't, they will take Jigsaw out or they will delay. I mean, I guess they're the options but with so many people voting against and I think what's interesting there is that IBM voted against and IBM, I guess, are the owners of the OSGI, which is an existing modularization platform or at least strong promoters if not the owners. I don't know ...
Richard:Well, it's a committee.
Matt:.. what the relationship is, but ...
Richard:So it would be a similar structure I guess. I don't know much about OSGI.
Richard:It'll be a member.
Matt:So as I see it. So Oracle have sort of complained a bit that they think IBM's vote against is because they haven't adopted OSGI and Redhat are trying to be the big guys on this and saying "Look, we all need to sit round a table and make this, find a way to make this work." So it's interesting the politics going on in the background. It is.
Richard:Interestingly the group that were hosting the hack day was the London Java community and they are members themselves of the expert committee and after that hack day, they voted against as well based on what had happened at the hack day, but they were quite soft about it. They said it's not far off. We only need a few of our fear allaying and then we will vote in favour so ...
Matt:Yes, but I think I've got a sense that in order for this to be adopted it's got to work seamlessly with the tools and that's not just the build tools like Maven, it's the IDEs. It's got to be easy to use and one of the, even little things like the fact that to create a module it has a different file structure from what we're used to seeing in a standard Java project, so yeah, you have this module-info.java but you have to create, if your package is called for example, this is the one I'm using, com.virtualpairprogrammers.accounts, it's one of our accounting systems that I've playing with, then you've got to create a folder called com.virtualpairprogrammers.accounts as well as ...
Richard:The folder itself has dots in it.
Matt:Exactly. As well as you also still need the full then com and in another folder with a package name, so you've got a very different file structure which there's no option in Eclipse or any of the IDEs right now to say new java module. There's only java project and then you have to go and start hacking the file structure to make it work and say which bits are in the build and which bits aren't. Nothing's easy at this stage. Now I'm sure that by the time of release there will have to be a new version of Eclipse and all these IDEs built ready to deal with that.
Richard:I'm surprised that they haven't because there's been early access versions of Java 9. In fact, Jigsaw has had a reference implementation for years, so I'm very surprised that Eclipse don't have all of this sorted, ready for July the whatever.
Matt:Well, they might do, but I get the sense that some of this stuff hasn't been that stable. That they've been playing with things like file structures. I might be wrong there.
Matt:Which would of course stop them doing it for an early release.
Richard:Well, it's clear that there is a lot of confusion in this area and it's going to take quite a while for the confusion to settle down. I think we should be pledging to, we're going to do a Java 9 course. It'll be a small course. We'll do a early review.
Matt:It's an upgrade course isn't it? But I guess that there's got to be something going round there about a lack of confidence because even if they fix everything to be released for Java 9 and they get a unanimous vote by the Java committee members to say yeah, this is ready for release and we want it, how much confidence did we have that they can overcome all these issues in the few weeks that are left? To me, I think they've probably shattered a bit of confidence out there and it's interesting that yes, the London Java group are supportive of the changes and say there's just a little bit more work needed. Clearly some of the other Java committee members are not so positive.
Richard:So, cards on the table. We're not members of the expert committee unfortunately, but if you were what would your opinion of Jigsaw be today?
Matt:So I like the concept. It's clearly not release ready and I'm only saying that because I'm not saying there's anything necessarily wrong with Jigsaw. I'm saying that the all the tools that need to support it are not there yet and until they're there and you can have a seamless experience as a programmer, so you're not worrying about file structures because that's done behind the scenes like it is today. Until we get to that point, it's not release ready for me.
Matt:But I think the idea, I have no issues with the idea and at least it will be optional whether or not you build a modular application or a standard application like you would today.
Matt:That's fine for me. What's your view?
Richard:My view, well I was going to say I hate it. I absolutely hate it because this is a solved problem. Obviously modularization is a no brainer. We talk about it a lot on our previous courses, coupling, cohesion, all that kind of thing. We have a microservices course where the whole point of that is the equivalent of a module in Jigsaw. We are deploying as a standalone, a standalone application in fact to its own standalone machine. Modularization yes, is great and tools to help us be more modular are great as well, but it's a long solved problem. We've had OSGI for 16 years or something. It's there and it works and anybody who wants it can use it and now we have this committee led exercise which is, it feels like this has been enforced on us. If we want to move to, I know you're saying it's an optional but I still can't quite understand that. I don't get it and it feels very ham fisted. It's the usual committee led sort of half baked solution that isn't as good as other solutions that exist and there's confusion abounding, so I don't like it.
What I do like however, the thing we've not talked about is the other part of Jigsaw. It should be a separate thing really but they've sort of mixed it all in is that the Java Virtual Machine itself is going to be modular.
Matt:So why do like that, Richard?
Richard:Well, one of the principles of software engineering is efficiency and it is a nonsense that any Java application today up to Java 8 that you run has to run with the entire set of Java libraries, so we have a web application running right now, soon as you start the virtual machine for your web application, you've also got on the class path effectively, it's not quite that, but it's there. It's loaded into RAM, the entire graphical user interface library in Java, Swing. Almost nobody uses Swing these days but it's there. It's there in the libraries, has to be loaded into memory when your virtual machine starts up which is just incredibly inefficient, incredibly wasteful. It's not a great big deal but it's there, so the idea is now you will build your own virtual machine which only has the components that you need. That's got to be a good thing. I'm not familiar with the mechanism for doing it or how well it does it, but the principle is a very sound one.
Matt:So, my sense on this, okay, it's a sound principle. I get what you're saying there, but will it give any practical benefit or even be used? So let me, if I can, tell you why I'm asking that question. In reality if I'm building a Java application that I am going to do one of two things, I'm either going to deploy it to a server or I'm going to be giving it to a customer. Okay, you might, but there are other things of course you can do with Java applications but let's just start with those two. Deploying to a server, would a smaller JVM, how much of a difference is that going to make?
Richard:I think it could be significant because I know we tend to think of servers as being massive machines with a lot of RAM, but for example microservices, we want to be able to, I mean, we'll leave Docker and containers and so on out of the equation but let's assume as we do on the microservices course, we want to deploy a module to a single instance on something like Amazon Web Services. We want to be able to run that on the smallest possible instance we can for efficiency, for cost savings. So, it is the case that the smallest instance you can get on Amazon is a T2-nano instance and it will run Java and it will run Java quite well, but it's not very difficult to make that JVM run out of memory. It just crashes at runtime.
Richard:For example, if you're wanting to use a T2-nano to host a Jenkins server, it's just not quite beefy enough. It eventually runs out of RAM. So, I believe I have not tested this, I have not measured it in any way but if you could run a smaller virtual machine that only has the bits in that you need for a web application, I believe it will be much, much easier to run on a small instance.
Matt:Okay, so I think you've identified there actually is a really good use case then for this because where I was going to go with this was that right now, and this may be something that changes, if you, say you're developing on a Windows computer, you can create your, I'm calling it a cut down version of the JVM so your JVM that only contains the parts that you need for your application and of course any dependencies that those parts need. So you end up with a JVM that generally will be a lot smaller than the standard JVM but if you're using Windows machine you can create a Windows JVM because it's creating it as a subset of the JVM on your machine. So, for you to then run it on a server, on an Amazon server that's running some Linux variation, you will need to create your JVM to run on that server.
Richard:I'm not clear about that, so what you're talking about here is a new feature of Java 9 called Jlink which is doing the equivalent work of old fashioned linkers if you remember those.
Richard:Now, what I'm not clear about is, is that separate to the cut down, so the module of JVM business.
Matt:So my understanding is that is the way to create your own JVM containing only the modules that your application needs.
Richard:I haven't realised that because I don't want to do that. I don't want to, so all, as far as I could tell, all this linker thing is doing is it's just embedding the JVM which is of course platform specific ...
Richard:... into a kind of a packaged, it's not doing anything particularly clever and people were getting ...
Matt:No, I suppose it's working out what dependencies are, so it knows which bits it needs and which bits it doesn't. I guess that's what it's doing. But that is the mechanism today at least. Now I suspect, I've written a draft blog post about this so there'll be more details hopefully on my blog coming up, but I suspect that actually to make this work, what we'll happen is that there will be publicly available cut down JVMs for things like typical Spring boot applications, so if you're building a standard Spring built web application with JPA and MySQL and whatever dependencies are, then you can say go and download that JVM for your Linux server and that's the right JVM to run, that's my guess.
Richard:Well, I was thinking it was more, the JVM wouldn't have the, so up until now there's a big monolithic jar file called rt.java that has the entire standard class library inside, so you get a smaller version of that.
Richard:You wouldn't have Swing in. You wouldn't have, I can't think now. All those things, I mean, there's millions of classes, so I like that idea. I think what people were getting annoyed about was oh, this is destroying JAVA's platform independence.
Richard:It isn't at all.
Matt:It's not, but the issue of course is that you've got to create the version of the JVM or the cut down version of JVM you want for the platform you're going to run and absolutely. And you need a tool that's going to let you do that.
Matt:Which I suspect someone will come up with that tool.
Richard:I thought that was Jlink. I thought that's ...
Matt:No, so Jlink does it for the particular JVM on your machine and what I think they were trying to say was that if you were going to be providing this, running this JAVA application on a server, you would need to create, use Jlink, recompile your code with Jlink using a machine that had the same JVM or at least the same operating system which, okay, it's a bit messy but I think somebody will solve that.
Richard:I'm quite confused about the whole process but it looks ...
Matt:That looks okay.
Richard:... that actually look quite promising.
Matt:The other thing though that, and I'm just, it's a solvable problem, but I don't know whether it's been solved just yet which is what happens when there's a patch for JAVA. So how does the cut down JVM get updated should you want it be updated? Do you have to create a new one? Do you patch your machine first and then create your new, so that's not clear yet. I've not looked that hard, but I've not seen anything about it, but that's a solvable problem.
Richard:Okay. Okay. So, it's exciting anyway and I think we should be doing a promise. We do tend to be a bit slow in developing courses but I think this one, we could do it quite quickly from the day of release of JAVA 9, we'll get something together. It might be only be an hour or two.
Richard:But if we can do a JAVA 9 quick start to solve some of these confusions and I'm still confused and I've done quite a bit of studying on it, so if we could do a course on that, that would be fabulous.
Matt:Absolutely, I think we can. It's difficult to start it today because things aren't stable.
Matt:And they're moving.
Richard:We will start on the day of release, of the formal release because yeah, even at the hack day with the developers there, they were still unsure about some things that were going to make the ...
Matt:Well, to be fair, they were asking for feedback so that there was a quite a complex Google docs document they wanted people to add feedback to which ...
Richard:Four weeks before, it's just there.
Matt:I know, but they were using that as the basis actually for the feedback they'd engaged which led to the vote against the release of Jigsaw, but they were saying does this work and are there any suggestions as to how it could work better? So, Java is not, so Java 9 is not signed off. It is still being developed and worked on and that's the point. So, what worries me I guess is that it feels like well, they're still working on it and yet they're saying they're going to release it in six weeks and that doesn't fill me with confidence, so I think that for Java 9 to be adopted right and if it does get released in July, there's going to be a very slow adoption process because people need to gain the confidence before they're going to start deploying production applications in it but it has got some nice features and there's other features.
Richard:There is quite a long list of features but I mean, I was sort of planning on going through some of them, but we're a bit pressed for time I think, so maybe we'll stick up on a blog post or something, but I must admit I mean, I'm more miserable about these things than you are. You like new toys and I just see this stuff as things that are going to get in the way of getting work done. I can't get excited about any of the, there's some small changes, some minor improvements but we'll stick up on a blog post the list of, and there's obviously a lot of other blog posts out there already listing so maybe we don't need to do that.
Matt:And I guess part of what we'll do in our quick start course is actually we'll work through those and say well, what are the things that are actually really useful for developers to know.
Matt:And talk about those.
Richard:There's going to be a lot of, well, I say a lot but there's going to be improvements to things like garbage collection under the hood which I think are things to genuinely get excited about in new versions of Java. I wish they didn't tie the releases together. I don't see a reason why they have to wait until a new version of the language to release new version of the JVM. They could release the garbage collection improvements. They could have probably released that two years ago without waiting for this, but, that's the sort of thing that I'm interested in. Anything that will improve performance at runtime is a great thing, so let's leave Java 9 to one side for this week anyway. What are you working on right now?
Matt:So, I'm currently in the middle of a course on Thymeleaf.
Richard:Yay! At last.
Matt:So I've got to say. I reasonably recently did your Spring boot course which is where you first mentioned Thymeleaf.
Richard:And I think I promised to do Thymeleaf and it hasn't happened.
Matt:It hasn't happened so I thought wow, I'm going to pick up that challenge.
Richard:Thank you. That's good. Thymeleaf is great, though, isn't it? It's a simple change to the workflow.
Matt:It's interesting. So having been using JSP for a while, so for those who are not aware this is a system for allowing you to create your views in an MVC application particularly aimed at Spring but you can use Thymeleaf with other technologies as well.
Richard:Really? Okay, good.
Matt:Yes. So, but it's not just Spring.
Richard:It's part of this Spring ecosystem.
Matt:It is. It is.
Richard:It's a direct replacement for JSPs, which is uh, I'm very embarrassed that we have a lot of courses that cover web development generally but we use JSPs a lot but in no way have we ever liked JSP. It totally sucks as a technology and it is ... I hope I've made my feelings clear on that.
Matt:I think you have and I agree with you that Thymeleaf is a pleasure to use in comparison to JSP.
Richard:And it's basically just XHTML, so it's regular HTML.
Matt:It is and this is the big advantage of Thymeleaf, I think is that it is standard HTML. Everything to do with Thymeleaf is additional attributes to existing HTML.
Matt:Which means that you can load up your Thymeleaf files in a browser outside of an application and see what they would look like.
Richard:Which has the important benefit that you can round trip your design with a HTML designer.
Richard:So you've added some code to your view but there's still no problem with sending that to your designers who are in some fancy design studio in Hoxton which I realise we're very UK centric here. What would the equivalent in New York be?
Matt:I have no idea but it's the kind of place where everyone's got a beard and yes, and these yeah, so.
Richard:So you can send it to them. They can make design changes. It doesn't break your code. They can look at it in whatever the equivalent of Dreamweaver is these days because does that still exit?. And I have to be candid here that we eat our own dog food at Virtual Pair Programmers. We develop our own website using the technologies that we teach and one of the reasons why perhaps sometimes our website design gets a little bit messy from time to time is we have developed using, it's not quite JSP but a very similar version of JSP and it has meant it's been very difficult for us to keep the design well designed while we're doing coding updates as well. So, ah, I just, Thymeleaf absolutely is XHTML. I'm sorry ...
Matt:Yeah. And there's two sides to it. There's you get your HTML and CSS files from the designer and it's your job to start integrating those into your application. Straightforward job, that yes, you've got to learn the Thymeleaf attributes and how they work but it's really quite pleasurable or you can build your application and then send your HTML files to the designer afterwards and say make these look pretty and they can do that.
Matt:It works in both directions.
Matt:And it's interesting I think because it's a more, with JSP you get all these tag libs, so there's all sorts of tag libs you can add in. They disappear. Everything is built into Thymeleaf but that doesn't mean that there's quite a lot of attributes to learn about that do different things and so it's not going to be a one hour course. I'm guessing it's going to more like three just to go through it in a bit of detail and what I'm hoping to do at the very end is to have two practical exercises. One to convert a JSP application, probably only with a couple of pages, but to get the experience of converting JSP to Thymeleaf because that helps you if you've been a JSP developer really get to grips with the differences and how to work in a more Thymeleaf way and then also I think I'm going to do a little example as well, where you've got a standard nicely designed HTML page and you're going to integrate the Thymeleaf code.
Matt:So I'm about half way through scripting that at the moment. I love these sorts of things as you know, Richard.
Richard:I've wanted to do Thymeleaf for a long time but it's just one of those things that kept falling off the bottom of the to do list and it is bad that our live website uses JSP but the reason for that is we've got a lot of legacy there and we have considered porting it to XHTML for years now and it's just one of those things that it is going to be painful isn't it to do that.
Matt:It is and actually what I'm not sure about and I'm sure it can be done, but I just don't know how you do it at this stage is having an application where you are some pages are in Thymeleaf and some are in JSP where you can run both together.
Richard:Oh, sure. Oh, absolutely.
Matt:So you can do a gradual migration.
Richard:Yeah, it's just a Spring MVC. If it's an MVC you have a view resolver which makes a decision of how is this view going to be rendered.
Richard:So, it's an easy job to do. We could do that, but ...
Matt:I guess it's a, the reason why I've said I don't know how you do it is because at least in Spring boot not so in a standard Spring MVC application, there's no configuration, so having Thymeleaf on your class path is all you need. You don't write any code that says, you know how in JSP you have to put in a couple of lines in your application properties that says the location of your files and the fact that they've got JSP ending. Don't have that in Thymeleaf. It's standard.
Richard:It's automatic configuration until you want to do something clever like mixing JSP and XHTML.
Matt:So it's obviously doable.
Matt:Yeah, and it's a really pleasurable experience, so I'm doing that and actually, our oldest course today at the moment is Java web development.
Matt:I say it's our oldest course. We started with Spring fundamentals but we've revamped that course. So, and actually we've had a, it's still a very popular course.
Richard:Yeah. It's embarrassing really.
Matt:It is but my thinking is that once I've finished Thymeleaf, I'd like to then look at that, bring that up to date and I know we've promised, we have a number of customers ask us for the final bit of the WildFly series which is JSF which, Richard, for those who can't tell from his noises he's making is not a fan, but the fact is people are using it and ...
Richard:This is a very much a tightrope that we walk in this business that we're enthusiasts for new technology and we want to use the latest greatest shiny things and I know our customers, many of our customers share that as well, but equally we're also serving an audience of people who probably still enthusiasts but they're working on projects where they're having to use, I am going to call JSF legacy. I'm sorry if that offend anybody, but it's certainly legacy on any of my projects and we want to serve those people as well. So, we're not going to say "Hey, we're never going to cover JSF." We had it in the old library under the Java EE course and we should probably have it but I don't want Virtual Pair Programmers to be seen as an advocate for a technology like JSF which I think is just horrendously broken. It's horrible.
Matt:I think what we'll do is a light touch on it but one of the things I don't know yet and it'll be interesting to see is whether you can use Thymeleaf with Java EE because it's not just to say a Spring project and if you can ...
Richard:JSF uses Facelets which is the direct equivalent. They say it's HTML.
Richard:It's possible actually that Thymeleaf might have even been inspired by Facelets. I think Facelets possibly came first.
Matt:Right. I know one of our customers has asked us whether we'll be covering as part of that when we get to it, PrimeFaces which I know nothing about. I've had a very quick look just so I could answer him.
Richard:It was in the, so just in case anybody doesn't know, we used to have a course on Java EE 6 I think it was which we've retired now, but a large part of that Java EE 6 course was JSF and we covered PrimeFaces on that, so ...
Richard:... and it's just a plug in library that gives you extra components. Fancy tables and ...
Richard:... it's a nice library, and it is probably one of the compelling reasons to use JSF if you really want to go down that route. Yeah. I don't like JSF.
Matt:No, well I will get it through just to finish off that series because we do have people asking for it, but ...
Matt:... what are you working on?
Richard:Well, I'm supposed to be working on Docker which has been announced but we haven't put a date on it and I've already had several customers saying when is it going to be released, so I'm sorry as usual I'm running late. What I'm actually working on, we are doing a major upgrade of the backend of our website, so the changes should not be obvious to customers. It's a structural thing that we're doing which we're trying to make everything more microservices-ified and we're just improving everything that we do on the backend. Unfortunately that's the led us into some pretty nasty problems. We use Grails for the website.
Matt:Ooh, you've admitted it.
Richard:Well, yeah, which we loved at first but less so now. We were on a very old version of Grails which needed updating and upgrading Grails has been an intense pain, so maybe on a future podcast we'll talk about Grails and why do we not have a course on Grails would be a good subject for a future podcast but we don't have a course on Grails and we're probably not going to have a course on Grails. Matt is nodding at this point or yes, no, maybe?
Matt:Without trying to take away from the conversation we might have at a future podcast, I don't think there's the demand out there for it.
Richard:I agree. But we are using Grails at least for the short term, so I'm working on that big apologies that Docker is still in development. Where are we now? We're in May. I would hope it's released in June, but I'll go into no further detail than that. It won't be a big course. I'm intending it to be a relatively gentle introduction to Docker and I will tie it into the microservice course as well so we'll show how you can use Docker in a microservice environment, but there's a lot of work still to do on it I'm afraid.
Matt:And will there be more in that microservices track to go after Docker?
Richard:Yes. Well, yes and no really. What we're, I can proudly announce that tonight we are attending, is it the Leeds Java Virtual Machine group or something?
Matt:I think it is. Yes.
Richard:So, we'll be going to that and it's a talk on Reactive technologies so it's a massive admission that we have nothing in our library on Reactive. It's a huge topic and we've been keen advocates of it for a long time even before we'd heard the word Reactive. It is a fundamental principle of a well designed system. We need some material on it. Whether that becomes part of the microservice track I'm not sure, but we'll certainly going to have material on Reactive and what we'll do possibly on the next podcast is we'll report back on what we did at the Reactive night.
Matt:Yes. I'm looking forward to that. We go to quite, or we try to go to as many of these meet ups I guess they're called as we can. We're based in Leeds in the north of England and there's quite a few here and in some of the other local towns, particularly Manchester.
Richard:And it's true across the whole world isn't it? It's, you can ...
Matt:If there's one near you and you've never been, I really recommend them because it's a great way to find out about technologies that you've never come across before or hear from people who've used stuff in a different way to the way you've used it and have, people tend to talk about the problems they've experienced and how they got round them and I think that's a ...
Richard:So just go to meetup.com and we'll include a link in the show notes.
Matt:Okay. Having show notes, are we?
Richard:Well, we haven't talked about that but there will be show notes. Should we be subtitling this?
Matt:I will leave that one for you to decide, so ...
Matt:It sounds like we're getting to the end. If we're starting to talk about the way podcasts work, which is where we started we're obviously getting to the end of this one.
Richard:We are. We'll aim for an hour on each one and we're up to about 55 minutes now, so it feels like about the right time to wrap up, so possibly then, podcast number two will be all about Reactive.
Matt:Okay. Well, you've made that commitment, Richard, so well done. We'll hold you to that.
Richard:That's another commitment I'm going to break. So just like my Thymeleaf commitment, so I think we're about out of steam.
Matt:Well, if you've stayed with us, thank you for listening.
Richard:Yeah, thanks a lot for listening and we'll see you next time.
Matt:Just before you close off, Richard, closure is, because I know you're going to hate me saying this but if you have any feedback please do send us a little message through our website would be great, and especially if you've got ideas of things we could be talking about. I think that might be nice for us to hear and I get to see those messages and I filter them before Richard does, so that's the plan. Thank you. Anyway, and hopefully see you next time.