In the evening I was reading this discussion:
http://www.theserverside.com/news/thread.tss?thread_id=61352
Did not read all the comments. Among the comments I have read, this one appeared sympathetic to me.
In (my) IT maturity cycle, I don’t think you could get to highly productive Enterprise app development tool without a strong, mature, low-level language and platform to build on. Things were going that way with client/server until the internet changed the dynamic, like client/server changed green screen, like green…
Now that TCP/IP driven systems (when you get down to it) and open standards have matured, we can reinvent VisualBasic again. Spring is doing it for VmWare cloud, Google provides IDEs for GAE cloud, Redhat, MS, yadda yadda. Problem is, Java may not do so well in non-enterprise solutions against vendors that want to control their delivery channels through proprietary devices and cloud platforms.
When I think of Ent. app development, I think license costs, seats, and lock in. With the availability of mature, open source frameworks and accessible cloud platforms (no Google, GAE isn’t portable enough) I just can’t see trading perceived short-term productivity for long-term lock-in. Look at SalesForce – they have a new word for everything.
“not dead yet” and Holy Grail seem to go together. And Java is far from dead and IT will always chase after silver bullets and non-technical Holy Grail solutions but never quite get there.
posted by Andrew Clifford
As for the original post, I think to state Java is dead has little to do with reality. The super power companies Google, IBM and Oracle having big stake in Java related technologies does count, but that’s not all. The vastly available Java developers and the common mind patterns among them might be the driving power for Java’s liveliness. Nearly every university offers some Computer Science courses with Java as the implementation language for homework or team projects. As long as Java lives in the Software Engineering lectures, Java will be alive in the field. As many comments in the thread have already pointed out, Java as a language and a platform, has always been improving and it is good enough for building modern enterprise applications.
In fact, not only Java, nowadays many languages and “technologies” are more than good enough for building decent applications, given there are highly skilled developers at that technology. If I were to choose a technology for a software project, besides the “license costs, seats, and lock in” that Andrew Clifford has pointed out, developer’s skill set is a really important asset and I would leverage it as far as I can. Applications can be built one way or another. But most developers are really good at one or two core languages of their own. It is easy to say “Hello world” or “Good morning” in many languages, but most people can write good poems only in their mother language. If the developers in my team can write good Java code and they love to develop in Java, I would do everything to let them think and express in their native language. If the end product has to run in a web browser, I’d try my best to get them tools such as Java-to-JavaScript translator. As long as the framework produces usable and correct JavaScript, my developers do not have to wrestle against a language or technology they are not very familiar with. Today JavaScript is hip, but who knows what comes next. Always chasing new languages does not really contribute to the quality of the software. I would rather focus on getting the business logic right and do more business with the software. Happy and self-motivated developers write better code. If certain language makes my developers unhappy and demotivated, I would try my best to avoid it or bridge it with tools.
Besides the implementation code, quality software consists of many other things. I am all for agile methodologies and I am all for self-explaining beautiful code, but lacking of necessary develop documentation is not something I can tolerate. Design decisions, algorithm choices, etc. has to be well documented. If the software consists of more than 20 classes or “modules (for classless languages such as JavaScript)”, documenting the software with UML diagrams at the end phase of the development is a must. I do not consider someone a good developer if he is too lazy to let his colleagues understand his the software with less effort. Besides, showing clients the source code (no matter how beautifully it is written) when discussing business logic is simply bad manner and not an option for me.
Automated unit/integration tests, issue tracking system and continuous integration are all necessary parts of development of quality software. Most of these tools are generic, so it really does not matter which language I am going to use for the next project. What really matters, in my biased opinion: Clients’ business requirements (we have to understand client’s business really well) and my developers’ core skills (we must be able to map the business logic into some machine-executable code elegantly). The technology to use should be derived from these two constraints, plus “license costs, seats, and lock in”. Software is peopleware at the very last. As long as there are people who learnt Java as their native language from universities, I do not see any danger for Java investment in the whole software industry.
