|
What is Dalvik? by Mark Murphy |
|
Wednesday, September 15 2010 @ 03:54 PM EDT
|
I asked an Android guy to explain some things to me about Dalvik, so I could understand the Oracle v. Google situation in more depth. I'm not a programmer, I told him, but I need to understand the tech behind the lawsuit, so I can understand when the lawyers start arguing about what Google did and didn't do and whether it was entitled to do it or not. What is Dalvik? Why use it? So I asked Mark Murphy, the founder of CommonsWare, and who is the author of three
books on Android application development, including Busy Coder’s Guide to Android
Development, to explain it. He also trains folks in developing for Android. Also, he doesn't work for Google, so he can speak more freely. Once you are in litigation, most companies are silent as the grave until it's decided. Don't go by SCO. That big-mouth grandstanding to the media was not typical. If, like me, you never paid much attention before to all the intricacies of Java, it's a chance to get up to speed on all that, as the article walks us through different ways the word Java is used, sometimes a bit loosely, as well as explaining what Dalvik does and the benefits it offers.
What I understand is that there were important technical reasons why Google would want to roll their own code, involving security, memory consumption, and speed, quite aside from any legal or licensing issues. This article isn't directly about the legal issues, by the way, the question that hovers over this matter in my mind, namely can anyone can write their own Java-like code without getting sued? This is just about the technical side, but as the case goes forward, understanding the technical bits will help us to understand the legal bits.
I've learned a few other things from researching and asking around that helped me to further understand the context for why Google went the way it did. For example, Sun's version of Java for mobile, Java ME, is released under GPLv2 only, but unlike OpenJDK, the open-source version of Java SE, there is no Classpath exception applied to Java ME, so using it might create doubt about whether the system exception applied. Moreover, none of the innovation over the past few years (like JavaFX) is in the open source version. I think then that it would be accurate to discern that Google wanted something better than what was available.
So, with that introduction, here's Mark's article:
**************************
What is Dalvik? ~ by Mark Murphy
When it comes to the Oracle lawsuit against Google regarding Android, many sites and news outlets say that “Android applications are written in Java”.
As usual, this is a bit of shorthand.
To really understand what is going on, and where Oracle’s lawsuit comes into the picture, we need to have a bit more detailed picture of what really goes on when somebody writes an Android application:
1. Developers write Java‐syntax source code, leveraging class libraries published by the Android project, Apache Harmony, and other groups.
2. Developers compile the source code into Java VM bytecode, using the javac compiler that comes with the Java SDK.
3. Developers translate the Java VM bytecode into Dalvik VM bytecode, which is packaged with other files into a ZIP archive with the .apk extension.
4. An Android device or emulator runs the .apk file, causing the bytecode to be executed by an instance of a Dalvik VM.
And for most of you, that description was gibberish. That’s the reason why we use the shorthand “Android applications are written in Java” — spelling out all those details every time would get very tiresome.
But, we need to sort out this gibberish to answer questions like:
What is Oracle suing over?
Why does this impact Google, if Java was released under the GPL?
Who else might be at risk due to Oracle’s decision to sue?
This article will try to explain two things, in lay terms:
1. What does all that gibberish mean?
2. What technical reasons are there for all that gibberish,
compared to the similar gibberish an ordinary Java developer would use?
3. Where do the Oracle patents and such tie in, generally speaking?
First, a few disclaimers:-
In the interests of making this stuff make sense to more ordinary people, I will wind up using some shorthand of my own from time to time. Purists will probably come up with any number of places where what I say glosses over some details. I am certainly interested in making updates and corrections as needed, where those will materially help ordinary people understand things better.
-
I will use “Sun” to refer to the firm that invented Java and created the Java development tools. I will use “Oracle” to refer to the firm that acquired Sun and, therefore, owns patents, copyrights, and trademarks relevant to Java.
-
I am an Android advocate, though I do not work for Google. While this article is not strictly intended to steer readers’ opinions one way or another on the merits of Oracle’s lawsuit, I am sure that my biases will leak through.
-
This article is written for people who have a smattering of technical knowledge, enough to, say, have made some sense over what was going on in the various lawsuits that SCO was recently a part of.
-
I have a somewhat quirky sense of humor. You have been warned.
Explaining the Gibberish
Let’s take those four pieces of gibberish and examine them, one scary‐looking phrase at a time.
“Java‐syntax source code”
“Java” itself is a bit of shorthand. There are many things that can legitimately be called “Java”. One of those things is the syntax of the Java programming language.
Software developers write source code, in some programming language. Java offers one such language, but there are a crazy number of other programming languages, from FORTRAN and COBOL of the mid‐20th century to newcomers like Scala and Clojure.
Each programming language has a syntax, just as each human language has its rules of grammar and roster of available words. The Java programming language has a specific syntax.
Most — but not all — Android developers will be creating Android applications by writing Java‐syntax source code, no different than if they were writing Java applets, Java desktop applications, so‐called “Java ME” applications for some mobile phones, or Java‐based Web applications to run on a Web server somewhere.
“Class libraries published by the Android project, Apache Harmony, and other groups”
When you build a bridge, you typically do not start by opening an iron mine. Rather, you build the bridge from a mix of pre‐fabricated and custom parts. Pre‐fabricated parts might include girders and rivets. Somebody else was responsible for creating those girders, somebody else was responsible for mining the iron ore used to create the steel used to create the girders, and so on.
Similar, in software development, applications are rarely created completely from scratch. Instead, developers take advantage of pre‐fabricated software routines. One term for those, used in “object oriented” languages like Java, is a “class library”.
I mentioned earlier that there are many things that are called “Java”. Besides the syntax of the source code, some people refer to certain class libraries as being “Java”. Sun developed three major flavors of these class libraries, one for conventional desktop environments (Java SE), one for a limited mobile environment (Java ME), and one for server‐based Web applications (Java EE).
Android has class libraries. Some of those class libraries were written by the core Android team, made up of Google employees and contributors from other firms. The rest of the class libraries come from other open source projects. Notable among these is Apache Harmony, a project aiming to create a complete replacement implementation of all pieces of Java.
Specifically, Harmony offers a class library that is generally compatible with classes that come from Java itself — they have the same names for classes, for example. Android has included some — but not all — of the Harmony classes in the Android OS. Hence, Android developers can write code that use “Java” classes, despite the fact that those classes did not come from Sun and whose copyrights are not held by Oracle.
Java VM bytecode
Yet another thing that people sometimes refer to as “Java” is the Java virtual machine, or Java VM for short.
Many programming languages are “compiled”, meaning that a tool converts the source code that developers type in into something that a “machine” can execute directly. You can think of this as akin to converting a singer’s voice into the bits and bytes that go into an MP3 file or onto a CD.
Many compiled programming languages are compiled into ”opcodes” that are designed to be run by some specific sort of chip. There are opcode sets for the Intel chip in your notebook, and other opcode sets for the ARM chip in your smartphone, and still other opcode sets for the MIPS chip in your DVD player. If you want your source code to run on all three types of chips, you would need to compile it three times.
Some compiled programming languages, though, target not a real chip, but a fake one — a virtual machine. A virtual machine (VM) is a piece of software that mimics the functionality of a real chip. It runs bytecode (the VM equivalent of opcodes) designed for that specific type of VM. Different versions of the VM software can then be written to run on different types of real chips (Intel, ARM, MIPS, etc.). This way, a compiled VM application can run on a wide range of physical chips, without having to recompile the source code to target each physical chip.
Java is perhaps the most famous language that uses a virtual machine — the JVM. It was not the first and is not the only such language. Other popular languages that use VMs include Perl, Python, and Smalltalk — the latter is the language behind the Squeak app that Apple removed from the App Store for violating its “Apple‐only languages” policy. Similarly, Microsoft’s .NET languages (e.g., VB.Net, C#) run on a virtual machine called the Common Language Runtime (CLR).
The javac compiler that comes with the Java SDK
Still another thing that some people refer to as “Java” is the Java software development kit, or Java SDK (or, occasionally, JDK).
The Java SDK represents the set of tools and files needed by a programmer to write Java applications. Among other things, it includes a compiler tool — javac — that converts Java source code into Java bytecode that can be executed by the Java VM.
Dalvik VM bytecode
The Dalvik VM is a virtual machine, along the lines of the Java VM, the Parrot VM (Perl), Microsoft’s CLR, and so forth. Dalvik was written principally for use with Android, though some have experimented with using it separately.
Each VM has its own bytecode, just as each type of CPU chip has its own opcode. Hence, the Dalvik VM bytecode is not the same as the Java VM bytecode, or the Parrot VM bytecode, etc.
Translate the Java VM bytecode
That being said, Android does come with tools that translate compatible Java VM bytecode into Dalvik VM bytecode. This allows developers to write Java‐syntax source code, compile it with the Java SDK’s compiler, then get
Android‐compatible Dalvik VM bytecode in the end.
Note that not all Java VM bytecode is compatible with the translation process, and therefore with Dalvik by extension. Notably, old bytecode (Java 1.4.2 and previous) and bytecode compiled by non‐Sun Java compilers will fail to translate.
An instance of a Dalvik VM
A Java program is run by a Java virtual machine. The VM reads in the Java bytecode, finds the desired entry point (a main method on a designated class), and executes the bytecode instructions. Similarly, an Android program is run by a Dalvik virtual machine.
If you wanted to run two separate Java programs at once, you will usually wind up with two copies of the Java virtual machine running on your computer. Similarly, when you run more than one Android application, each application usually gets its own Dalvik VM instance.
So, Why Dalvik?
OK, so, why did anyone bother to create Dalvik in the first place? Why not just use plain ol’ ordinary Java?
I do not claim to know all of the rationale behind the decision. That being said, here are at least some of the known technical reasons:
Memory Consumption
As noted above, if you want to run more than one Java or Android application, each application gets its own virtual machine instance. However, in Java, that will require a substantial amount of RAM, and on Dalvik it does not.
Why? Sharing.
Much of what is in a VM is read‐only. For example, the class libraries each VM uses do not typically get modified when a program using those libraries is run.
In Java, each application gets its own copy of all the read‐only portions of the VM.
In Dalvik, each application shares one master copy of all the read‐only portions of the VM, using techniques like copy‐on‐write.
As a result, Android, through Dalvik, can run more programs in a tightly‐constrained memory environment, like a smartphone.
Security
Saving memory is good. It allows us to do more with less. However, with Dalvik, there is an extra important benefit: it gives us better security that might otherwise be possible.
Linux has a security model baked into the kernel, one involving users and permissions. Each Linux program is run under a certain user’s account, whether that be a real person or a fictitious account for a particular program (e.g., an apache account that runs a Web server). All files in a proper Linux filesystem are owned by some user. Files that are marked as usable only by the user can be read and written to by that user’s own program, but cannot be read or modified by any other program, since other programs run as other users.
With me so far?
In Android, by default, each application gets its own user account — akin to the apache scenario above. When you run an Android application, it can access its own files, but it cannot access other applications’ files by default, courtesy of it running as a certain user.
This is only possible because of the memory sharing described in the previous section. If Android were limited to a traditional Java VM, each program would take up too much memory. Android applications might all have to share a single Java VM and all run as the same user, meaning one application could access another application’s data. You would have to layer all sorts of security cruft into the Java/Android environment to isolate applications from one another.
But, the memory sharing means each Android application can have its own Dalvik VM and run under its own user account. As a result, we get the tried‐and‐true Linux security model, making it significantly less likely that one application will be able to abscond with another application’s data.
Register‐Based VM
There are two ways to implement a virtual machine, “stack‐based” and “register‐based”. Java VMs tend to be stack‐based. The Dalvik VM is register‐based. This too is an optimization designed for mobile environments, where RAM is limited, as you can get more stuff done in fewer bytes, on average, with a register‐based architecture.
|
|
Authored by: NetArch on Wednesday, September 15 2010 @ 04:00 PM EDT |
OT Wow - I finally got one? ;-)
---
NetArch - building a better Internet one subnet at a time...[ Reply to This | # ]
|
- Could Microsoft buy SuSE? - Authored by: NetArch on Wednesday, September 15 2010 @ 04:03 PM EDT
- Novell sell imminent - Authored by: Anonymous on Wednesday, September 15 2010 @ 04:38 PM EDT
- Science vs Reason - Authored by: Anonymous on Wednesday, September 15 2010 @ 04:41 PM EDT
- HTC and the Unlock patent revisited - Authored by: soronlin on Wednesday, September 15 2010 @ 04:56 PM EDT
- Too Few Women in Tech – Am I Responsible? - Authored by: Anonymous on Wednesday, September 15 2010 @ 05:12 PM EDT
- what does oracle object to in all this? - Authored by: Anonymous on Wednesday, September 15 2010 @ 05:20 PM EDT
- Another sleazy bankruptcy story - Authored by: Anonymous on Wednesday, September 15 2010 @ 06:34 PM EDT
- Skyhook Wireless sues Google for business interference - Authored by: Anonymous on Wednesday, September 15 2010 @ 07:51 PM EDT
- Neon now wants PSJ in IBM case - Authored by: SpaceLifeForm on Wednesday, September 15 2010 @ 08:38 PM EDT
- Diaspora released to developers - Authored by: Anonymous on Wednesday, September 15 2010 @ 10:31 PM EDT
- Today's Dilbert is funny... - Authored by: Anonymous on Thursday, September 16 2010 @ 03:10 AM EDT
- [OT] Old Chestnut: Buying PCs without having to pay for Windows. - Authored by: TerryC on Thursday, September 16 2010 @ 05:45 AM EDT
- Intellectual Property - Authored by: JamesK on Thursday, September 16 2010 @ 07:00 AM EDT
- [OT] Dilbert's Intellectual Property - Authored by: Anonymous on Thursday, September 16 2010 @ 07:26 AM EDT
- Who's buying Novell? Place your bets - Authored by: JamesK on Thursday, September 16 2010 @ 08:31 AM EDT
- SCO Group auctions UNIX division - Authored by: JamesK on Thursday, September 16 2010 @ 12:21 PM EDT
|
Authored by: Anonymous on Wednesday, September 15 2010 @ 04:14 PM EDT |
Thank you very much for the effort to explain, let's not pass that by.
I (think I) can follow the build-up, however it seems to end rather abruptly:
where is Oracle, and where is Google in all this..?
So the three things the article intends to explain, being
1 the gibberish, is kind of clear.
2 the technical reasons and advantages, okay.
3 the patents feel kind of left out.[ Reply to This | # ]
|
|
Authored by: Henning Makholm on Wednesday, September 15 2010 @ 04:46 PM EDT |
2. Developers compile the source code into Java VM bytecode, using
the javac compiler that comes with the Java SDK.
It should be noted
that there are other compilers from Java source code to JVM bytecode, besides
the one that comes with the Java SDK. In particular, the Eclipse project has
produced such a compiler from scratch, based on Sun's public documentation of
the source and bytecode languages.
GNU also has a Java-to-bytecode compiler,
which IIRC is based off Eclipse's one, but integrated with GCC.
This is
relevant because many (most?) developers will use the Eclipse compiler -- and
therefore will not be running any code owned by Oracle at any point
during the development cycle (except perhaps for the JVM atop which they run
Eclipse). [ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, September 15 2010 @ 04:53 PM EDT |
Most Unix(s) will keep only one copy of the executable(run-time binary)
in memory for multiple running instances of an executable. The data segment will
have a separate memory image for each running instance. I believe this is true
for Linux as well, as well as Microsoft (it is a technique that has been
around for a while.)
Because each VM is already sharing their
binaries because of the underlying OS, this would make Dalvik's technique
redundant. I suspect the line "In Java, each application gets its own copy of
all the read-only portions of the VM" might need to be "In Java, each
application gets its own copy of all the read-only portions of the Class
Libraries used by the VM" (similarly with the line below it). The OS is
already taking care of sharing the VM read-only itself. The Class Libraries are
'input' to the VM as well as the byte-code you are trying to run.
Side
effect (probably intentional) of sharing the Class Library read-only
bytecode is faster startup of an application under the Dalvik VM.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, September 15 2010 @ 05:05 PM EDT |
One thing that strikes me about this discussion is that while Oracle should not
be able to complain about someone writing source code in a Java-like syntax and
having it compile to an alternative virtual machine, they may not like having
restricted Java libraries, originally generated by Sun, automatically converted
to run under a different virtual machine. In a very real sense, converting Java
VM code to run on Dalvik is taking copyrighted code and converting the
algorithms captured in Java VM code and making it "Dalvik" code. It is
similar to the effect of GPL code being used in a proprietary system, and
locking it way from end user modification. In both cases, the original writer of
the code, looses control of how their algorithms are used. With the GPL, the
programmer uses the power of his algorithms to cause more GPL code to be
generated. With Oracle, it is used to enhance their business.[ Reply to This | # ]
|
|
Authored by: artp on Wednesday, September 15 2010 @ 05:07 PM EDT |
"Eror" -> "Error" in the Title block, please.
---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?[ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, September 15 2010 @ 05:24 PM EDT |
You can say it is not java but it still requires java tools to create java
compiled
code. Looks lazy to me. With all the smart people at Google, why not
create your
own java source code converter instead of doing bytecode
conversion. Why risk
copyright/license violation knowing that Sun had sued
Microsoft to protect java
from embrace, extend, extinguish. Something does not
pass the smell test. By
using bytecode conversion, I still contend that you can
convert any framework or
third party library files not just "user" source.
[ Reply to This | # ]
|
|
Authored by: dcs on Wednesday, September 15 2010 @ 05:47 PM EDT |
There are other languages that generate Dalvik-compatible bytecode, such as
Scala. When developing a Scala application for Android, the closest you need to
get to Java is having an intermediary bytecode and using Harmony-produced Java
libraries.
---
Daniel C. Sobral
[ Reply to This | # ]
|
|
Authored by: artp on Wednesday, September 15 2010 @ 05:56 PM EDT |
URL ? Then we'll know what you're talking about.
---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?[ Reply to This | # ]
|
|
Authored by: betajet on Wednesday, September 15 2010 @ 06:02 PM EDT |
I would humbly suggest that "Java syntax source code" be enhanced to include
"Java semantics". The syntax of a language is merely its grammar: how
characters are formed into words and how words are formed into expressions and
statements. What these words actually do at run-time is the semantics of
the language, i.e., its meaning or behavior.
I think the author would like
to say that Java source code used in Android has both the syntax of the Java
language and has the same semantics as well.
Most languages have a tight
correspondence between syntax and semantics, but not all. Even languages that
normally have tight correspondence have exceptions: for example C and C++ use
the same syntax for a macro call and a function call, even though they behave
quite differently.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, September 15 2010 @ 06:06 PM EDT |
> When you build a bridge, ... somebody else was responsible ...
Sums up a whole mess of patentable stuff.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, September 15 2010 @ 08:48 PM EDT |
Java Source Code - Is readable by humans like a book of
instructions
Java bytecode - Is readable by the Java
Virtual Machine (still a list of instructions)
Dalvik bytecode
- Is readable by the Dalvik Virtual Machine (same set of
instructions)
So the javac (Java Compiler) translates human readable
instructions into Java Virtual Machine instructions.
The Andoid tool
translates the Java Vitual Machine instructions into Dalvik Virtual Machine
instructions.
It really can be tied to a real world problem. If one
person spoke English and another spoke Spanish, and another spoke German - You
would need a translator from English to Spanish and another one from Spanish to
German.... Same basic concept but we are talking about Human Language (Java
Source Code) and two Computer Languages (Java VM bytecode, and Dlvik VM byte
code)....
[ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, September 15 2010 @ 10:16 PM EDT |
I'm unclear on this point, is there a way to write apps just for Dalvik without
using Java? Is there a compiler that generates Dalvik bytecode? [ Reply to This | # ]
|
|
Authored by: SilverWave on Wednesday, September 15 2010 @ 10:26 PM EDT |
I had most of this down from previous research but its nice to have an
explanation from an authoritative source.
Cheers.
---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
|
Authored by: SpaceLifeForm on Thursday, September 16 2010 @ 12:22 AM EDT |
Link
November 12th, 2007
Sun released their “free java”
source code under the GPLv2 to both win the free software crowd and capture
peripheral innovation and bug fixing from the community. For the java standard
edition (aka “the cat is out of the bag”) there is an exception to the GPLv2
that makes it “reciprocal” only for the Java platform code itself but not for
the user code running on it (or most people wouldn’t even dare touching it with
a pole).
But such exception to the GPLv2 is not there for the mobile edition
(aka “where the money is”).
Stefano Mazzocchi spotted this
lawsuit long ago,
but I'll bet he did not know it would be Oracle doing
the
dirty work.
Lots more at the link.
Sorry for being so
on-topic.
---
You are being MICROattacked, from various angles, in a SOFT manner. [ Reply to This | # ]
|
|
Authored by: bprice on Thursday, September 16 2010 @ 01:51 AM EDT |
There are two ways to implement a virtual machine,
“stack‐based” and “register‐based”. Java VMs tend to be
stack‐based. The Dalvik VM is register‐based. This too is an
optimization designed for mobile environments, where RAM is limited, as you can
get more stuff done in fewer bytes, on average, with a register‐based
architecture.
The last sentence is presented as a general truth,
that register-based architectures produce more compact code than stack
architectures. In my experience, it's not a general truth — there are, at
best, confounding factors omitted.
The experience of which I speak occurred
more than 40 years ago, during the design of a mainframe architecture. We had a
choice of register-based and stack, of course. We also had serious memory
limitations, so code compactness was as much of an issue as with current mobile
applications. Maybe it was even more of an issue, since RAM was thousands of
bucks per kilobyte — the market size differed enough, though, ...
So we
did something really unusual — we measured it. We found our proposed
stack architecture produced about 40-60% of the code size as any feasible
register architecture that would meet the project's requirements.
Since code
compaction was a priority for us, we weren't too surprised. For the same
reason, our experience does not generalize, just like the Java/Dalvik findings
do not. Java bytecode did not have a pressing need for compaction; Dalvik does.
Thus, I'm not surprised at their experience. --- --Bill. NAL: question
the answers, especially mine. [ Reply to This | # ]
|
|
Authored by: barbacana on Thursday, September 16 2010 @ 02:03 AM EDT |
I'm a software developer who uses Java, among other languages. As a language,
it has its critics. But I
don't use it because I find it a good language, I use it because it comes closer
than most languages to letting me write a program once and use it in different
environments.
A language like C++ can be (and is) used to write portable
programs. But it has 2 problems.
- You have to recompile it for each new
platform
- You have to pick a GUI library if you want a
GUI
The first problem means that you can't easily write an
applet for a web page in C++.
The second problem means that if you want a
GUI, and you want your program to work in GNU/Linux and in Windows, you have to
choose between one of the GUI libraries. Three well-known ones are Gtkmm, Qt and
wxWidgets. They all have their advocates, but their real problem is that there
are three of them. You learn one, then you go to work on somebody else's project
and they've picked a different one, so you have to learn that. And learning a
GUI library is a painful process.
With Java, the GUI libraries are much
more standard. They're part of the Java spec, not bolted-on afterthoughts that
have been done in various incompatible ways by different people, as was the case
with C++. There are a lot of naysayers out there, but the truth is that Java
comes closer than any other language to letting me write programs once and then
run them in multiple environments. Perl and Python are nice but not for applets.
ECMAscript (aka Jscript or Javascript, don't confuse it with Java) can run in
the browser but it hasn't got the powerful GUI libraries.
What Google is
doing seems to be disrupting this. Thereby taking away the only reason I use
Java in the first place. Google has cited some technical reasons but none of
them is serious. This was a marketing/legal decision, not a technical
one.
I don't like software patents, so I don't support either side in
this dispute. [ Reply to This | # ]
|
|
Authored by: IMANAL_TOO on Thursday, September 16 2010 @ 02:15 AM EDT |
I am not sure about the actual relevance to the similarities
between a war and
litigation. But, they do have at least two
common perspectives - (1) different
mindsets to begin with
and (2) a winner and a loser. There are of course all
shades
of these, but I think it may be seen as a start.
I just read an
old 1991 interview article in Time called "On The
Mistakes Of War: ROBERT MCNAMARA".
with
Robert McNamara about the first
Gulf War (I can also
recommend the very interesting film "The Fog of War:
Eleven Lessons from
the Life of Robert S. McNamara").
In the Time interview McNamara is
asked:
Q. Did you ever imagine anything like the large
number of
casualties that the U.S. experienced in Vietnam?
A. Certainly
at the beginning there was no anticipation of
that. That is correct.
Q.
When did it become apparent? Does it relate to the gulf?
A. The
situations are not analogous, except in one sense:
the consequences of military
action are unpredictable. I
learned this as Secretary time after time after
time: we did
certain things we thought would lead to certain results, and
the
results were different. The Soviets have learned the
same thing.
I think that the litigations covered here have shown this
too. Nothing has been really predictable. Who would have
anticipated SCO
surviving seven years in court? With this
Oracle and Google case, we have the
backbone money on both
side from the start. But will that lend to anticipate
the
future outcome? Judging from McNamara's experience, no. So,
the tentative
reward for Oracle must be really really
high.
What could those rewards
, really? I understand it may be
about control, and ultimately money, but where
is the money
here? I can not see it coming in large drove from anywhere,
yet.
Potential fees from all Android developers? Potential
fees from all Android
users, analogous in the SCO case? A
hundred bucks a year from all Android users
would sum up
nicely, enough even for Mr Ellison. But is that the goal and
is
the cost of war worth the litigation?
--- ______
IMANAL
. [ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, September 16 2010 @ 04:18 AM EDT |
This missed the most important bits. Why the patent lawsuit.
In the process of working on Java, Sun wound up being first to do a lot of
important stuff for making an efficient VM. They took out patents on it. You
are protected from being sued for those patents if you use Sun's implementation
of Java.
However Google did not use the Java code. Therefore the patent license that Sun
offered to the whole world to people who used Java, does not apply to Google.
(Had Google used the code that Sun published, then Google would be caught by the
GPL v2, and everyone writing Android apps would be forced to use the GPL v2.
Alternately you could pay Sun to get more convenient license terms, which is
what Sun was trying to make happen.) Google has done some of the same things
with their VM that are covered by Sun's patents. Now that Oracle has bought
them, Oracle sees the opportunity to litigate.
In a number of comments I see the misconception that the fact that Google is
being sued because Java is used in the development process. Not so. Google is
being sued for using techniques in their virtual machine that are covered by
patents that Oracle now owns, without Google having a license letting them do
so.
Incidentally odds are that if Microsoft doesn't have a patent arrangement with
Oracle, they could be sued for C#.
IANAL and all that.[ Reply to This | # ]
|
- The key legal point - Authored by: Anonymous on Thursday, September 16 2010 @ 05:26 AM EDT
- The key legal point - Authored by: Vic on Thursday, September 16 2010 @ 07:14 AM EDT
- As for Forth - Authored by: Anonymous on Thursday, September 16 2010 @ 09:44 AM EDT
- As for Forth - Authored by: Vic on Thursday, September 16 2010 @ 09:56 AM EDT
- As for Forth - Authored by: Anonymous on Thursday, September 16 2010 @ 10:40 AM EDT
- As for Forth - Authored by: Vic on Thursday, September 16 2010 @ 11:19 AM EDT
- As for Forth - Authored by: Anonymous on Thursday, September 16 2010 @ 11:49 AM EDT
- As for Forth - Authored by: Anonymous on Thursday, September 16 2010 @ 11:53 AM EDT
- As for Forth: OO - Authored by: Anonymous on Thursday, September 16 2010 @ 12:04 PM EDT
- As for Forth - Authored by: darthaggie on Thursday, September 16 2010 @ 12:35 PM EDT
- Well done, Vic - Authored by: Ian Al on Thursday, September 16 2010 @ 10:37 AM EDT
- The key legal point - Authored by: Anonymous on Thursday, September 16 2010 @ 11:00 AM EDT
- That remains to be seen - Authored by: Anonymous on Thursday, September 16 2010 @ 11:35 AM EDT
- MicroSoft sued? - Authored by: Anonymous on Thursday, September 16 2010 @ 11:58 AM EDT
- Patents - Authored by: The Mad Hatter r on Friday, September 17 2010 @ 11:20 AM EDT
- .NET Has Nothing to Do With Oracle. - Authored by: Anonymous on Friday, September 17 2010 @ 06:34 PM EDT
|
Authored by: GriffMG on Thursday, September 16 2010 @ 04:36 AM EDT |
It must have take more than five minutes and really helps.
B-)
---
Keep B-) ing[ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, September 16 2010 @ 05:48 AM EDT |
I have a certain affinity to Google's dilemma vis a vis Java
on a smart phone.
A few years ago, I was working at a company called IPC. We
produced what are called 'turret systems' - basically PBX
systems on massive steroids. We decided to build the next
generation deskset for this system. This deskset was very
analogous to a smart phone - on steroids. For example -
there were between 4 and 11 CPU's in one deskset.
We built this on Linux. We also investigated building the
user interface, and other components using Java. Ultimately
we rejected Java as a viable option. Had Dalvik existed at
that time, we might very well have used it.
The problems we had with Java were several. First, the JVM
must either be available for the CPU you are using, or you
must port the JVM to it. We had two different flavors of
CPU, but we did find JVM's that were for CPUs very close to
ours. The vendor who had these JVM's was no longer
interested in maintaining them, so it would have been very
expensive for us to pay them to maintain them.
Next, Java ME (the only sanctioned Java normally _allowed_
to run in an embedded device) was very much cripple ware, as
compared to Java SE (explicitly forbidden for use in a
telephone!).
Finally, modeling the CPU use and memory use of Java was a
bit scary. Like Android, and unlike most phones that use
Java, we were multitasking. Multiple instances of the JVM
were not appealing. Next, the deskset is very much more
than just an ordinary phone. There was a lot more going on
behind the scenes, just to run the phone, than is happening
in a smart phone.
Point is, Java, as promulgated by Sun, just is not suitable
for a phone like ours, or like Android.
IPC was far to small to consider entering into a special
license with Sun to put Java SE on our deskset, or get
exemptions to the limitations of Java ME. We were also too
small to do our own VM. Neither of these considerations
apply to Google, of course.
My best guess is that Sun, when confronted with the prospect
of a 'divergent embedded JVM and Java class libraries' would
not object to much, if that JVM and library set were not
exposed to anyone outside the licensee for such divergent
implementation.
On the other hand, given that Google wanted to make the VM
and libraries publicly available, I bet Sun would dig in
it's heals, and say no way! Java must be Java (tm). Even
though the case here is NOT the same as the Sun vs Microsoft
case, the underlying principle, no divergence is the same.
So, Google, being well capable of it, produced it's own VM
and libraries, based on Harmony.
The only gotcha I could see arising in this lawsuit might be
something contractual between Google and Sun, back in the
Java investigation days, before Dalvik. This might be what
gives rise to the copyright claim. Or maybe not, maybe
Oracle thinks that using Java documentation with copyrights
held by Oracle to do anything 'non-Java' is a copyright
violation?[ Reply to This | # ]
|
|
Authored by: jpvlsmv on Thursday, September 16 2010 @ 09:27 AM EDT |
When you compile an Android application with javac, do the bytecodes that come
out include parts of the Sun Java standard classes?
Then, when you run it through the Dalvik translator, are you creating a
derivative work* of those standard class bytecode sequences?
I don't know much about the license of the Java standard library bytecodes, but
could this be where Android runs afoul of the Oracle America copyright license?
What is the license for including pieces of java.lang in other works?
--Joe
* In terms of copyright law, does performing a mechanical (non-creative)
transformation of a copyrighted work create a derivative work, or is it still
the expression of the same creative idea? Is the javac compiler doing anything
different to the work than a photocopier set to enlarge the print of a piece of
text?[ Reply to This | # ]
|
|
Authored by: DannyB on Thursday, September 16 2010 @ 10:17 AM EDT |
The p-System was in use in the 1970's and early 1980's. In fact, the p-System
and the Pascal language were the basis of Apple development tools on the Apple
II and Apple III.
Softech made the p-System for other platforms. This included very different
microcomputers (Z80, 6502, etc) and minicomputers (DEC VAX), IBM PC, etc.
The binary programs emitted from the p-System Pascal compiler could be run on
any of these computers that ran the p-System virtual machine. (At the time
called p-System "interpreter".)
So the idea of using virtual machines to execute one or more source languages on
one or more target computer architectures is quite old.
---
The price of freedom is eternal litigation.[ Reply to This | # ]
|
|
Authored by: DannyB on Thursday, September 16 2010 @ 10:22 AM EDT |
Instead of the bridge analogy it might be better to use a building analogy.
When you say "building a bridge" it has secondary meanings that
"constructing a building" does not have.
The fact that both require vast amounts of standardized interchangeable parts
makes the analogy good. A building even more so. Not just rivets and iron
girders, but windows, sheetrock, pipe fittings and countless other things.
---
The price of freedom is eternal litigation.[ Reply to This | # ]
|
|
Authored by: TiddlyPom on Thursday, September 16 2010 @ 10:37 AM EDT |
This is why this is a silly lawsuit. Dalvik is just another VM (like the Ruby
VM, Python VM, .NET CLR, Parrot VM etc) not a clone of Java!
Dalvik is not a
language at all - it is a combination of:
- The 'dx' binary-to-binary
translator which reads Java binary (class) byte code files and outputs
equivalent Dalvik (dex) byte code files
- The Dalvik VM itself (target
environment) which runs the (dex) files
It is more analogous to
something like Mainsoft Grasshopper which
reads Microsoft .NET binaries (CLR) and outputs equivalent Java class (binary)
files which can then run on Tomcat on
Linux. In this way, Google is not actually doing an end-run around Java ME - it
is allowing developers to create applications which run on the Dalvik VM which
just happen to utilise the Java compiler to product the intervening byte
code.
Google could just as well (and I have started to look at this)
produce an equivalent to dx which reads Python binary byte code and outputs dex
files (or for Ruby, Parrot, .NET CLR etc). They could, instead, develop a
compiler that takes source code as an input and produces dex files directly as
an output but that is outside the scope of this
trial/discussion.
--- Microsoft Software is expensive, bloated,
bug-ridden and unnecessary.
Use Open Source Software instead. [ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, September 16 2010 @ 11:55 AM EDT |
I understood the technical reasons for wanting a VM that uses less memory,
separates applications for security, etc. It seems like this could have been
accomplished by writing their own VM that still executs Java byte-code. Then
they wouldn't have to bother with the translation from Java byte-code to Dalvik
byte-code.[ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, September 16 2010 @ 12:15 PM EDT |
The courts have said that software patents apply to a real things. Software
on a particular hardware.
But Java and Dalvik don't meet that criteria.
Both are 'virtual' machines. Different virtual machines.
Oracle is
suing about Google's Dalvik virtual machine infringing on their Java virtual
machine.
'Virtual' being the key here. That's why Google is certain
they are protected. Oracle is just looking for a settlement to make the
case go away; something to help pay for the residue called Sun Microsystems
(which I suspect they only bought for MySQL; a real competitor). Like IBM
in the SCO/IBM case, they are looking for fool's gold.
Funny really. Sun
could have taken Java down the Unix/Linux road of user privilege, saving memory
space right off the bat. They might have even bifurcated Java into a
single/multi instance based on the user privileges available. But what can you
expect from a language designed to make vending
machines work?
Java's main platform was to be on smart toasters. User
privilege don't exist and don't make sense. Being process privileged, it must
have been easy to port to Windows; they are equally crippled.
Dalvik is a
completely different animal then JVM. Like English. American vs. Indian. Same
language, very different sound. It should be simple to explain in court. [ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, September 17 2010 @ 07:36 PM EDT |
This one too.
Try to make argument why Dalvik is better than OpenJDK for mobile devices. I
think that is wrong argument. Heart of the problem is: Why Google chose to base
Dalvik on Harmony instead of OpenJDK.
Dalvik uses Harmony class libraries and its own VM. Harmony is reverse
engineered copy of OpenJDK's class library. Why Google didn't use original
OpenJDK class library? And then they could still make their own register-based
VM to use with original class library.
That would make thing GPL and Google would be protected from Oracle patents
since they use OpenJDK code. And it would have better Java compatibility since
it uses official class libraries. Writing proprietary apps for android would be
possible too, because of Classpath exception, and because Google could still
release their own additional APIs under Apache licenses, so proprietary apps can
link it. It would be problem to ship proprietary apps that link non-CE API (that
are apache licensed) together with JVM, but all apps come from App store anyway.
Vanila distro should be open source.
Fact remains that Google decided to avoid GPL. They didn't chose Harmony as a
base for practical purposes; OpenJDK's class library is superior to Harmony in
every way, and it would take less work to adapt JVM for mobile than to adapt
Harmony for mobile. They wanted to avoid GPL, that is whole story.
Being opponent of software patents, I don't like anybody to get sued. Being Java
developer, I don't like Google co-opted Java and broke WORE promise. Being an
Free Software fan, I don't like Google evaded GPL even at the price of getting
sued.
[ Reply to This | # ]
|
|
|
|
|