The latest expert opinions, articles, and guides for the Java professional.
We’re constantly having discussions about today’s technology development and there’s no difference between talking about our own internal processes or commenting/predicting/gambling on what other dev teams are doing.
Simon Maple, evangelist extraordinaire, never shies away from a good discussion and, after more than few roundtables, we decided to sit down for a one-on-one to get his thoughts on a few current topics, focusing on our biggest audience: Enterprise Java development teams.
Why is Java 9 important for dev teams?
“First, we should acknowledge the importance and impact of Java 8. It was the most important release in the past 20 years, not only because of the performance improvements but also its massive shift in programming model. Java 8 allowed everyone to write functional code instead of strictly object-oriented, offering up more flexibility than we had ever been seen before. It brought back a lot of users who had moved onto other JVM languages, like Scala and Ruby, but missed the features of Java.
Java 9 won’t make as big of an impact, other than the move to six-month feature release cycles. The new Java Platform Module System will allow the delivery of features much faster, and let teams make changes without bringing the entire platform up to date, but I don’t see developers being that excited as Java 8 because it doesn’t necessarily impact their day to day coding. It’s early days but even with our customers, we’re seeing single-percent adoption of Java 9 whereas Java 8 is around 80%.
The bigger impact will be on the team as a whole: With the ability to release much smaller features faster and the need to, at least, monitor Java version updates, teams have to choose how agile they want to be. This affects everything from the developer, to the build system, to test, to the end user.”
What’s the impact on Java tools vendors?
“Tools are going to struggle the most, especially those without solid companies behind them. Do you spend the effort to keep up with the latest and greatest or take a slower approach and risk getting left in the dark? Unless there’s a good tooling story, developers are going to leave you behind.
Azul is dealing with this by offering long-term support (LTS) for releases designated the same by Oracle (once every 3 years), medium-term support (MTS) for one feature release per year, and short-term support (STS) for 18-month lifecycles. But that’s just one example, each vendor will have to figure out what works best for them.”
Your take on microservices?
“Don’t move from monolith to microservices for the wrong reasons. I can’t stress this enough: Don’t follow the trend – understand and think hard before making the move. What I see is Conway’s Law in full effect. Enterprises think they’re behind the ball and architect out microservices that mimic the structure of the organization rather than basing the architecture on the needs of the app and users.
Scalability, resilience, and security should be the key drivers and teams should be structured to mimic the service they are building. Choose your core services, build them for scale and load, and put the boundaries of the services into people’s heads through organizational structure, rather than forcing them into existing team boundaries. This will avoid a lot of issues later.”
No comments yet.
Sorry, the comment form is closed at this time.