The Double-Edged Sword
Code-base and Deployment Maintainability:
Code-base and deployment maintenance in Java is a double-edged sword: There are significant advantagesand significant weaknesses. The dominance of the Java language on the J2SE and J2EE platforms is perhaps these platforms' greatest strength with respect to code-base maintenance. An adept programmer can pick up the code from any other programmer and, if not understand it right away, can at least figure it out with minimum effort. (Compare that to the .NET platform's avowed multilingual capabilities: I really can't imagine a VB, a C#, and a COBOL programmer getting together to share or understand each other's code.)
|The dominance of the Java language on the J2SE and J2EE platforms is perhaps these platforms' greatest strength with respect to code-base maintenance.
There's another advantage to Java: It's not a particularly complex language. With minimal effort, you can write code that is easy for other Java programmers to followand eventually maintain. Speaking as someone who has done project maintenance in both Java and the considerably more complex C++, there's no comparison. The time it takes to grok an average piece of well-written Java code vs. C++ must be shorter by at least a factor of 2.
Where J2SE and J2EE fall quite short is in the area of version management and compatibility. There is no standard way to label a Java class with a particular version number or to indicate what versions of classes are compatible with what other versions. Similarly, other resources, such as data files, internationalization resources, etc., can't really be stamped with version information. There is a weak standard for labeling JAR files with version information, but this information is not used by any of the standard class loaders or resource APIs, so there is basically no practical support for this type of versioning.
J2EE does not have a standard, portable scheme for deployments. Often this most significant hurdle to deploying a working J2EE-based solution is making sure an administrator is in place who knows the deployment and configuration vagaries of the chosen container implementation.
Platform-independence and Portability: Java excels where it was designed to succeedplatform independence. There's no getting around the fact that successful cross-platform projects were few and far between before the Java architects released their gift. Only tightly focused problem areas could seriously be considered.
||Where issues of security, throughput, and management are secondary to platform-independence, the project will be implemented in Javaor it will fail.
For a project with cross-platform requirements, the Java platform is virtually the only contender. Where issues of security, throughput, and management are secondary to platform-independence, the project will be implemented in Javaor it will fail.
A large part of standard Java APIs are dedicated to extending platform-independence to container- and implementation-independence. Take a look at the stated goals of the specifications; you'll see that JDBC, JMS, J2EE, JNDI, and most other JXYZs state portability and implementation-independence as a goal. Despite reports of its demise, the software component marketplaceat least the Java part of itis based around these open, implementation- and container-independent standards.
Project Management: Java has been embraced by tool vendors that run the gamut from open-source, freeware tools such as GNU Emacs to powerful commercial design and developments tools (TogetherJ, JBuilder, and VisualAge, to name a few). What I love about Java is how a team of developers using wildly different tools can successfully complete a projecteven from far-flung locations. A developer with a minimum of free tools can participate in a Java project. The minimum set of tools includes the JDK, a decent editor (Emacs + Ant, for example), and a source-code management system, such as a concurrent versions system (CVS). (See "Six Years and Counting: The State of the Java Market" for more details about Java tools.)
In addition, most standard Java services have free reference implementations for Linux, Solaris, and Windows platforms. So, a J2EE project with a database component can be sufficiently replicated using the J2EE reference implementation and a database. The same code developed against this set of implementations should work without modification when run in an iPlanet or WebLogic server using any other RDBMS for which a JDBC driver exists.
The community of capable Java developers is large. Because of the component model complexities, however, a capable Java programmer is not a proficient EJB or servlet developer. In fact, it's hard to find "guru"-level EJB developers, because design patterns for EJBs and servletswhich are not truly OO component models and often are inappropriate targets for traditional "gang of four" design patternsare not firmly established.
When considering using either J2SE or J2EE as a server-side application platform, you must consider the potentially high cost of putting together a team that can implement a solution. (For more details, look for our story on the "Java Skills Gap" and the Java Pro Developers' Survey in early June in Part II of the "Judging Java" series.)