Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Why we care about Java

Forces are at work to divide Java. The original and true purpose of the technology will carry Java through the current maelstrom of confusion and clutter

By Terence Parr, JavaWorld.com, 11/01/97

Page 2 of 4

One final element can cause portability problems: bugs and inconsistencies that exist in the various Java implementations. As with any complex piece of software, the number of problems will asymptotically approach zero over time. JavaSoft and its partners have created The Java Porting and Tuning Center to increase platform consistency and decrease the time lag between release of the JDK and its implementation by the various vendors.

But Windows can be my whole World, right?

Why should you care about portability instead of focusing on the huge Windows market, 80 percent of the world's computers? This question is like asking in the early 1980s, "Why should I use a PC when I have a mainframe?" Like the early PC, Java supports a new computing paradigm with advantages over previous systems. Most importantly, if you base your product on Windows technology, you will be programming to a moving target, as Microsoft is jostled around by the Net like everybody else (I cite the disappearance of ActiveX as a prime example). The Internet has forced most companies to rethink their strategies. Even Microsoft performed an impressive about-face when it realized the Internet's dominance. Microsoft would not have licensed Java (a threat to their business) had the Internet not forced them to. The Net ignored VBScript/BlackBird and if Microsoft wanted to be in the game, they had to go where the developers were. Ignore the Net at your peril.

What about performance?

Even if you pay attention to the Net and 100 percent portability, isn't Java a lot slower than C++? The simple answer is no; neither language has a significant inherent speed advantage over the other. Java is slower at the moment because it is interpreted, partially interpreted, or less well compiled than C++. Doing a priori (static) compilation on Java programs will yield execution times similar to that of C++ programs, but it kills portability and security. A just-in-time (JIT) compiler, on the other hand, preserves Java's portability and security by compiling a program right before it is executed (dynamic compilation). Unfortunately, a JIT has the constraint that compilation time plus reduced program execution time must be less than simply interpreting the program; JITs do not make sense for programs that run for only a very short time.

For long-running programs, dynamic compilation has serious advantages over static compilation. Static compilation can optimize for only a single CPU (usually the lowest common denominator, such as the Intel 386). Dynamic compilation, in contrast, can generate code tailored to each particular run of a program. More specifically, variables at static compilation time are effectively constants at dynamic compilation time. Consider the following piece of object-oriented code where an instance method is referenced for some variable of type Object.

int h = obj.hashCode();

Looking at the program statically, a compiler does not know what the actual type of object obj will be at run time and hence it cannot know which version of method hashCode will be called -- no method inlining is possible. In contrast, at run time, obj is of known type and a compiler can inline hashCode. For example, if obj were known to be of type Integer, the compiler would generate the equivalent of:

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.