Strengths and weaknesses aside, it's important to consider the development areas that a language is most appropriate for. You certainly can't compose a Java app on the command line like perl, and it would be a monumental and not very worthwhile feat to write a kernel device driver in it. So what does it shine at?
The new Swing GUI toolkit is a wonderful thing, and Java's graphical event model is very straightforward. Callbacks are unnecessary (one of my early mentors, an X/Motif programmer at the time, referred to callbacks as "revenge of the goto"), and it's easy to really concentrate on your problem domain and desired look without being bogged down in details.
Like most X toolkits, and unlike most Mac/Win32 environments, Java's GUI frameworks were built with the assumption that they might have to run on all manner of strange displays, of differing resolutions and color depths. Layouts are flexible and dynamic, absolute pixel positioning is discouraged, and things color translation is done on the fly.
Swing, like the latest versions of the GTK, features runtime-swappable look-and-feel themes, so native looks as well as cross-platform and custom looks can be emulated.
And finally, the JavaBeans API allows for simple configuration, at run-time, of controls, which makes RAD tools and GUI builders much easier to build and stock with acquired or custom-built components. Or, for those like me that detest such tools, you build more complex components by configuring and extending simpler ones, and assemble flexible frameworks from which applications can be quickly assembled in code.
Java toolkits such as ObjectSpace Voyager allow near-transparent movement of Java objects from machine to machine across networks. Java agents are elegantly and simply implement; serialization and network calls require little or no extra programming for the developer. Applet/server architectures can be built with a floating dividing line between the two; allowing (at runtime) processing to be done by the client machine or the server machine based on network speed and client machine resources.
Java implements CORBA readily (it will probably become even more integral as time goes on). This of course allows it to interface with other applications and languages, including, say Gnome.
You can also interface to things like COM and ActiveX components. I've managed to avoid this so far.
With its introspection API, you can do all manner of things to anonymous objects at runtime, such as determining class, methods available, and properties, and then running methods or setting or getting properties. Infrastructure like this is essential to low coupling, which is essential to highly configurable, high-reuse architectures that can be modified at runtime, without code or compilation, to look or act differently based on configuration options. I'll show some examples of this later.
If you think about it, all servlets and applets really are is a sort of specialized extension language, just like elisp or other scripting languages. But how many scripting languages do we really need to learn in one lifetime? The main problem with using general-purpose languages for application extension is that they have no way to prevent the extension from running rampant all over the application. Java, however, was built with just such security in mind, so that it's possible to run untrusted binary code in your application without (well, too much) fear. And when that code is also capable of wandering about a network, then you get some really exciting possibilities. Imagine, for example, a MUD-style, distributed game where users can custom-code their characters in Java to achieve unique behaviors or appearance, and this code simply becomes an agent that can walk from machine to machine in a distributed virtual world. Or plug-ins for, say, the Gimp, written in Java that are updated with the freshest version from a central repository on the Internet.
As Japhar matures, we'll have an LGPLed VM that we can embed in any application.
There is still tons of big iron out there, most of it running legacy applications of some sort or another. Getting rid of those has proved very difficult, since the first stabs at it involved "client-server" technologies based on unstable operating systems with truly annoying deployment requirements. It turns out that applets, servlets, and other web-based Java technologies are much better suited to this problem, due to their centralization. One of the largest product areas in Java libraries is in database bindings, transaction processing interfaces, etc.
|
|
|
|
|