Each class is a file. Each package is a folder containing class files or
other
folders (packages). java.lang.String means there is a String.class file
in the lang
folder (or lang package) which is found in the java folder (or
package.) That is
how Sun and programmers who program java have to do it. It's
a bit passé and I
have no idea if Google implemented their source code with the
same structure.
I've been wrong before, but here is what I think
happened.
- Google buys the Android phone and agrees that third-party
applications
are the key to breaking it into the market.
- They
investigate alternatives
and decide that java is the language that has the
developers they need and, as
the language purports to be write-once
run-anywhere (it isn't and everyone
knows it, but it's kinda close), has
promise vis a vis many applications pret a
porter at or soon after
launch.
- Sun and Google are talking a bit. Sun
would like to be making
some money out of mobile, this looks to be the last
train leaving the station
and they also think it's to their benefit to have more
platforms where java is
relevant. Talks don't go
any where.
- Google decides to build its own
virtual machine, which
necessarily has its own byte code. This is done clean
room so Sun's source
code, which is available, is not referenced as libraries
are written.
- However, in order for java developers to buy into the
platform, the
developer source code dalvik consumes and transforms into
bytecode has to
have the same package, class, and method names and signatures,
otherwise
compilation fails. If that happens developers have to port their
application and
rewrite all the parts where javac compilable code fails on
dalvik. This puts the
platform's immediate viability at risk as developers
won't spend to rewrite code
unless the platform establishes
itself.
Not every package in java was replicated. Some of the
packages
in java are third-party donations and while Oracle initially claimed
them, Oracle
was told no soap. There were 37 packages that were replicated and
this
replication had to be done with reference, perhaps indirect, to Sun's
documentation.
Oracle is not claiming that looking up the documents for
writing programs
is a problem. Oracle is not claiming that a coincidental
commonality of names
and methods is a problem. Oracle asserts that the
essential replication of
multiple core packages becomes the
infringement. I'm going to
editorialize now. Oracle has a point. Google
used java's popularity, which was
built by large investments among Sun and
others, in order to save money on
bringing the Android platform to market and
to give it an important leg up on
having an application library. In some sense,
Sun did have the upper hand:
there were no feasible options. C and C++ are more
fragile because no garbage
collection, pointer
arithmetic and null-terminated
strings, C# is Microsoft's and in the 2003 time
frame not as rich as the java
application universe and the setting up of a
development
environment on a
non-Windows machine fraught with annoyances. Objective-C
(Apple's development
language) was hated, is just C with square brackets and
has no garbage
collection. Clearly Google, once it
decided to roll its own java, took
all the right steps to be independent, except
for this question about the
structure and organization of the 31 packages. I've
omitted sequence, because
sequence is clearly not at play here: the packages
and the methods are order
independent. I can see the point that blocks are
irrelevant and Google cloned a
subset of java without infringing. I
know one interpretation of
Van
Nest's raising of the registration issue is a warning shot telling Oracle/BSF
that its fuzzy ever-changing presentation of its claims is to stop. One
interpretation that occurred to me is that Van Nest realized that finally BSF
had
found a traction point, not in individual methods and certainly not in
implementations and of course not in comments, but in whole blocks of names.
Once BSF stumbled across a theory of infringement that could be taken
seriously, then it was time to raise the question "But, when did you provide
evidence that you authored this stuff because we've looked at the registrations
and they don't conform with your assertions of ownership and your ability to
pursue these lines of reasonings." There are other complications, such
as
CEO blogs and Apache Harmony, which might have provided the guidance for
package, class, and methods. We didn't have much testimony about that, so
who
knows what the jury will think, or even understand what it means
that Harmony
wrote a java, but couldn't call it that because it couldn't get a
TCK. If I was
a juror, I could see me deciding that Google didn't copy the apis
from Oracle,
because they copied it from Harmony, and maybe Oracle should go
after
them. Well, I read, I weigh the comments, I make my estimates of
what
will
happen and when I'm wrong, I learn. I don't think a positive result
for
Oracle will kill java or make it any less desirable. The politics of java,
and this
go back to the Sun days, and its state-of-the-art for the early 90s
core are
sufficient. This weekend, I'm extending a
couple of java projects I
wrote in the past for some clients. I'm going to do one
in scala, because I am
pretty sure it is a better language than java and while it
uses the jvm, this
project will run on a server the client controls, so we don't
have to worry
about getting users to add the runtime, as we would with a
desktop java
application. The other project
might use gambit-c scheme, but only if the
Racket (which is an advancement of
Scheme) environment I'm using cannot compile
a native standalone executable.
[ Reply to This | Parent | # ]
|
