Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Thursday, August 12, 2010

Last gasp of Sun's semi-openness

Throughout its lifespan, Sun always had a schizophrenic view of open standards. Some of the things it did were very open, like giving away specs and/or implementations of things like RPC and NFS. Some of the things were traditional proprietary licensing models — akin to Microsoft or Intel — with SPARC chips, Solaris and the like.

On the other hand, Sun’s use of open source was always semi-open, as I noted in 2003 in my most oft-cited open source paper. In fact, Sonali Shah (now of U. Washington) coined the term “gated source” to refer to Sun’s use of open source-like approaches inside an extranet during the past 15 years or so.

While Sun eventually embraced open source, its opening always seemed like too little, too late. Certainly during its entire lifespan, Sun’s was at best semi-open — a combination of (as I put it in my 2003 paper) “partly open” and “opening parts”.

The crown jewels of Sun during its final decade was the Java programming language. One offhand estimate I heard was that Sun spent more than $1 billion in R&D on Java before it was gobbled up by Oracle, but that number seems low.

Now Oracle (owner of Sun’s IP if few of its former leaders) is suing Google for its independent implementation of Java in the Android platform. Since neither the IP nor the alleged infringement has changed since the first Android phone shipped two years ago, the lawsuit seems driven more by the change in management than a change in IP use.

Oracle is represented by David Boies, who once helped sue Microsoft for antitrust violations but more recently represented SCO in its suit against Linux and IBM.

The Merc sees it as a negotiating ploy:

While Redwood Shores-based Oracle did not specify the amount of damages it will seek, one analyst said the stakes could be high. But he also suggested the lawsuit may be a strategic move by Oracle in the course of a larger negotiating effort.

"At the end of the day, it could mean a fair amount of money," said Al Hilwa, a software industry expert at the IDC tech research firm. Based on other similar past disputes, he added, it's likely that the two companies have been negotiating quietly for months.

"Going public with a lawsuit may well be part of a strategy by Oracle for trying to force the issue," Hilwa said.
In contrast, ComputerWorld quotes a Gartner analyst who (correctly) suggests that Oracle will have a hard time making a case:
When Google developed Android it included a Java compatible technology called Dalvik with the phone OS. Dalvik was developed as a "clean room" version of Java, meaning Google built it from the ground up without using any Sun technology or intellectual property, said Gartner analyst Ken Dulaney.

"You can't just take a Java application from a Sun environment, where it's licensed, and run it on Android. You have to recompile it to Dalvik," Dulaney said.
The cleanroom process is almost 30 years old, used for hundreds of clones of the IBM PC, Adobe’s PostScript interpreter, and many other copryighted software technologies owned by litigious wealthy IT companies. When used properly, it is very effective — which is why Dell and HP are shipping more Wintel PCs than IBM, which dumped the business it created.

If Google used this process, Oracle faces a nearly impossible task of proving copyright infringement. If it didn’t — with all its brains and resources and lawyers and egos — then certainly it deserves to pay whatever a jury hands out in a courtroom.

In fact, Android does not have a complete Java implementation, but the Java language syntax with a different set of APIs that brought heartburn to Java programmers (and Sun).

I don’t know much about the Java patent portfolio, which is potentially a more seriously threat to Google since a cleanroom or independent invention is no defense for patent infringement.

I was curious to find no record of Sun asserting Java patents against other firms, at least openly. The only Java patent litigation I could find was a $92 million settlement in 2004 by Sun in favor of Kodak for Java infringing patents created by Wang Laboratories (and bought by Sun)

Certainly there have been at least limited Java clones, including HP’s MicroChai in 2001, which apparently shipped in a few HP devices.

So does Sun/Oracle have a weak case? Has it been using the patents behind the scenes to win royalties or eliminate competing Java implementations?

However, the fact that Sun has patents to assert over Java implementors shows that it always intended the Java platform to be semi-open, and that its abortive effort to make Java a truly open standard was never intended to give up control.

Wednesday, April 28, 2010

