Is Java over the hill ?

by Andrew Anderson

Seems like there is a buzz in the air these days about the demise of Java. Two recent examples include Marc Andreessen's comments on how Java has acquired all the issues that its predecessors have and how PHP will take the lead away from Java in the not so distant future and Bruce Tate's recent OnJava article on specific places where Java is losing ground to other languages.

So is Java on the way out ? I hope not, because I believe that fundamentally Java is a great language, but Java does have some real problems. I think the root cause of most of the problems is Java's enormous scope and complexity.

A couple of months ago, after reading all sorts of articles on Ruby and Ruby on Rails, I decided that I would try them out. My goal was not to create some epic program, just to get something working that gave me an idea of what Ruby was all about. I started by downloading and installing Ruby (not realizing that it was included in OS X) and some libraries, then I downloaded and installed Ruby on Rails, then I found an article at and used it to create my first Ruby on Rails application. Total time from the first download to the program working, including setting up the database, was somewhere between an hour and an hour and a half. Not too bad, from my point of view that is just about the right amount of time a developer should be willing to dedicate to going from no knowledge to having a simple working demo. The same thing in PHP might not have been as easy to code, but the setup would have only 10-15 minutes, giving me more than an hour to code up an example

How long would that whole process take in Java? Just think of all the steps involved: downloading and installing the JDK, figuring out to use Tomcat (or some other servlet engine), installing Tomcat, getting the JDBC driver, setting up the JDBC driver, deciding how to do the database queries (either through your own code or with Hibernate or some other package) -- then assuming I didn't go off shaving yacks, I would finally be ready to sit down and write code.

Think about this: Java is so complex that new OS X versions come out months after the Windows and Solaris versions and needs to be compiled and optimized by Apple, not Sun.

What's worse for all this complexity, we don't even get :

  • a basic scripting language

  • a built in, simple web server

  • a built in, simple servlet container

  • a built in build tool

  • ...

Sure all of these things exist in the greater Java community (Groovy, Jigsaw, Tomcat and Ant respectively, for example) but since a large amount of Java's installed base is developing web apps, why does Sun keep adding marginally useful Swing widgets instead of trying to include things that developers might actually use ?

What does Java need to do to get it's act together ?


2005-10-27 13:56:45
The conclusion I came to about five years ago is that Java is in an awkward space, neither high-level nor low-level enough to be really useful.

High-level languages (i.e. "scripting" languages) are great because they have very powerful language features like blocks/closures, native language support for dynamic arrays and dictionaries, and a high degree of dynamism and introspection (taken to the extreme in Ruby). They're also interpreted, freeing you from the compile-link-debug cycle. These abilities let you leap tall buildings and level mighty oak trees in a single line of code, so you can express your ideas quickly. These languages also have very high-level frameworks that make use of these language features to let you handle typical tasks like networking and serving web pages very easily. (Ruby On Rails is probably the most extreme example of that.)

Low-level languages, by which I mean everything from C++ and Objective-C on down to assembly, are great because they're highly optimized -- in fact, they actually run just as fast as native code! :-) They also have direct access to all the APIs of the platform you're coding for, without any troublesome glue layers. That makes them the best choice for writing desktop apps.

Java has some traits of each category, but unfortunately not enough of either. The language is still close enough to C++ to make it annoying to write complex things, and despite a decade of hype, it's nowhere near fast enough to use in a desktop app that people will voluntarily choose to run (as opposed to being forced to by an IS department.) And the frameworks, at least at the GUI level, offer a plain-vanilla feature set that can't match the cutting-edge features of the Mac OS or even Windows.

So in my programming, I use Objective-C with Cocoa for desktop apps, which since it's more dynamic than C++ is relatively non-painful. For web stuff where performance isn't so much a concern and the platform is standard HTTP, I'll use PHP for quick hacks, and I'm definitely going to learn Rails for the next time I do something bigger. But in either scenario, Java just isn't as compelling.

2005-10-27 15:10:14
enterprise-scale Java; desktop applications
since a large amount of Java's installed base is developing web apps, why does Sun keep adding marginally useful Swing widgets instead of trying to include things that developers might actually use ?

1) In an enterprise-scale web app, the planning and development time is measured in months, if not years, and so the one-hour-to-a-demo measure is laughably irrelevant.

2) Java is still the best for developing cross-platform desktop applications. I have written several relatively large Java Swing apps (one is around 40 thousand lines of code) and I haven't seen a performance problem.

