Now that Oracle and Google are engaging in open warfare over Java patents surrounding Android, it’s reasonable to wonder whether litigation is the future of Java. But don’t worry. Oracle isn’t SCO. You don’t need to hide your Java code in a bomb shelter, or even disguise your developers using Groucho Marx masks. In fact, when it comes to enterprise development teams writing and deploying Java SE, Java ME or even Java EE applications, the lawsuit changes absolutely nothing. Keep on coding, keep on deploying, nothing to worry about.

The story may be different, however, if your business is to sell platforms that embed a Java runtime that’s not officially licensed by Oracle. Exhibit A, of course, is that Google’s Android platform uses the Dalvik virtual machine, which Oracle claims violates its patents.

If you make your money selling Java, perhaps it’s time to search for alternate sources of income. Certainly, Oracle hasn’t lined up targets other than Google yet, but if it wins the Android suit, that could spur further disputes.

It is a shame, however, that all of the attention being paid to the Oracle v. Google lawsuit isn’t also being directed toward the OpenJDK. That project is genuinely solving some of the traditional problems of the Java environment, and it’s currently one of the most happening areas in the field.

While JBoss, Spring and Tomcat continue to push forward the state of enterprise Java, the OpenJDK has gathered a real head of steam and interest thanks to tireless contributions from both inside and outside of Oracle.

Despite its vibrant community, the scope of the project means that the OpenJDK is likely two years from completion. Unfortunately, many of the Java luminaries we’ve spoken to cite the OpenJDK as the insurance policy that will keep users safe from patent litigation. Does that mean Java vendors will have to wait another two years before they can feel truly safe? It does look that way.

Apple blinked
The industry—and the pundits—screamed bloody murder when Apple revised its developer license agreements to block the use of third-party tools, such as code generators, to create applications for the iPhone, iPod touch and iPad. We were among those complaining about Apple’s seemingly gratuitous restrictions on its developers. We are pleased, therefore, that Apple has backed down and has formally revised its license terms to be more accommodating to cross-platform development.

In June, Apple changed section 3.2.2 of its developer agreement in a way widely perceived as blocking Adobe’s Flash platform—but which caught up other third-party tools as well. The terms read:

“Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).”

In early September, Apple changed 3.2.2 to say, “An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded.”

We believe that Apple’s terms, which permit generated code, are now reasonable. But why did the notoriously secretive company change its mind? It may be because Android is coming on strong, and Android developers lack any such restrictions. Or it may be because Adobe asked the U.S. Federal Trade Commission to investigate Apple’s draconian license agreements. Either way, it’s good news.

We are also pleased that Apple has pledged to release the internal guidelines that it uses to evaluate iOS applications. This will help all developers, both corporate and independent, understand exactly what they can and cannot do.

With luck, Apple has learned an important lesson: Developers don’t want to be told how to write their software. Code generators are an important part of the mobile landscape. We’re glad to see Apple loosen those restrictions.