It's odd that a language touted around the video games console market for a year should be the thing to change the face of the computing industry.
Nevertheless, Java has been lauded as the holy grail of computing - the portable elixir to solve software developers' woes. Vendor activity in the Java market has been unprecendented, as vendors have been fighting to bring out Java products.
The computer industry is noted for its fickle ways, and concepts such as Java are "media viruses" - once a core critical mass of people get hold of a suitable idea, it spreads like the plague, gathering up investment capital and mindshare as it goes. Speak to Sun and executives there will crow as they explain that there are more than 700,000 Java developers worldwide. As with many enthusiastic vendor claims, however, this figure needs to be taken with a large pinch of salt. The number of developers that are doing anything serious with the language rather than just fooling about with it is anyone's guess, and there are certainly some obstacles that Sun has to overcome before some developers will touch it.
In spite of that, the first quarter of 1998 has been a turning point for Java. It represents the kick-off point for the environment's assault on the enterprise. While Microsoft executives criticised the language a year ago for doing little more than providing ticker-tapes and animated dancing elephants in desktop browsers, things are changing. The ratification of the Enterprise Java Beans standard at Sun's JavaOne conference in California at the end of March means that the company will now be pushing developers to develop commercial, server-based Java applications more than ever before.
The Enterprise Java Beans specification is designed to make server-based Java applications development easier by creating a set of services that are required by most enterprise applications, such as the monitoring of transactions between application components to regulate performance bottlenecks.
The other advantage of it is that it brings the Java Beans component model into the enterprise space. A key difference between a Java Bean component and a standard applet is that Java Beans are structured to correlate directly with business processes. Thus, whereas an applet may mean nothing to a business manager, a Java Bean would provide a function, such as payroll or transaction balancing, that would benefit the business manager directly.
By marrying business functionality with component-based development, the concept of reusing components in software development, finally begins to come into focus. Reuse has been a holy grail in the computing industry for years, but in spite of the hype few developers have managed to make it commercially viable.
One of the biggest drawbacks for Java to date has been the performance issue. Because Java code is interpreted by a Java Virtual Machine (JVM) or, at its best, run using a Just In Time (JIT) compiler, its performance has lagged that of compiled C++ programs. That has been the price to pay for its Write Once, Run Anywhere functionality.
Peter Shearan, VP of technical services at Sun VAR and independent software vendor Micromuse, has always been loyal to Sun, but said that even he can't justify developing time-critical systems in Java because of the performance issue. "Our Reporter product, which does Oracle service reporting, was developed completely in Java for NT and Sun systems and then we loaded it onto an HP machine running a JVM that it had never run on before. We did it on AIX too, so we have seen some benefits of not having to cross-compile," he explained. "At present, the speed of the JVM is the concern.
Our other products focus on higher performance and that was a big differentiator between us and the competition. In trials, compiled C outperforms Java by a factor of three. If you're in a telecommunications environment and you're handling millions of events a day, then performance is key."
Nevertheless, Sun is aware of the problem and is working on its HotSpot JVM, which the vendor's Java market development manager, Rob Banforth, says will solve the problem. He says that JITs often work better compiling large chunks of code rather than small sections of software, and says that this can discourage developers from building properly-structured object systems, which adopt the latter structure. HotSpot will put an end to that, he promises. The product will ship in the autumn as a standard part of the Java Development Kit (JDK).
Andy Longshaw, Java technology champion at independent training firm QA Training, said that many developers of server-based applications are now warming to Java because of these reassurances. He added that the next version of Java server - an IP server underlying many Java applications - will include thread pooling and connection pooling as key features, obviating the need for the server to start up individual threads to service server calls on an ad hoc basis. This feature will allow developers to speed up their applications, he said.
Another possible way to solve any performance problems is to simply compile Java applications natively on the server. Dynamic run-time relocation of Java Beans across heterogeneous platforms isn't likely to be at the top of many customer checklists, and even if a company does change its server platform, one recompilation won't hurt. However, if this is the case, then it's worth asking why anyone would bother rewriting applications in Java in the first place, if their current applications are serving them well. The Write Once, Run Anywhere capability of the language is its main selling point, after all.
The transaction servicing abilities within Enterprise Java Beans will also carry customer favour for Sun, said Longshaw, who said that it will help to push Java into the space currently inhabited by the Object Management Group's Common Object Request Broker Architecture (CORBA) standard for object brokers. Applications that require a lot of traffic in the form of asynchronous messaging or transactions (such as multiple database engines), will need protocols at this level to handle the enterprise-level server-based communications.
One company that is especially interested in backing Java at this level is Oracle, which has previewed version 8.1 of its database, due for shipment by the end of this year. The new version includes a JVM that will sit in the database engine itself, enabling developers to write stored procedures in Java rather than Oracle's own PL/SQL language. The company will also make the system compatible with Enterprise Java Beans, according to Kieran Kilmartin, development tools marketing manager for the company.
Another more political problem for Sun is its refusal to hand over ownership of the standard to an independent third party or committee. Although the company has submitted the Java specification to the International Standards Organisation (ISO), if it gets approved Sun will still own the source code to the language, meaning that it will still technically be a proprietary environment. This has clearly riled Microsoft, which at the end of March was ordered to take its logo off of Internet Explorer 4.0 because it had changed some of the source code in its Java Virtual Machine to introduce some Windows-specific features.
Mike Pryke-Smith, Internet and development tools product manager at Microsoft, has also moved to defend Microsoft's introduction of J 6.0, its latest implementation of the Java language which has introduced new keywords and an incompatible set of classes, called the Windows Foundation Classes.
These conflict with Sun's own Java Foundation Classes, thereby departing from the 100% Pure Java standard.
Meanwhile, Java still has to compete with Microsoft's DCOM standard at the enterprise level. DCOM is Microsoft's own component model, and one of its advantages is that it is well-established on the server. Its main disadvantage is its single-platform status. Although Microsoft partner, Software AG, has moved to port the architecture to other platforms including Unix and MVS, it will be some time before customers summon up the courage to use it for mission-critical systems on anything other than NT.
To add to the confusion, Hewlett-Packard has announced its own JVM which introduces new functionality designed specifically for embedded devices such as process controllers. Jolanta Pilecka, electronic commerce marketing manager at HP, is unrepentant at the move, even though it represents the second official deviation from the 100% Java standard. "There is a difference between Sun and HP. Sun's experience is not as vast as ours. We have been in this market for 50 years. We know how to embed the devices and we know what our consumers expect," she said. "Our intention is to license the technology to other manufacturers." The company has wasted little time, either - its first licensee is Microsoft, who will use the technology in its Windows CE PDA version of Windows (which some industry wags have taken to calling "Wince").
Pielcka's protestations that HP has simply provided functionality that Sun did not have are unconvincing in the light of Sun's announcement of its own EmbeddedJava platform - and a port of the PersonalJava platform for Windows CE - at the JavaOne conference.
While both Sun and HP are doing their best to smooth over this deviation from Sun's 100% Pure Java standard, Microsoft is happy to defy the Java standard, which has led to open war between the two vendors. Whatever happens, it seems clear that Java is well on the way to becoming a fragmented technology, which is bound to cause doubts in the customer base.
These doubts have already caused Bob Kelly, head of development at Microsoft ISV Imasys, to put Java development on hold. He complains that difficulties in getting tried-and-tested Java applets to do what he wants to do have lengthened development times. He is therefore concentrating on developing his NT-based imaging software using Visual Basic. "While many people are taking the time to learn Java, it's a question of whether we can go to a customer and sell it," he said, pointing out that he needs to justify development costs to customers. "If we take a wrong technology strategy to a customer, we won't get the order. There has to be a commercial acceptance by IS directors in all organisations before it can even be sold and if it isn't sold then we won't develop it."
Such doubts threaten to prevent Sun from making headway into the Java-based server market. While many vendors are champing at the bit to support Java, (even the AS/400 now has a built-in JVM, for example), it will take time for them to bring out products that comply with the Enterprise Java Beans standard. While it's waiting, all that Sun has to do in the meantime is hold its 100% Pure Java standard together for long enough to persuade customers that the environment is stable enough to develop for. It must also spend lots of marketing money to counter pre-conceived notions of performance limitations.
Server applications are where the real money is, and if Sun fumbles this one, then the Java game will be well and truly over.
THE TECHNICAL COMPONENTS OF JAVA IN THE ENTERPRISE
Tom Murphy, product manager a development tools vendor Objectshare, (formerly ParcPlace), says that one of the things Sun will have to resolve to make Java a success on the server is its interaction with the Object Management Group's (OMG's) standard for inter-object communication, called the Common Object Request Broker Architecture (CORBA). With the OMG coming up for its tenth anniversary next year, this well-established standard cannot be ignored. The companies signed an agreement last autumn to integrate CORBA's Internet Inter-ORB protocol (IIOP), with Java's Remote Method Invocation protocol, which enables Java applets to communicate across distributed architectures.
"The biggest problem from the CORBA perspective is why Sun developed RMI in the first place as a separate protocol from CORBA? The company plans on using the same IIOP transport layer but that hasn't been done yet," he says.
These concerns will hopefully be resolved by the Enterprise Platform for Java initiative. This initiative is an umbrella term for a set of APIs, some of which are already shipping and some which will be rolled out this year.
- Enterprise JavaBeans is an enterprise extension to the existing JavaBeans technology.
- Java Database Connectivity (JDBC) is a protocol for hooking Java applets into database engines.
- Remote Method Invocation (RMI) enables Java applets to call each other across distributed systems.
- Java IDL enables Java software to talk to CORBA-compliant objects using the Interface Definition Language (IDL). It will also include its own Java ORB and will support IIOP.
- Java Transaction Services (JTS) will leverage the Object Transaction Services (OTS) within CORBA.
- The Java Naming Directory Interface (JNDI) enables Java applets to talk to applications utilising directory services such as Novell's Netware Directory Services. This will ship in the third quarter.
- JMAPI is designed to enable developers to deliver a standard view of network resources for network management.
- The Java Messaging Services will let developers create communications facilities that can be used for push technology and queuing systems.
Connexin drops out of Ofcom auction due to start next week
SwiftKey users now send two billion emoji every week
Recruitment plans are 'most ambitious ever', claims Openreach HR director Kevin Brady
Samsung's under-the-hood improvements separate the S9 from the pack when it comes to the display