2005-10-27 15:49:12
enterprise-scale Java; desktop applications
1- laughably irrelevant. wow. of course it should takes weeks to get to a proof of concept working for any idea that is actually worth pursuing.

i am not claiming that an enterprise app should rely on the built in Ruby webserver or a simple Apache/PHP setup, much less coded up in an hour. i was pointing out the unnessecary complexity of the Java environment. designing enterprise scale web apps, and setting up a decent development/simple server environment are two very different things.

then of course, i wonder when was the last time any decision on an enterprise app was made for purely technical reasons ?

2-i never claimed that Swing was slow, actually compared to the AWT, Swing is quite fast. my point is that desktop apps represent a small percent of actual Java code that is developed and yet Sun wastes time developing new Swing features, instead of adding language features that will help Java survive.

btw, you brought up a pet-peeve of mine. the best way to develop cross-platform desktop applications is to develop the application on each intended platform individually. UI conventions (and I am not talking about just the shape and placement of buttons) differ between platforms. since Java and Swing can run anywhere, it encourages people to use the same UI on multiple platforms, which makes it harder for users on any given platform to understand and use the program effectively.

2005-10-27 16:23:02
Concerning dynamic development/prototyping
I suppose it all depends how you implement your frameworks in Java, but you can do quick prototyping with Java... Apple's WebObjects is an excellent set of frameworks, that allows WO developers to churn out prototypes and finished products quicker than any other environment/set of frameworks I've seen. And it's in Java nowadays.
If you've used AppKit you're going to have an easier time coming up to speed on how to program using WebObjects than a prototypical Java programmer, I believe, but once you're there it's really, really tough to use anything else. You just feel like you're wasting time.
2005-10-28 05:38:21
Difference in scope
There is the danger of confusion between Java as a platform for server-side application development and Java as a desktop application framework.

The massive integration time for new versions of the Java runtime from Apple are of course because Java is pretty much a peer of Cocoa on Mac OS X. PHP can't possibly be used for desktop app development in this way and doesn't require the same (primarily GUI) integration work.

This of course boils down to a weakness in Java when baking off against PHP since its massive scope and versatility count for nothing on the server-side. And there is of course a separate debate to be had about the value of its massive scope - perhaps this is as much a hindrance as a strength for Java...

