As you attend conferences, read books and peruse online articles, you inevitably run into a number of diehard Java fans. But few have as much enthusiasm for this time-honored topic as Adam Bien. Known throughout the programming community as a Java champion or even a rock star, he brings more energy to this subject matter than a double dose of Red Bull. TheServerSide caught up with Adam to ask a few questions about exciting new developments in Java—as well as what makes this traditional programming language so useful after so many years.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Just how big of a deal is Lambda?
The Java community is all abuzz with the changes that Lambda may portend. But Adam says the depth of transformation is a matter of perspective. "I would say, for most Java developers, it's revolutionary. For polyglot programmers, it's evolutionary." At first, Lambda can look pretty scary for Java programmers. But by the end of the first day, or late into that night, Lambda starts to feel right. The code is very lean and fits naturally with the Swing Application Framework. Finally, it's possible to write far less code—Lambda even replaces some MapReduce algorithms. Making less code do more is great for enterprise IT since it boosts productivity. It's also a boon for individual developers when it reduces the amount of time they have to spend pair programming with a coworker who is their arch nemesis. It's a win-win.
Is Lambda breaking Java?
This new-found ability to add full methods to Java interfaces goes against the grain for Java programming. In fact, it's practically taboo. Adam's a bit of an iconoclast, "Does it break the language? I don't know; but who cares when it works?" In fact, he says it is possible to add new connection extensions with Lambda without breaking the old connections using interfaces. It's just a new tool in the tool belt and not something to get one's Battlestar Galactica boxers in a twist over. This has all happened before, and it will all happen again. Let's just relax our rigid ideas about what Java should look like and see what happens.
What about Big Data? Concurrency?
There's certainly an argument to be made that languages like Scala and Groovy already offer excellent tools for handling issues surrounding big data and concurrency. But this doesn't automatically mean enterprises should transition to such languages for these solutions. Adam's view is pragmatic, recognizing the challenges of cross-language teamwork. After years in the trenches as a consultant, he cautions against mixing languages too much.
If you introduce Groovy in a project, you experience constant fights between the developers. Throw Scala in the mix and it starts to look like a WWE style smack-down. Scala's all about being type-safe and Groovy is super dynamic. Java is stuck in the middle as the referee who keeps getting hit with a folding chair. The various factions keep arguing about which language is better and forget about the business goals.
Of course, you can't really eliminate Java from a project and rely solely on one of the new languages. It's ubiquitous and far too deeply embedded to simply swap out for a newer model. Why not just stick with what you know?
Basic can be better for business
Even with Lambda added, Java is pretty basic compared to the fancy coding languages developed over the last decade. But Bien argues that it's still sufficient for most enterprise apps. Boosting productivity is about updating your thinking, not changing to a different programming language. If you've got a mindset that's stuck back in the monster mainframe days, you're going to end up with a punch card product.
It's true that you may gain an additional 5% in productivity by switching to Groovy or Scala. But most enterprises and developers don't really care about that final little bit when the initial resource and brainpower investment is too high. And that's what it boils down to with Java vs. Scala. You have to know when good enough is good enough.
As Adam says, "When you look at Java code, you know what happens—because it's just stupid code. That's good because there are no surprises." With Scala libraries, you have to dig down and understand the back story to figure out what's going on. If you don't know what a piece of code does, you use it at your own peril. Sometimes, stupid is smart. So the next time you program, don't be afraid to get stupid with the language.