Java completely violates the Coupling/Cohesion rule of software quality. A "module" in Java consists of 5/6+ files containing interfaces, beans, functions, etc. This makes for low cohesion (BAD!). All of these files also need to be connected to each other plus those "frameworks". This introduces a high degree of coupling (BAD!).
The smartest thing the US government ever did with computing was to create Ada. It was designed for software quality, to be provable, and to scale to millions of lines of code. They achieved their goal with the language Ada - and relatively quickly made the mandate that ALL future US government code would be written in Ada.
That (almost) never happened! Ada was new and was not taught in schools. C coders were used to having plenty of rope (to hang themselves) - like untyped pointer addition, while Ada took ALL of the rope away. NO POINTERS? HOW will I get my job DONE? No department of the government took the Ada mandate seriously, and kept on coding in C (or FORTRAN) - so the promise of a better way was squandered.
As bad as untyped pointer addition is, writing several files to do ONE thing in Java is worse.
Java is an incredibly successful toolset - but what is it really and how did it get to be so popular?
To understand what it is and how it got this way you have to start with the problem it was meant to solve: manufacturers working on digital consumer products like cell phones and set top boxes (intended to add internet connectivity to television sets) wanted their software to be updateable in use and able to run unchanged on multiple hardware generations.
Although digital TV has now brought the set top business back in volume, it was the cell phone that saved Java at the time - and because Java gives companies making those exactly what they need: a standardized software platform that’s essentially independent of the hardware, it’s now used on more than a billion such devices.
Think of the problem the phone makers faced as platform instability induced by rapid hardware change and it’s obvious that the PC software makers faced the same problem: platform instability, in their case brought about by Microsoft product churn. In response Sun released Java for Windows, got into a licensing deal with Microsoft, and advertised Java as the write once, run everywhere target of choice for developers.
It didn’t work out that way largely because developers soon discovered that memory and processor limitations on the average user computer coupled with bandwidth restrictions pretty much crippled the downloadable applications idea.
In response people did the obvious: moved their code from the slow and and distant client to the fast and local server - but when that worked didn’t follow through by abandoning Java.
Instead people who wanted to hang onto to working code and what they’d learned writing it presured Sun to incorporate increasingly complex libraries, work-arounds, methodologies, and related kludges into the standard release - thereby eventually producing what we have today: an enormously successful, absurdly over-complicated, utterly out of control monster devouring resources at an ever increasing rate.
In an ironic parallel Sun replicated this process with its own transition from the JavaStation to the Sun Ray. When the JavaStation, a “client” intended to run applications downloaded as Java byte codes for local execution, failed miserably because of bandwidth, local performance, and compatibility limitations Sun responded by abandoning its planned MAJC based smart display to create, instead, the Sun Ray -essentially a JavaStation with all processing moved back to the server.
Thus I’d argue that the use of Java in handhelds and digital TV support makes perfect sense: i.e. that its success in this role has been fairly earned because it’s the right tool for the job. But, I’d also argue that the rationale for the use of Java in business computing applications vanished as soon as the execution environment for those applications moved from the client back to the server - or, in other words, that it makes no sense at all to incur the overheads associated with trying to run downloaded applications on a Windows client when the application you’re writing will actually run on your Solaris server.
More generally, I’d argue first that the Unix mindset calls for spare, elegant, simple programming languages encapsulating principles that are easy to learn and can be widely applied; and second that “business Java” doesn’t meet this standard. Thus the C you learn in school is the C you find in complex applications like Solaris or Apache but the Java you learn in school isn’t what you get in heavyweight business applications where frameworks get piled on libraries piled on methodologies - producing about as convoluted, localized, over-complicated, and resource inefficient a mashup as you can get short of the Windows/BASIC pairing.
Notice that this isn’t generally true for Java as used in cell phones and similar devices. There the existence of space constraints and the lack of generality means that new hires have to learn company standards, a custom API or two, and a development framework but then work with recognizable Java code on the actual applications.
Unfortunately the image of crap piled on crap is the bottom line for business applications developed and maintained using Java tools - if you ever have the misfortune of having to deal with multiple Java development frameworks in large organizations or just get lumbered with trying to make something like Sun’s all Java identity management work you’ll soon learn exactly what I mean: this stuff isn’t Unix like at all - it’s windows like: byzantine, often disfunctional, defined by exceptions, and ultimately dependent, not on your ability to learn, but on your willingness to memorize.
