When confronted with a haystack full of needles, especially golden needles, its nice to have some expert guidance on exactly where to look. Thats what JavaOne attendees got last week in one of the first-day keynote sessions, when one of the charts (Im sorry, but I didnt note which of the several speakers displayed it) suggested a top half-dozen emerging and forthcoming Java technologies that especially deserved attendees attention.
Proposed and final specifications for the Java platform are described by Java Specification Requests in various stages of discussion and approval. First on the list of hot topics at the conference was JSR 127, “JavaServer Faces.” This proposal addresses, as I see it, a critical gap in developer ease of use between Java and the Microsoft tools such as Visual Basic: It dramatically raises the level of abstraction for developers who want to connect a clients graphical user interface elements with the state and behavior of server-side applications.
JSR 175, “A Metadata Facility for the Java Programming Language,” doesnt exactly fill me with joy: Im a huge fan of developer tools that simply read my code, just as the processor will have to read my code (in some form or another) to run it. Borlands JBuilder is my leading exemplar of how well this can be done.
Any other form of code annotation, even comments meant strictly for human consumption, seems to me an invitation to inconsistency–not that I want to give up source-code comments, I just wish that I could believe them. But the arguments for and against such attribute mechanisms have already been made in contexts such as Microsofts Visual C++, and it looks as if attributes have won. At any rate, a language that doesnt provide them handicaps developers whove become adept at using them elsewhere, and Java doesnt need that drawback.
JSR 220, Enterprise JavaBeans 3.0, anticipates the opportunity to use Java metadata to streamline the use of this powerful but complex component model. JSR 223 tries to close another gap in developer productivity by offering a scripting interface to Java classes: Im a true believer in scripting languages such as Rexx, and Im eager to see what benefits may flow from combining the power and convenience of these technologies.
JSR 224, proposing a Java API for XML-based remote procedure calls, is harder for me to get my head around on short acquaintance. Were still talking about developer productivity, in this case the streamlined use of Web services protocols from Java code, and this JSRs supporters are the thoroughly respectable BEA Systems, Borland Software, Fujitsu, IONA Technology, Macromedia, Oracle, SAP and Sun Microsystems. With friends like these, Im prepared to believe that this effort is worth understanding.
The last of the “sexy six” JSRs (my nickname, not Suns or anyone elses) is emphatically not the least among them: JSR 185 is a very large umbrella titled “Java Technology for the Wireless Industry,” and its a major effort to produce a specification, a road map and a user guide for a comprehensive Java Wireless Architecture. This has the potential to bring a much-needed coherence to the various separate JSRs that all bear on the goal of making Java a universal execution environment for applications spanning wireless networks that incorporate many diverse device types. I cant think of any role that Java is better equipped to play.
Tell me what you saw and liked, or wish you could have found, at JavaOne.