Microsoft hosts Android platform

Earlier this month, Microsoft Research in Silicon Valley hosted a seminar on Android. I tweeted live from the event:

Serious irony: here at Microsoft Research (Mountain View) waiting for talk on Android, using the Internet via GoogleWiFi (free in Mtn View).
6:53 PM Apr 13th via Tweetie

At Android event http://bit.ly/dym6ff local IEEE CompSoc vice chair installed Android on his AT&T Tilt phone (originally Windows Mobile).
6:58 PM Apr 13th via Tweetie
This is not to say that Microsoft and Google can’t find occasional common ground in their fight for Total World Domination. (For example, Microsoft said Wednesday it will license patents (under royalties) to its customer HTC to defend against allegations that HTC Android phones infringe iPhone patents.)

However, in this case the seminar — “Android: A 9,000 Overview” — was organized by the Santa Clara Valley chapter of the IEEE Computer Society. It had a unique two-part format: a business overview by Mike Demler and a technical tutorial by Marko Gargenta.

Android Platform: An Ecosystem View

Demler is a semiconductor engineer (with a MSEE from SMU) who I met when he was getting his MBA at San Jose State. He summarize his own talk on a blog post that includes his slides:
This presentation provides a quick overview of the participants in the rapidly expanding Android ecosystem; from software to semiconductor companies, wireless providers, handset manufacturers and app stores, to the numerous opportunities in consumer electronics beyond smartphones.
He was seriously limited for time, but Mike provided a very clear overview of the ecosystem, complete with information about recent trends (part of a his planned update to his $200 report on Android trends.)

To readers of this blog, some of his basic points were familiar: Android has won support by all four US carriers, the rate of new devices is increasing, and it’s going to have an impact beyond cellphones. Because (unlike the iPhone), all four carriers are carrying multiple Android devices, Mike is among those who are very optimistic about its future US/global market share.

Two tidbits were specifically interesting to me:
  • Cellphone manufacturers and carriers are mobilizing their developer support organizations to back Android, through programs like MotoDev and third party tools like DeviceAnywhere.
  • In products beyond mobile (to use Bill Weinberg’s phrase), Android licensees are pushing the platform in an area that’s not a priority for Google. Examples include not only the Nook (and an e-reader rival named Alex), and various notebook-type computers from HP and Acer, but also settop boxes on at least two continents.
Android Platform: Technical Overview

From both his talk and website, Marko Gargenta clearly spends a lot of his life helping programmers understand the Android platform. He posted his slides to his LinkedIn profile which points to SlideShare, but similar earlier talks (particularly “Android Internals”) can be found as PDFs via Google.

Marko’s tutorial looked fun to this former programmer, including the Eclipse tools that make it (relatively) easy to target multiple platforms: Android 1.1, 1.5, 1.6, 2.0, 2.1. It was also fun to see that Android adopt a 25+ year old Apple concept of resources, both to hold program data and also to support a non-procedural definition of user interfaces and other program structure.

Marko identified two aspects of the technical architecture that provided insight into Google’s business strategy.

First, Java fanatics were excited to hear that the programming APIs are in Java, but Sun was disappointed that Android doesn’t use its standard Swing or other J2ME (Java ME) libraries, but instead has its own unique user interface APIs. The equation Marko put on the board was:
Android Java = Java SE – AWT/Swing + Android API
and he got a few laughs for his Trumanesque newspaper headline.

On a related note, Google didn’t want to pay royalties (in its free OSS distribution) for Sun’s Java Virtual Machine, so Java code is translated from Java bytecode into .dex files to run on Google’s own Dalvik Virtual Machine.

Secondly, the message-based Android APIs allow a third-party application to handle any function that an Android-supplied one can: browser, email, calendar, mapping, etc. Like Windows (or the iPhone), the Google code cannot be deleted from an Android device, but unlike the iPhone (or other platforms) the third-party software can supplant the built-in application, fully integrated into the phone operations and the user experience.

