Miguel de Icaza on Java lawsuit

Miguel de Icaza on Oracle’s patent lawsuit against Google.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I just wonder

Does mr. J. Gosling make money on that one patent of his when Google decides to settle?

Hmm, that's phrased wrongly. In general, when one files a patent in a company, will -or need- they pay royalty in case they make money out of it?


In almost every employment agreement for software developers and designers, the employee assigns all patent rights, copyright, etc. to the employer. The company receives ownership (to the extent possible) of all intellectual property created by the employee on the job. (And off the job, in some cases, though this is not enforceable in all jurisdictions.)


Thanks, just trying to understand the legalese around programming languages in industry.

Inventors and Assignees

Patents list both the "inventor"(s) - the individuals behind the 'invention' - along with the "assignees" who actually hold the patent.



usually gov't entities let researchers get a % on patent stuff. It can be substantial since usually the researcher will sell the patent for shares valuated at a low price, which the gov't then liquidates a percentage of.

Another comment

By Stephen O'Grady:

Oracle is willing to absorb soft costs in risk to reputation and participation rates in the Java ecosystem. [...] this suit is going to negatively impact – probably substantially – Java adoption. The enterprise technology landscape is more fragmented by the day, as it transitions from .NET or Java othodoxy to multi-language heterogeneity. Oracle’s suit will accelerate this process as it introduces for the first time legal uncertainty around the Java platform.

There is hope yet!

There is hope yet!


Java and the JVM are entrenched by now, but if there are patent issues like that buried in the essentials of the runtime system, there is a very, very real problem. Here a simple alternative implementation strategy can't avoid the patent issues, and IMHO, NOBODY should hold themselves hostage to such a language - a frickin' computer programming language!!! - going forward.

Fact is, if Java died a quick death because of this, no one will care or hardly remember in 10 or so years. There's nothing categorically special about Java (conventional Algol/C family language adding GC) or about a VM implemented language (sorry, pretty trivial to build a fast stack based VM - hell, if I can do it...) or even about a JIT (although a few Java implementations are very clever in their implementations). JIT's are actually hard (performance quality criteria drives this kind of infrastructure, and performance doesn't have any real upper bound regarding customers and competitors), but again, neither new nor unique to the Java community.

Totally skipping arguments about the virtues of software patents, it's just prudent to pick tools with longevity and unhindered by, frankly, patent and licensing BS like this.

And FYI, I got turned onto Java early visiting out at Sun circa '96 and adopted server side Java a few months later with the alpha implementation of Sun's 'Jeeves' servlet engine. So I don't have any real beef with Java - far from it.



That's the damnable thing -- there is no guarantee that any implementation technique is unhindered by "patent and licensing BS". Would that there were. You don't know if there's a troll under the bridge until he comes out, even if you built the bridge yourself.

Re: Unhindered?

Great response, John! The situation is not specific to Java or .Net.

The good thing about this situation is that Google is the best for us candidate to defend against such assault.

From this end I just cannot

From this end I just cannot understand how Oracle could be so blatantly anti-competitive and petty. This is roughly equivalent to dumping tons of toxic waste into the pond in which all Java vendors live. Oracle may have launched this lawsuit knowing they wouldn't make much money in the end from it, but for the opportunity to grind Google to a halt. I don't think they are prepared for the second-order effects this will have.

This will undoubtedly slow down Java adoption and make vendors consider other alternatives. This lawsuit will drag on for three years at least, and in that time the rats will leave the sinking ship...

Sorry Java, this may finally be the last bit of weight that drags your horse out of the race.

This doesn't really have

This doesn't really have anything to do with Java. Fully compliant JVM implementations have explicit patent protection IIRC, so this shouldn't affect JVM adoption in the least. This "compliance clause" was used to sue Microsoft back in the day, and now Oracle is using it to attack Android now that it's attained critical mass.

What is 1.6bil worth 12 years later?

For what it is worth, Charles Nutter wrote a good summary of the lawsuit, more micro-level than Miguel's "just use Mono" plea (if Novell were serious about "just use Mono", they would fund Martin Odersky to take Scala.NET very seriously, as that would be "the new J#").

In theory, yes

>This doesn't really have anything to do with Java.

In theory, you're right, in pratice nearly everyone who belongs to the Free Software community despise Oracle now.
So this will have a significant impact on MySQL (easy: use PostreSQL instead) and Java, but there's no obvious replacement for Java..

On Dalvik Internals

The recent post sparked my interest, and I read up on Dalvik internals to see where it stands as a JVM at the moment.

CEO summary: A) A Dex file uncompressed is a few percentages better than the compressed Java class file compiled from. It achieves this by maximizing sharing in several constant pools. B) The Dalvik byte code interpreter is some factors (even when JITted) slower than most other interpreters. C) The Dalvik machine is register based versus the stack based version of Sun.

Now, the second amazes me and I wonder: Is that because of the extra levels of indirection introduced by compressing it?

[ Changed order to factor. Big whoops. ]

Orders of magnitude?

Disclaimer: I do work at Google, but _am not_ speaking for the Dalvik folks.

Dalvik is not orders of magnitude slower than any other interpreter. I'd doubt if it was more than a factor of two slower than the highly optimized, hand-written assembler versions of HotSpot's interpreter. The JIT is pretty simple but does give pretty decent speedups, but is nowhere near HotSpot performance.

As for indirection, the combined constant pools of the DEX format means there are fewer levels of indirection than with a standard JVM.

The Android platform also does some installation-time rewriting of DEX files to make them more efficient (e.g. quickening getfield bytecodes). Also, the file format is very cleverly designed so that it can simply be memory-mapped and most of the data structures and code used "in-place" in memory.

But don't take my word for it, Dalvik is open source and you can see all the details.

I've tried to get my hand on bench-marks

Since I was interested. It showed very poor performance on its 1.0 release, which is okay, of course. And I looked at Google 2010 IO speeches on the JIT, which promises 2-5x speedup.

Still, they remain conservative on promised delivery, and, hey, I am not worried. I know it must be hard to bring JIT to embedded devices. It's just that I wonder whether there is a time-space trade-off involved.

[ Ah forget it. The most plausible answer is that it's probably just somewhat harder to JIT a larger instruction set (it is larger, correct?), but that that doesn't matter in the long run, since theoretically, if you would really want it, you could always return to the smaller set and JIT that. ]