The trio talk with Client Server Java Team Leader Adam Juckes about what they love and hate about working with Java, and what the future holds for the language.
Adam Juckes : When you're considering a new project, if you're predominately a Java house, what leads you to the decision of what language or frameworks should be used, how does that conversation happen?
Ryan Zakariudakis : What we usually do is we need to figure out what you're trying to achieve first. All three of us have had projects where we all have to figure out what approach to take first. We look at what the end product we need to get to, we figure out what the existing technology we have is, plus what boxes you need to tick to get there, and that really flows naturally into what language and frameworks and design patterns to go with for new work or additional work.
David Manning : I picked up TypeScript from pretty much fresh, just over a year ago and that's been quite a change. What prompted that decision? To an extent it’s who shouts the loudest, but also interest in new languages comes into it; I've done Java for 8-10 years, and something else is here and it's exciting and new. For us it was the right decision - we're writing a lot of APIs so native support for JSON is great, there's no deserialising like you would have to do if you were using a Java client, say. We also looked briefly at cold start up times, and as we know, JVM has quite a slow start up time. I remember reading that new features in Java 9 might help that. The low start up times for Node are really quite snappy. That works nicely as we don't have to worry too much about cold lambdas slowing down the UI (we put in warm ups but most of the time it's not necessary). Where you're going to deploy it is a big consideration.
AJ : I guess a lot of those decisions, who shouts the loudest, is also reliant on having a command chain that's willing to listen to those discussions and give you the tools that you need.
David : We were very lucky in that we were allowed to do TypeScript and we're lucky in the sense there's never a punishment for getting it wrong.
Ryan : If anything, if it's a hypothetical change, we'll go "Alright" we'll try it on the small part of the system first. Test it, see if it works. It's better doing it that way.
Jack Liddiard : We got tripped up quite badly when we tried cold start time with Scala . That was a whole kettle of fish, wasn't it? We batted it off as nothing because once it was hot then the cold start times wouldn’t matter. However as we got more and more services, those cold start times of 3-4 seconds started to grow exponentially. This proved real problematic as Amazon Lambda can tear down your Lambda at any points, hitting you with a 3-4 second cold start. When you're trying to route calls and detect fraudulent activity in under 500 milliseconds, those cold start times were absolutely killing us.
Ryan : If you're using microservices and chaining of lambdas (your microservice calls) then your cold starts kind of multiply together and that's way worse a single cold start.
Jack : The only other thing I'd say is that it depends on the user case. Imagine trying to shoehorn all the machine learning stuff we're doing into Java - that'd be dreadful! You've seen some of the Python code that has to be written. It depends on what you're actually trying to do, but if the whole machine learning space is in Python, if you're saying "This is strictly Java". I remember interviewing at a company and they asked me what my opinion of Scala was and I told them, and they said "Oh we're a strictly Java house". If you went in there and said "Right, we need to do machine learning" and they're strictly Java, you couldn't do it. They're not going to throw away decades worth of packages and content on the eco system.
AJ : There has been a bit of a case of what's been said so far of the case against Java, what are the benefits of using Java? It must still offer value somewhere?
Jack : It's an unfortunate thing that every company has something written in Java. We have this thing called "CUSDAD" and it's basically an abstraction for how our telephony channel gets switched. It abstracts a lot from you. So instead of talking about twiddling these knobs here and there, it's a bit like saying, "I want a number to go from here to here", commit that and you'll be able to dial that number. It's a bit clunky as an API, but it does the job. Now if you had to re-write that in TypeScript, Golang , or anything other than a JVM language, it would take years because there are some serious bits of code in there. It's a huge library that large institutions have libraries that are too expensive to re-write the thing.
Ryan : The fundamental issue with Java is that its JVM takes a long time to start up, but once it's running, it's excellent. One of the solutions is to go containerised serverless. You start your container with your JVM application up, whatever microservice it is, and you leave it running as opposed to having Amazon start and stop it whenever it decides. You have automated provisioning to scale them up, whatever the load. It's still serverless, it's still better than having to manage an elastic beanstalk or to manage ec2 instances with your own application servers running, but it's much more efficient than knowing as your application scales up you are going to have a cold start for each new instance that’s started. It costs more than AWS Lambdas, but the cost saving on error rates (timeouts) and customer experience is worth it. It's the best pattern we've come across so far for solving that issue.
Jack : It's these absolute behemoth of libraries which companies have had around for 20 years and you have to deal with 20 odd years of code, which is sort of an unfortunate thing.