Java 6 will be retired from security support in less than two months, and users and businesses should prepare now for its demise, experts said today.

Oracle will publicly patch Java 6 for the last time on Feb. 19, 2013. After that date, only enterprises with contract support plans will receive security updates, according to the Java support roadmap.

That means consumers and most businesses should upgrade to Java 7 as soon as possible, said security professionals Wednesday.

"If you're not able to upgrade [to Java 7], you'd better have some pretty deep in-depth defenses in place," warned Jason Miller, manager of research and development at VMware.

Miller has a point: In 2012, Java vulnerabilities were widely targeted by exploit writers and hackers. Last March, for example, approximately 2 percent of all Macs were infected with Flashback, malware that exploited a Java bug that Apple was sluggish in patching, even though Oracle had issued fixes for other platforms.

Apple continues to maintain Java 6 for OS X users but ceded responsibility for Java 7 to Oracle in 2010.

Oracle acquired Sun Microsystems in late 2010 after it offered $7.4 billion for Java's creator the year before. Oracle released Java 7 in July 2011.

Although Oracle extended Java 6's EOL, for "end-of-life," twice this year -- first from July to November 2012, then again from November 2012 to February 2013 -- Miller was certain that this time the date would stick.

"At some point, they just have to say it's retired," said Miller, comparing Oracle's situation to that of Microsoft, which has delayed Windows XP's retirement, but now seems ready to stand by an April 2014 expiration date.

While individuals may have little trouble upgrading to Java 7, enterprises face a bumpier road.

IT administrators and Java developers are the most at risk of not making the deadline, said Miller. "They really need to test their [Java] apps," said Miller, and if necessary, rebuild or modify their in-house and public apps.

The bright spot is that users and enterprises have six months to dump Java 6 before they'll miss a bug fix. After the Feb. 19 update, the next Java patches will be released June 18, 2013. "Between now and June, enterprises should be testing [Java 7] and deploying it," Miller recommended.

Java 6's support death presents special problems for Mac users. While Java 7 runs on all current editions of Windows, including the 11-year-old Windows XP, it requires OS X 10.7, aka Lion, or its successor, Mountain Lion, on Macs.

That will leave a significant portion of Mac users without the means to run an up-to-date Java next year. According to Web metrics company Net Applications, approximately 41 percent of all Macs still run versions of OS X older than Lion.

Apple will presumably issue the final OS X patches for Java 6 in February alongside Oracle's update.

But some security researchers are unconvinced that upgrading to Java 7 is a good idea.

On Tuesday, Polish researcher Adam Gowdiak, who reported scores of Java vulnerabilities to Oracle this year, told the IDG News Service, "Our research proved that Java 7 was far more insecure than its predecessor version. We are not surprised that corporations are resistant when it comes to the upgrade to Java 7."

Thomas Kristensen, chief security officer at Danish vulnerability management firm Secunia, was more optimistic about Java 7's security prowess, saying in an interview with Computerworld yesterday that it was "pretty much equal to Java 6 out of the box."

But Kristensen did criticize Java 7.

The Java 7 Update 10 released last week included several new security options that let users disable Java in all browsers, or set privileges for signed and unsigned Java apps.

Kristensen called the changes "a step in the right direction" for the attack-plagued Java, but argued that Oracle should have turned on the new features by default rather than leave them in users' hands.

"They're difficult to understand, they're more complicated than similar features in other products. You have to know how Java works, the nature of Java, you have to understand signed and unsigned [apps] and the source of those apps," Kristensen said. "A more restrictive [environment] should have been applied by default rather than depend on users actively choosing them."