Recently one or two people disagreed with what I had to say about the impact that the Google, Amazon (and other) API’s will have on Java. Considering the ratio of positive to negative comments (about 3 for and 30 violently against), I obviously need to express myself in a clearer way. The link to the original post is at the end of this article, read on before you consider flaming me.
So , deep breath , here goes.
Compare the the way you develop now , with the way you built software 10 years ago. Do you remember having to manage your own memory? Or the pain of trying to deploy your software on different machines without a JVM? Or the hassle of trying to write distributed software using Corba? Or using a text editor instead of the fine IDE’s (Eclipse, Netbeans or JDeveloper – take your choice) that we have today? Would you consider building your software without a tool like Ant or Maven?
(Shudder). Things have moved on ,and I am very glad they have. Likewise, the way we develop 10 years into the future will be very different. I don’t know what the future will look like, but here’s a simple guess.
The biggest trend today is the move from software running on your computer , to software being delivered over the web. I’m not talking about the buzzwords being thrown about regarding ‘Service Orientated Architecture’ or ‘Enterprise Service Bus’. I’m talking about simple API’s that are available for use over the web today. Like the API’s and products from Google – including their Documents and Spreadsheets, and their Authentication service.
‘Everything should be made as simple as possible, but not one bit simpler’ – Albert Einstein
‘You Ain’t Gonna Need it’ – Anon, XP Mantra
As a good Agile Developer you’d probably agree with these quotes. But what if the most simple way of doing things was not to develop in Java at all? Most people don’t build their own operating system – they use Linux, Windows or OS X instead. Most people don’t write their own Java Server – they use Tomcat, JBoss or your server of choice. The pattern is the same. A small, dedicated core of developers builds the product, and the rest of us say ‘thank you very much’ and use it to get things done.
This range of ‘off the shelf’ solutions is increasing all the time , even before the online services arrived on the scene. As a Java developer , you’ve said ‘thank you’ , downloaded the latest version and integrated it into your solution. The time you save means you deliver other cool features instead. Java is very good at this ‘download and integrate’ process – not only is it a key benefit of Object Orientated Software, but Java has the widest range of solutions available (if you don’t believe me , just check out Sourceforge).
Java can also let us build our solutions (either partly or fully) around the online API’s. Java has great networking and XML handling ability already. In time this will become as normal as the idea of using a JVM. Great – we use these API’s pretty much like we do libraries today, and we can continue developing pretty much as before, right?
Wrong.
Remember, what is the most simple way of doing things? What if the most simple way of doing things was not to use Java but to use a more simple language (like Ruby or PHP) instead? Until now there were a couple of advantages that Java had over these ‘simple’ (and that’s a compliment) languages. When using online API’s these advantages disappear, or worse, become a liability.
- Scalability and Robustness. Enterprise Java is massively scalable (it’s one of the reasons for it’s complexity). But can even you outscale Google?
- Security. Enterprises haven’t (yet) learned to trust the security of online applications. This trust will be hard earned over time. But already you can make the argument that you data is safer with Google / Amazon / other service provider than on your average virus-ridden home PC.
- Language Ties. To use the Java libraries you needed a JVM somewhere in your solution. Once you had a JVM , you might as well write your own solution in Java. But when the product you are extending is hosted elsewhere, you are free to code in the (most simple) language of your choice.
- Always on. As long as you have a connection to the web, your programs can use the API’s. Scripting languages like Ruby and Python can claim to be even more portable. Not only can they run natively in most environments, they can also be deployed via a JVM if that is your choice (under the guise of JRuby and Jython)
- Features. Need a feature that you don’t have in your scripting language? Just borrow it from Java by running in the JVM. How can Java win a ‘features arms race’ against that?
So do we face a form of developer apartheid, where a ‘hard core’ of Java Experts develop web API’s that the rest of us use via scripts? Let me know what you think. Like the original blogpost said, it may not be the end of Java, but perhaps the end of Java as we know it.
Paul Browne 
I still don’t get what your point is. The applications I have worked on are quite complex and specific to certain domains (e.g. contract management, product line management, and manufacturing). Are you saying that Google will provide product line management software? I’m sure you’re not and and I’m sure they won’t. Are you saying that I can use Google’s spreadsheet to build product line management software? That definitely is not possible.
Neil,
‘That definitely is not possible’. Are you sure? Do you mean ‘not possible now, but may be possible later’?
You’re in a good niche with the manufacturing and product management domain.
However, what’s to stop SAP offering online services, with people like you customising the final 10%? If you’re offering customisation (rather than building from scratch) , what’s the best / quickest language to do it in?
Are you really sure it’s Java? Me, I don’t know.
Paul
Observation:
Most of the ‘off the shelf’ solutions that you cite as examples here are tools. They are independent of any particular application domain. They just allow you to abstract over the nastiness of the details on a particular platform. The JVM hides operations like platform specific file handling (if that’s not a counter-example!), Spring helps you tidy up your JSP pages, Swing provides a nice little callback mechanism to simplify GUI code, and the list goes on. What none of these things do is address a domain. Would you like to comment?
I think that you’re making sense if you’re only considering cases where the development of software, more often than not, amounts to merely stringing pieces of functionality together. I’d argue that those cases are few and far between, for now anyhow.
…and then there’s the dependency management 😉
Paul, I see where this and your original post are headed, and I think you raise a valid and not at all flameworthy notion.
Some questions I have arising though are:
is this Monaghan’s year for the GAA final?
more on topic though, I’ve recently built a commercial site that makes heavy use of Google Maps.
Nice API, didn’t cost us a bean. Yet.
My CEO said to me – what happens if Google decide to charge? I said we weigh up the cost of the alternatives at that time, and make the best decision then, and hope it doesn’t break us financially.
Point being – I can’t see the big bank I work at during the daytime, who have me trucking out fairly ordinary Java based business web apps that could easily leverage Google APIs et al, ever saying – “we’ll worry about that liability later”.
I think, from their point of view, the most risk averse and possibly cheapest option in the long run is to have me write all of it in house now. Sure Google have written a spreadsheet app, but _we_ don’t control it, and we can’t have our business balls in someone elses pockets.
Does anyone have any thoughts about how palatable it will ever be for corporates to rely on other corporates not changing the costs involved?
If everyone used Google API, then Google have a massive monopoly, which calcifies over time… ‘don’t be evil’ notwithstanding, what do corporates typically do with massive monopolies?
They milk them for every last penny.
One last question – will your CEO like having ‘(c) Google’ and possibly some adwords selling her who knows what keywords might have triggered, every time she looks at the app’s front end?
Again bravo for not only asking the big question, but being thick skinned enough to ask it again 🙂
Adrian,
You’ve said what I’m trying to say , better than I did 🙂
Major factor in the rollout of this is not so much technical (you’ve already proved it more or less works) but trust – and we’ve a long way to go on this one.
Paul
P.S. Hope Wellington is treating you well. Miss the Wine Bar on the corner of Boulcott Street, but not the frequent earthquakes.