Earlier this month, our very own CTO – Charles Kendrick – was interviewed by Marketing Strategist and Growth Hacker, Tom Smith. This interview was part of a series for DZone’s 2015 Guide to the Java Ecosystem, coming in October.
Tom’s article is below and the original can be found here. It is well worth a read!
A Candid Opinion on the Threats to Java
Charles has an interesting take on the evolution of the Java Ecosystem. He’s certainly optimistic, but he says that Sun’s missteps and Oracle’s lawsuits still threaten the community.
I had the opportunity to interview Charles Kendrick the founder and CTO at Isomorphic Software about the state of the Java ecosystem today and moving forward. This was part of a series of interviews for our 2015 Guide to the Java Ecosystem, coming in October.
Charles had a more unique perspective than some of the other folks I interviewed and I thought the the followers of the Java Zone would like to see his perspective and let us know [here] how you would answer these questions.
Q: What type of Java projects have you worked on?
Isomorphic produces the SmartClient and SmartGWT HTML5/Ajax frameworks. Both use a Java server, and SmartGWT uses Java on the client-side via GWT.
Q: What do you see as the most important parts of the Java ecosystem?
The tremendous breadth of useful libraries tends to mean that any enterprise project needs to be using the JVM, even if a language other than Java is chosen.
Q: Who are the most important players in the Java ecosystem?
Oracle and Google (Google because of Android).
Q: What sources do you use to stay abreast of industry trends?
DZone, StackExchange, SDTimes, and various TechTarget sites.
Q: Where is the greatest value being seen in Java today?
Server-side usage in the Enterprise, specifically large-scale, database-oriented systems involving integration between multiple services or platforms, and distributed transactions.
As a language for describing UI, Java is used because it’s popular and well-known, but its expressiveness is very poor, and other languages tend to be a better choice.
Q: Who’s in charge of different Java-related projects at your firm?
We have multiple teams implementing both framework features and customer projects in Java.
Q: What are the skills that make someone good at this?
We will not hire anyone who only knows Java, which we would consider a very bad sign. We look instead for people who are smart and get things done.
Q: Which other programming languages and frameworks do you, or your firm, use?
Q: How has the Java ecosystem evolved over the time that you’ve worked with it?
Poorly. Sun’s lack of leadership and major missteps (eg JavaFX, JSF) have led to a plethora of conflicting approaches in basic areas of the Java platform like UI and data binding.
Q: What are the obstacles to the success of Java-based initiatives at a company?
The poor expressiveness of the Java language means that code takes longer to write, is harder to read, and tends to be rigid instead of flexible in the face of new requirements.
Java continues to struggle from the “jar hell” (in analogy with DLL hell) that .NET solved years ago with .NET assemblies, and the various solutions keep getting pushed out (“Project Jigsaw” is now planned for Java 9).
Q: Do you have any concerns regarding the Java ecosystem?
Oracle’s willingness to litigate innovation out of existence, specifically their lawsuit against Android, could easily cause many partners to jump ship to another platform, causing Java to stagnate.
Q: What’s the future for the Java ecosystem from your point of view – where do the greatest opportunities lie?
Q: What do developers need to keep in mind when working with Java?
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.