Finally, from a technical standpoint, Google is allowing native development of C/C++ source code using its NDK. Unlike Java, this code is no longer processor independent (thus requiring bundling separate code for ARM-licensed and Intel processors), but it does allow high performance for things like image or audio processing algorithms.

The availability of such information — and the overflow crowd of programmers eagerly seeking it — shows one of the strengths of Silicon Valley. With nearly 40,000 Android apps available, we in the audience were not exactly the leading edge, but there is a huge pent-up interest in Android here that seems to be approaching that of the iPhone.

The interesting question is: how much longer can new entrants into either ecosystem make money? I think it will play out like the PC, Mac and other software platforms. In a year or two (if not today), the the only ISVs making money on either platform will be either the pioneers (who shipped one of the first 10,000 apps) or the big boys (EA, eBay, Amazon).

Thursday, December 11, 2008

Flash is still not alive on the iPhone

InfoWorld updates a long-running story with today’s post: “No Java, Flash for iPhone this Christmas.”

There is still a little time left, but it doesn't look like Apple iPhone users will see Adobe Systems and Sun Microsystems get Flash and Java up and running on Apple's handheld device by Christmas.

Although both Sun and Adobe have expressed a desire to back the iPhone for nearly a year, neither the Flash Player nor Java Virtual Machine run on the device. And it appears that little to no progress is being made. Sun and Adobe, the chief proponents of the Java and Flash platforms, respectively, repeat what they've said all year: that they are still working to get their software platforms running on the trendy phone.
Paul Krill chalks this up to technical difficulties, rather than a conspiracy by Apple to block competing platforms. (OTOH, Apple wasn’t willing to comment).

So various rumors (in Fall, Spring, Winter) that iPhone Flash was due Real Soon Now appear to have been premature, as were rumors of Java implementations.

It doesn’t make sense to introduce something like this in December anyway. Perhaps this is something Steve will announce at his keynote on Jan. 6.

NB: Although it would make for a better metaphor, it didn’t seem fair to say “iPhone Java is still dead” since it’s never been alive yet.

Monday, September 1, 2008

Evaluating Ajax alternatives

Ajax has been a central part of Google’s efforts to design richer, client-independent Internet applications. I think by any measure it’s been a success, in part fueled by (and fueling) the success of WebKit, the open source HTML rendering engine developed by Apple engineers.

In the August issue of IEEE Computer, George Lawton authored a 3-page summary of “New Way to Build Rich Internet Applications.”

The article lists two major Ajax development tools: the Google Web Toolkit and Microsoft ASP.Net Ajax. It also lists the non-Ajax alternatives: Adobe solutions (Flash, AIR and Flex), Microsoft Silverlight and Sun’s JavaFX.

I haven’t been a code-level engineer since Palomar closed in 2004, and I haven’t had occasion to create any Internet apps other than many pages of HTML and a few small fragments of Perl and Javascript. However, I found the article provided a helpful overview of the competing RIA technologies, with no obvious axes to grind.

The one odd thing was only a single passing reference to Eclipse. Its Rich Ajax Platform version 1.0 was released 11 months ago. It leverages the existing Eclipse Rich Client Platform architecture that is the basis of many Eclipse applications from the past five years.

Saturday, March 8, 2008

The dog that didn't bark

As Sherlock Holmes noted back in 1892, sometimes it’s just as interesting when a dog doesn’t bark as when it does.

Last month I asked whether this week’s iPhone SDK would bring Flash support. It didn’t, and in almost all the coverage of the SDK intro nothing was said about this major gap (for Apple? for Adobe?) in platform compatibility.

Despite what Adobe boosters claim, Steve Jobs still feels that Adobe needs Apple more than Apple needs Adobe. Various accounts quoted him as telling shareholders Tuesday that PC-based Flash is too slow and Flash Lite is not capable enough to support today’s web. It’s not clear if Steve is being sincere, or merely sending a message diss’ing (or even promising?) Flash support. Adobe this week was noncommittal.

