We interviewed 11 executives who had spent most, if not all, of their career working in and around the Java ecosystem. We asked them for their suggestions for developers working with Java.
Specifically we spoke to:
Anthony Kilman, Tech Lead, AppDynamics | Gil Tene, CTO, Azul Systems | Bhartendu Sharma, Vice President of Operations, Chetu | Charles Kendrick, CTO and Chief Architect, Isomorphic Software | Fred Simon, Co-Founder and Chief Architect, JFrog | Ray Auge, Senior Software Architect, Liferay | Michael Hunger, Lead Developer Advocate, Neo Technology | Brandon Allgood, PhD, CTO, Numerate | Dr. Andy Piper, CTO, Push Technology | Jonas Bonér, Founder and CTO, Typesafe | Toomas Rὅmer, CTO and Founder, ZeroTurnaround |
A consistent theme is the size of the ecosystem and the amount of pre existing code and programs that are available in the libraries and the user groups. If you don’t see what you’re looking for, ask before building - this will save a lot of time and effort.
Here’s what they told us:
- Look for good open source competence before writing your own software - look at the library. Look at the Java 8 streaming feature as it changes the way we do development.
- While Java has a pretty shallow learning curve it goes very deep with parallelization, reflection JVM. Continue to learn for years and it will still surprise you. If you think you know Java very well, you haven’t looked deep enough.
- Move to containerization with deployment and development with Docker and Google. The lines between systems and runtime environments are blurring. There are synergies using container technologies - you get quality and reliability. Java gives you the ability to build virtual machines. Don’t be afraid to crossover between technologies.
- The most critical infrastructures are built in Java or a JVM language. Hadoop, Cassandra and Spark, the biggest databases in the world, are built in Java. Java is a responsible way for people who want to play with cool stuff.
- The size of the ecosystem is truly massive. The breadth of the ecosystem can be challenging for developers. There’s a massive community enhancing functionality that you can reuse and accelerate app development. Don’t build something without checking to see if already exists. There’s always more to learn about Java. And, it’s always possible to shoot yourself in the foot by overcomplicating what you’re building.
- Learn and become certified in object-oriented skills. You need to understand the concept to use Java and everything it has to offer. Have a working knowledge of the APIs within the platform. Don’t reinvent the wheel. Use the community. People loyal to Java share and contribute their knowledge. A lot of open source exists. Look for opportunities to build on top of these applications. Be flexible and use what’s out there as it will speed your development time.
- Build for the long-term, not the short-term. We’re currently building technology pre designed to fail due to evolutionary changes in the industry. A five-year lifecycle is huge in the IT industry in contrast to airlines, aerospace, trains, medical systems and telephone systems. Build for the long term, don’t assume the product you build won’t be running long.
- Continue to progress and learn. Join an open source project to learn remote collaboration, read other code, get feedback. There’s no ego in code. Put yourself out there. Put yourself at risk by contributing. Read as much as you can. keep up with the latest research. Have fun.
- Be active in the community, this is what makes Java great. The reason why we have so many open source libraries is because we have a great community. Learn and succeed by participating in the community.
- A silent majority use Java but don’t give enough back to the community. Share what you’ve learned and done no matter how small. There are 60 million developers using Java. If more would participate in the community by fixing and testing, the effect would be tremendous.
- Java’s static type checking ability needs to be looked at as just another form of automated testing, and structuring code to allow more static type checking needs to be weighed against other forms of automated testing. Specifically, we find that if a developer has spent too much time with Java to the exclusion of other languages, they tend to expend heroic efforts structuring code so that it’s possible for the Java compiler to check more error conditions. This effort is usually better spent on automated tests, which can catch a much wider range of error conditions.
Based on your experience with Java, what advice would you share with your colleagues?