With the release of the newly renamed Java 5.0 J2SE platform, it's time to speculate on just what might be coming in Java 6.0. Given the typical 18-24 month cycle for major J2SE releases, you need to think beyond the norm and not just about new specification releases that require updated versions in the platform.

Sun's Bug Database (http://bugs.sun.com/bugdatabase/) is a good source for ideas about the more normal Request for Enhancements (RFEs), what's missing from the current release or has been missing in past releases. Since Sun has a top 25 list, we won't repeat what's there. Also, obvious additions/updates such as for "new" technologies that Sun is promoting, e.g., the Sun Java Desktop System, will be left off.

Instead, let's consider how changes in the world and the Internet will lead to even more technologies being incorporated into the standard Java platform.

Hopefully, by the time Java 6.0 comes out, the patent on GIF writing will have timed out everywhere in the world and Sun can add this to the platform. Of course, why anyone would want to write GIFs any more can always be asked.

It's also about time Sun offered full support for PDF files. This is no small feat, as the printing API includes a PDF flavor, but no native printing support. This added library would need to offer support for parsing, generating, searching, previewing, printing, encrypting, and annotating. Form support would also be beneficial, though that could wait for 7.0.

Instant messaging and peer-to-peer networking are very popular these days. Expect to see APIs like Jabber (www.jabber.org) for XML streaming protocols and support of the up-and-coming Extensible Messaging and Presence Protocol (XMPP) from the Internet Engineering Task Force (IETF) available.

A new javax.blog package could serve as a hotbed for serving up personal diaries. With the help of the XMPP capabilities, support for having everyone's blogs automatically intertwined by just starting a standard blog server could be available. Group blogs would need to be supported, as well as a handful of Web services that, for example, enable Amazon associates to maximize revenue options.

Because of Josh Bloch's huge contribution to the Java platform and to maximize his new stock options over at Google, Sun should include the Google Web API service (www.google.com/apis/) in the standard SDK. With broadband everywhere by then, developers could easily add features like Google's spell-checker, translation options, or just put AdSense in every available Web application.

Viruses and spyware are rather popular these days. With Sun's renewed interest in the desktop, look for new API hooks into the anti-virus software on the client. Expect the option to automatically check for viruses on standard socket connections. To help virus writers, Sun could add a new virus writer/spyware toolkit to the platform. This would include features for polymorphic virus generation and keyboard capture. Also, look for an API that provides the ability to add users to and remove users from the operating system and to "su" over to another user to execute a command under the guise of that user.

With Sun and Microsoft settling their legal differences, and Microsoft no longer updating Internet Explorer's pseudo virtual machine for Java, Sun could include a pluggable Internet Explorer as a full-fledged browser in the JEditorPane/HTMLEditorKit, reversing the plugin debate.

For the low-carb developers out there, Sun should delete every deprecated field and method. This would lighten up the APIs considerably in some areas and remove many methods that just redirect calls to different methods. Of course, this would mean that methods like System.getenv(String) couldn't have been undeprecated in 5.0. But then, getEnv() might have been a better name had Sun not had to keep to the original name when the method got undeprecated.

For the high-carb developers there, Sun should finally add operator overloading. Just look at how Groovy does this at http://groovy.codehaus.org/operators.html. Define a method like plus() in your object and you can do a + b. Define a next() method and use auto increment operators (++). What's wrong with mapping method calls to operators? You should also be able to define new operators like ^^ for power (since ^ is bitwise-or), like 2^^3 for 8.

With all these things missing from Java for so long, you wonder how it has even made it to version 5.0, let alone to the second release, 1.1. We'll just have to wait and see what Sun decides to add.