Interestingly, Sun took a quick look at the iPhone SDK and then promised to bring Java to the iPhone. That’s what I expected Adobe to do, so maybe Steve is right: the current Flash is suitable for the current iPhone hardware.

Sunday, May 13, 2007

What is Sun thinking?

Last week was Sun’s annual JavaOne and thus its major announcements. This year, the big news was the new “JavaFX” brand, and the two products — “JavaFX Mobile” and “JavaFX Script.” Maybe I’m dense, or rushed, but I don’t get the logic of either one — the branding, the need for the technology, or how it fits with existing ecosystems.

JavaFX Script

Let’s start with JavaFX Script. Technically, it’s a statically-typed language with declarative features intended to tie together Java (particularly Swing) GUI code. Its emphasis on “rich” applications overlaps (if not compete with) the JavaScript-based Ajax, Adobe’s Flash and Microsoft’s new Silverlight.

Declarative languages are the best way to specify user interface/code interactions, as Mac GUI authors have known for more than 20 years. However, despite Sun’s claim to a technical need for yet another scripting language, the aims of JavaFX Script (or whatever they end up calling it) seem more about keeping Java programmers writing in Java, and developing for a Sun-controlled architecture.
Meanwhile, the latest language option raises questions about last fall’s decision to hire the “JRuby Guys” and efforts to drive Ruby development to the Java-native interpreter.

The open source and branding strategy are similarly confusing:
What Is Project OpenJFX
Project OpenJFX is a project of the OpenJFX community for sharing early versions of the JavaFX Script language and for collaborating on its development. In the future, the JavaFX Script code will be open sourced. The governance, licensing, and community models will be worked out as the project evolves.

What Is JavaFX
JavaFX is a new family of Sun products based on Java technology and targeted at the high impact, rich content market. …

Why is the JavaFX Script name so long?
Although the official name of the scripting language is JavaFX Script, we expect many programmers to just call it JavaFX as it is the core of the JavaFX family.
Everybody got that? JavaFX Script is going to be open source someday, you should just call it “JavaFX”, and this “JavaFX” has the same name as Sun’s new family of products (of which these are but the first two). If this is the long-term strategy, it’s hard to see that JavaFX Script ever becomes independent (like Eclipse) rather than captive or even dual license (like MySQL).

JavaFX Mobile

The other half of the JavaOne announcement was JavaFX Mobile.
This is based on the work of SaveJe, a spinoff of Lucent that won $71m in VC funding, and strategic support from European carriers Orange and Vodafone. Although people like the SavaJe technology — adding mobile phone features into the Java virtual machine — it ran out of money last fall and then all its IP was acquired for a song by Sun last month.

Again, Sun seems to be trying to compete head-on with Adobe (née Macromedia née FutureWave) Flash, which has successfully turned middleware into an API platform that pre-empts operating systems.

Various accounts say that JavaFX is targeted at low-end phones or "multimedia phones". (If they are the same then all phones are multimedia phones). So Sun has another six months to figure out a strategy before it ships first product. Meanwhile, it hopes to commoditize phone operating systems, pleasing carriers like Orange and Vodafone while pissing off major mobile phone customers like Nokia, Samsung and Motorola.

What does it all mean?

That Adobe, Microsoft and various second tier vendors (like Sun) want to own rich Internet content is not all that surprising. But what is interesting all these vendors are vying to offer complete solutions for mobile phones, which already has Symbian, Palm, emerging Linux solutions as well as the phone makers’ in-house solutions.

Two things seem like larger lessons:
  1. Unlike with the original Acrobat, or Flash, none of the competitors are willing to let a new platform win by default. (Even MS-DOS had competition briefly from CP-M/86 and of course recently from Linux).
  2. So far, all of these options (except Linux) seem to be proprietary software stacks with only an occasional bone of openness (such as the JavaFX and Silverlight open source promises). Either the vendors are right, and buyers (whether end users or hardware makers) don’t care about openness, or there’s an opportunity for someone to compete using openness as a weapon.

Technorati Tags: ,