|
INTEGRATION WATCH: Helping Java Advance
By Andrew Binstock
 April 1, 2004 — One of the perils of designing a language to execute in a runtime environment (such as the Java Virtual Machine or the .NET Framework’s Common Language Runtime) is that from the get-go, you create legacy executable code. The key word here is executable. Any extensions to the language that might require the addition of new bytecodes threaten to upset all previous executable environments.
As a result, the custodians of Java and other languages that compile to bytecodes are extremely leery of changes to the language structure. And this specific problem is one that, in my opinion, is beginning to become an important issue in the Java environment. (Because Microsoft has sold less enterprise-class software than Java vendors and because the company has been comfortable forcing platform updates on its customers, this aspect will be less problematic down the road for the CLR.)
Traditionally, language vendors have addressed this issue in a way that simply displaces the problem: Rather than fix the language, they add libraries. In certain cases, this is a workable solution, but often it simply means that programmers have to do a lot more typing to handle issues that should really be the province of parsers and compilers. In Java, this is especially apparent in the threads library and in JXTA. Let’s look at these.
If one is to believe that threads will be on nearly all desktops soon—and I think this is now a conservative projection—then threads processing should be part of the language, rather than a series of function calls.
The OpenMP standard comes close to providing this solution today in C/C++. OpenMP is a library of threading functions that are called by the compiler to thread loops and other program sections.
In C/C++, this is done through the use of pragmas, which state, for example, “thread the next for-loop using the optimal number of threads.” The actual programmer-written code in the loop is unchanged from its single-threaded version. When the program starts up, it checks for the OpenMP library. If it finds OpenMP, it allocates a pool of threads that are subsequently activated wherever these pragma-identified loops occur. The pragma keyword in C/C++ is ignored if the compiler doesn’t recognize the command that follows it.
By this mechanism, the OpenMP committee was able to add threading to applications without the developer needing to write a single library call or worry about whether OpenMP is supported on the runtime system. For programmers who revel in the low levels of thread management, OpenMP functions can be called directly, although this practice is (appropriately) discouraged. No function calls, no changes to working code, and transparent runtime support—Java should have these.
Another conservative assumption, in my opinion, is that XML processing will become a primary activity of most software. So will accessing resources across the network, and then combining network access and XML into Web services. If so, then Java syntax would benefit from reflecting these features natively in the language. It seems reasonable to assume that URLs—or, more accurately, URIs—should be a native data type. And why not native XML types—although this would be more difficult.
Work on some of these ideas is under way. For example, the JOMP project is tackling OpenMP for Java. Accessing local or networked devices the same way appeared on my radar screen in the Plan 9 operating system from AT&T Bell Labs (now part of Lucent Technologies). Its approach was to make all resources look like filesystems. And whether the resource is local or remote, it is accessed by the same functions. The compiler and the runtime environment handle any protocol or hand-shaking issues that might arise.
Native support for Web services is being proposed in other languages (which I hope will inspire similar developments in Java). Jeff Schneider of Momentum Software Inc. has been proposing a Service Oriented Language in which many of the resources needed for Web services are built directly into the language. (See schneider.blogspot.com/archives/2004_01_11_
schneider_archive.html#107409153082470089.)
Because developers currently can limp along without these features, there is no significant incentive for Sun to make changes that foist binary incompatibility upon users. Binary compatibility is a tremendous incentive to move slowly, with the result that new features always arrive late.
For these reasons, I support IBM’s stepped-up request to open the source code to Java. Presuming IBM and Sun can work out a sensible way for this project to function, having the mass of Java developers lobby for and develop new features that make the language more useful and exciting is a big advance.
Andrew Binstock is the principal analyst at Pacific Data Works LLC
|
|
Advertisement
Click here for a complete listing of Integration Watch Columns
Click here to see a complete Column Archive. |
Back to Top
|