However even on the web application server level there are some stark differences in development time as the article states. The complexity of the J2EE framework (pretty much the only platform for server-side Java development, WebObjects isn't much of a player in terms of momentum/market presence) means that there is a tougher learning curve and slower implementation time than PHP.

This is also partly due to the more structured nature of object-oriented development, particularly Java-style where classes are (generally) in separate source files, with fairly strict compile-time checking... and then there's the whole fix/compile/deploy issue.

Then again I would say that without disciplined development practices (and a resulting slow down in development times), PHP is a difficult language in which to develop enterprise-scale applications. However you can't beat it for quick-hack turnaround.

Then there are issues of design - PHP is full of ugly specialised throwaway functions like get_magic_quotes() and pfpro_process(). But that's convenient even if you do rely on PHP developers to have thought of everything you'll need. Otherwise you're implementing from scratch which is a knock-on timewise. I consider the Java libraries to be richer and more powerful than the (admittedly extensive) PHP function set.

Java is also suited to working in larger teams, being well suited to logic tier separations and with the power and flexibility (particularly in terms of HTML developer usability etc) of custom tag libraries.

Then there are the deployment possibilities. For example clustering, replicated sessions, entity caching, relational persistence frameworks (e.g. Hibernate) etc all make enterprise scale Java hard to beat, although with the consequential complexity in setup. There's no free lunch.

But for a smallish webapp PHP is the faster and more flexible option.

2005-10-28 17:20:44
enterprise-scale Java; desktop applications
"my point is that desktop apps represent a small percent of actual Java code that is developed and yet Sun wastes time developing new Swing features"

I don't know how accurate this statement really is. I believe that internally companies are using swing a great deal. I am a contractor at a government installation with a mixed PC and Mac environment and we build all our internal apps with Swing. Web stuff stinks compared to Rich GUI apps and our user's love the apps. With minor tweaking the applications look native on all platforms. As a matter of fact, I have pushed for the purchase of many PowerMac's because our java apps will run on them. I think if anything SUN should have thrown more at Swing to provide an application framework similar to Cocoa's Bindings and mulit doc's.

2005-10-29 12:39:47
enterprise-scale Java; desktop applications
the best way to develop cross-platform desktop applications is to develop the application on each intended platform individually

I agree that this would be the best way in an ideal world - however we don't live there - and the alternative is often to build a Windows-only app.

Note too that it is possible to make Java apps conform to most of the expectations of the platform - e.g. a menu bar at the top of the screen on OS X.

2005-10-30 11:19:01
enterprise-scale Java; desktop applications
"1- laughably irrelevant. wow. of course it should takes weeks to get to a proof of concept working for any idea that is actually worth pursuing."
Why not use PHP for prototyping which gets your job done is few hours and use Java for implementing in production.
2005-11-01 15:04:40
what a nonsense.
I am very impresed by all the programmers that seem to understand closures. And a language that implement them must therefor be fantastic. Objective-c must always be faster then java because it is compiled to native code? i think not! Today i was debugging some python to find a error that a java compiler will find at compile time for me dynamic are sometimes slower to develop in. I even think python is a lot nicer than ruby generators and list comprehensions are really a good idea a lot more useful then closures and blocks
2005-11-02 14:56:16
enterprise-scale Java; desktop applications
Proof of concepts are rarely the way my company works (which shall remain nameless :) ). The ideas come down and we, the developers get to implement. As a result, the requirements definition is often very poor at the start and a continual process of refinement with the internal user. Proof of concept is irrelevant here. If you chose to use proof of concept as a method you may lose a week or two of developers time which unfortunately most companies are far too tight (cheap) to allow for. I have nothing against other languages, some are really well thought out but the reality is that there are a lot of positives for the heavyweight architecture of the J2EE as there are negatives. It's ability to interoperate with some very heavy capacity applications for web support such as just about any database you pick, just about any web server you choose make it sometimes a hard to beat solution. Is it tough to learn, yeah. Have I seen anything better that is as comprehensive and stable, no. Admittedly I haven't worked with PHP or Ruby but I'm going to make a guess they're not radically more capable than Perl and I use Perl. I haven't seen Perl take over the web landscape either, though it does have its place. So, in a nutshell, I think it's overstated to put it mildly that Java is on the decline. I recently read another similar article that I am more in agreement with... the J2SE needs to be paired down. It tries to be all things to all people and we know this usually fails.
2005-11-02 15:03:48
enterprise-scale Java; desktop applications
This sounds a bit like sour grapes. There are a lot of developers (myself included) that would like to do desktop application development with Java but the reputation is that it's too slow, etc. The speed issue I think is not relevant anymore given the research I've done. There are some annoyances though that keep Swing from being a truly professional GUI platform such as, well the gray spots that J2SE Tiger purports to fix. The layout of some of the text items such as JMenuItems is such that you create hacks to get them to align properly etc. It's a hassle and needs to be fixed. To put it succinctly, Java has a larger user base and Web Development/Enterprise development is only one facet of Java. Desktop applications are still very relevant and the write once debug ... er, run many is still a good paradigm. I don't see any of the alternatives you mentioned providing this capability and I don't see one world, one cpu, one operating system happening anytime soon! FWIW.
2005-11-03 21:30:53
Speed of Java Development
I guess it just depends on how comfortable you are with Java APIs. I have no problem developing complex GUI desktop apps in an hour. I code all of the GUI by hand, and don't use a GUI builder. What pains me the most about people griping about Java is that most probably haven't learned enough about Java nor understand the practices of correct Java coding to be productive. All the silly GUI builders and J2EE wizards shield the developer from the exposure to the language basics that they need to be comfortable and effective with it...

We still see people who don't know to use SwingWorker. We still see people creating static layouts. We still see people who hardcode paths inside their programs. We still see people who don't know how to use resource bundles. We still see...

2005-11-04 04:10:50
Speed of Java Development
YES! we still have people who wants to learn and move Java but is stoped for all that complexity, but we we still have people like me who had to abandon delphi and accept the chalenge of Java.

Java is nice, Swing is hard ...

2005-11-04 09:45:06
Built in, no thanks
The problem with Java isn't that it doesn't have "built-in" X, Y, or Z. The problem with Java is that it does have these things, and they create a massive unnecessary bloat that makes it difficult to manage. The core Java "runtime environment" includes everything from custom sound APIs to JDBC. What Java needs is a thin core library, I'd like to see a core runtime environment that throws out much of the extra crap.

In addition, one of the major hurdles to Java is that it is held back by Sun's draconian distribution policies. If people were able to distribute the Sun libraries then maybe we'd see more rails-esque innovation.