Java is a robust, full-featured environment, but I am not sure it is the framework for me.
At one point in 2002, when I was caught up in the idea that I had to make a choice between .NET and Java as the next platform to array my programming skills around, I might have been inclined to choose Java over .NET. A lot of negative sentiment about .NET was whipped up by conspiracy theorists who were concerned with what .NET was really about. A lot of these people were from the open source software camp, and were convinced that .NET was yet another attempt by Microsoft to take over the Internet and to drive Linux and any other operating system alternative out of existence, so that Microsoft could have a monopoly on computing. These fears have largely turned out to be unfounded, as Windows and .NET did not take over the world. .NET's adoption has been stalled by the unwillingness of a lot of enterprises to install the .NET framework on their machines. Microsoft has bundled .NET into Service Pack 2 for Windows XP, which a lot of enterprises also haven't installed, fearful that it would break existing applications. So much for the momentum of the Microsoft "conspiracy".
Java thus did get my attention for a while, but I think I was cool to the idea later because of several things: the idea that one had to buy into Java as a complete system to use it on client and server, the attractiveness of open source software as an alternative to Windows, and the desire to really test the tools that I knew best-- VB and SQL Server. Now, I am willing to give Java another look: the truth is that Java can be used in a variety of situations alone or as an integrated system; open source hasn't been able to accomplish the level of integration in terms of systems that will interoperate aside from the web space; and VB/Win32 leave a lot to be desired in terms of what they can deliver for the characteristics I desire in a development framework.
So here's a quick look at Java and how it stacks up in meeting my aforementioned criteria for a development framework-- Highly customizable user interface, open API's, performance, garbage collection, Flexibility, support/extensibility, and marketability.
High Customization of UI. Java delivers with very sophisticated user interfaces. This blog entry, and virtually all the other work I do with HTML, is done on the jEdit text editor, which is written in Java. Quite simply, it is the best text editor I know of. It is written with the needs of programmers in mind, and I have used it for a variety of programming languages, including ASP, SQL, Python, VBScript, JavaScript, and HTML. Beginning with version 4.2, jEdit has a color highlight mode for all those languages. But, ironically, I haven't used it for work with Java. The biggest reason I use jEdit instead of other text editors is its ability to handle multiple documents. I probably have had as many as 40 or 50 documents loaded into the buffer at one time! You can also split the client area in the window and load different documents in each frame, or the same document in each frame and view different parts. Needless to say, this has made much of my development work a lot easier. Plugins from the jEdit community are available as well, such as the JTidy plugin that works just like HTML Tidy, completing tags whenever you type a left brace and slash. jEdit is a showcase for what Java Swing is capable of. Some people may not like the UI, but Swing is quite capable, and it does not have the "look and feel" of Windows. The days of Java applets may be behind us, but Java can certainly deliver powerful desktop GUIs.
Open API's. Java is still very much the domain of Sun Microsystems. Although the entire Java framework is open and well documented, the Java Virtual Machine itself is still proprietary code. This proprietary nature of Java has attracted several companies who have created application servers based on the Java 2 Enterprise Edition standard promulgated by Sun. In a lot of ways, this has ended up being a liability, as their implementations of J2EE are different. There has been discussion by Sun with the open source software community about making the JVM open source, but nothing definite has been announced.
Performance. It used to be that Java was a lot slower than native-code apps on Win32, but recent versions of the Java runtime seem to indicate that the gap is closing. I suspect that Java will always be at a disadvantage to Microsoft's language tools on Windows, but after all, they do own the OS too. However, recent comparative benchmarks seem to demonstrate that the latest versions of the JVM perform as fast or faster than .NET; both still lag behind native C++ or C in terms of speed.
Garbage Collection. Like with Python, it is built in, and you don't really have to write to the finalize() method or worry about managing memory. However, it is considered good programming practice to release external objects you have instantiated to free up resources more quickly than the VM does on its own.
Flexibility for High or Low End Tasks. Coding style in Java is strictly object oriented-- everything is done within classes. A lot of things you might do as a system call may have an equivalent in the Java framework, such as file handling and thread management. So there is some potential to do some "lower-level" coding, but it is always within the context of the Java framework. What Java really excels at is high-level tasks such as XML messaging, remoting capabilites, directory and web services. Java Server Pages give developers a way to write custom tags and enhance the functionality of web pages.
Support/Extensibility. Java is well-supported by some of the biggest names in the software business-- IBM, Oracle, Sun, BEA. All of them produce application servers for the J2EE, although as I mentioned before, their implementations are different, so code written for one server may not migrate to another easily. For Java applications, plugins and JAR's (Java archives) are well-established methods of extending the capabilities of Java apps.
Marketability. Although Java and J2EE are mature platforms, Java is still hurt by the fragmentation of the Java application server market, and the financial and technological commitment required to implement J2EE in an enterprise. The perception is that Java is very much a definitive choice for large companies but prohibitively expensive for small or medium-sized enterprises. Java developers and consultants still seem to be doing well as the platform makes sense for some enterprises.
James Gosling, the creator of Java, says that Java is more secure than the .NET platform because Java is secure throughout, whereas .NET allows for "unmanaged code" that creates the opportunity for programs that cause memory exceptions:
They have a notion of managed code and unmanaged code. Managed code is the kind you can make security and reliability statements about. (But with unmanaged code), you can't depend on anything anymore. Memory corruption is indistinguishable from correct behavior. It's pretty difficult to analyze what a program is doing. C programs (a type of unmanaged code) tend to fail in mysterious ways. It ends up having deep implications about how security mechanisms work. In C, you have to be able to lie about the identity of things, and in Java, you're absolutely forbidden from lying about the identity of things.
About how the role of Java has evolved over the years:
The big difference in the last five years vs. the first five years is that Java has become a central part of many gigantic, mission-critical systems. That requires a paranoid conservatism. When you've got large banks clearing hundreds of billions of financial transaction every night, small bugs have big consequences. Early on, we could do all kinds of crazy stuff, but now we have to worry hard about who we actually affect. Every bug we fix causes problems for somebody who had done a weird workaround. It becomes a very meticulous discipline.
Talking about scripting languages and the Groovy project, which allows scripting languages like Python and Perl to target the JVM:
When people talk about scripting languages, they often talk about things that are more toward having a developer be able to slap something together [really] quickly and get a demo out the door in minutes. How fast the thing runs or how well the thing scales or how large a system you can build tend to be secondary considerations. In the design of java, we didn't care so much about how quickly you could get the demo out the door, we cared about how quickly we could get a large, scalable system out the door. We ended up making difficult decisions. In general, scripting languages are a lot easier to design than the real programming languages...(All of Gosling's quotes are taken from an interview with ZDNET, June 29, 2005.)
The Java design is at two levels: the Java virtual machine and the Java language. All the hard stuff is at the JVM and below. If you can build a scripting language that targets the JVM, you get a certain amount of both properties...All the Java libraries are available to things written in Groovy. And Java applications can use Groovy. They can incorporate Groovy scriptlets.
I think in the last quote, Gosling summarizes the sentiment that some language tools are fine for rapid prototyping but not necessarily for production applications. This would seem to concur with Mark Lutz's view of Python, that it is a great tool for rapid prototyping of an application, which allows the gradual migration to components written in "real" programming languages, as Gosling calls them. Whether the scripting language is appropriate for a whole system is another matter. I am reaching the conclusion that they are not, just as VB 6 is not the appropriate tool for all the components of a system. A project like Groovy is nonetheless in the interest of Sun and the wider Java community, because it allows Java developers to create prototypes of Java components without having to actually compile the components into bytecode. In a lot of cases, it can help speed up the design process of Java applications.
In spite of the advantages of Java in terms of the maturity of the platform and the enforcement of security, I am still not certain that Java is the platform I should choose. The lack of true openness in the Java APIs and the essential "fork" of Java that we see at the application server level, are considerable obstacles to adoption by all but the largest companies. I would prefer a platform that is more accessible to a wider range of organizations, preferably small- or medium-sized companies.
Comments