I've been using java since 1999. The language was released in 1995 or
1996.
There were four javas mentioned in the testimony, JavaCard, JME, JSE, and
JEE.
JEE is structured around Enterprise JavaBeans and Object-Relational
Management
layers and is for high-volume web services. It has fallen off in
terms of
relevance, and most people would prefer to use Ruby on Rails if given
their
druthers. JSE is standard java and suitable for basic
services and desktop
applications and utilities. Sun thought the first big thing
was going to be
applets, but poor network speeds and a java that needed more
work meant that
that dream was dead forever circa 1998. JavaCard is java for
smart cards which
have minimal processors. JME back then was about mobile
devices, which didn't
have
displays of any sophistication. There has been many changes and today's
smartphone compares very favorably with a mid-90s $3000 computer.
If
we keep this in mind, I think we can understand why Mr. Severan
described the
motives for splitting the javas as he did. Mid-way through the
last
decade,
when mobile phones started having the resources to run interesting
applications, once could argue that the division based on capabilities lost
importance and Sun was more focused on mobile as a revenue sector.
Sun
gave away JSE and JEE (and
OpenOffice) because Microsoft was firmly
established, offered a web application
stack and a way to make some inroads on
the desktop or protect Sun's
hardware and Solaris business was to give java
away. On the
servers, if the application you wrote could run unchanged with
Solaris
underneath, then letting programmers target Windows, or HPU/X, or
AIX,
etc., servers meant eroded some of the vendor lock-in that arose from
different
flavors of Unix or Windows. I note that java for Linux was slow to
arrive and
did so with an outside organization that Sun gave a license to.
It didn't
work. Sun's revenues
continued to decline and the company was laying off large
numbers every 2-3
years from 2000 on. But mobile was growing, the hardware was
advancing
rapidly and Sun wished to leverage its platform and its wide
programmer base
so
it became a money-maker.
The more testimony I see,
the more I think this is not a case of software
freedom being encroached, but a
case where one company thought another
should
pay for something.
The other
company engaged in talks and decided that rolling their own might
be better.
But they didn't completely build it from scratch. We are going to see
Google
have fuzzy memories about those times someone there said "We need a
license."
Oracle will have fuzzy memories about the times when it, as a
consumer and not
the owner, said giving things away was really the right thing
to do for Sun.
(The interesting element in Severan's testimony is that Harmony
was Sun, with
Oracle's blessings, making sure java was safe so if java went to
someone else,
Oracle was not at risk for suit. You got to love irony when it
appears, though
I'd have a different opinion if I was paying the lawyers.) The
folks are not
the Brothers
McBride, manufacturing narratives out of whole cloth, claiming
rights they
should have known they didn't acquire. As to the
industry, when
this case is in the books, java will still be on its long decline as
the
language arts and the computing environment have changed
with the emphasis on
networking, concurrency and distributed computation.
Nobody is
ever going to
try and write a
platform like java or .net again because it really didn't work
out that well for Sun
and
Microsoft as strategy. The aforementioned Ruby on
Rails, it runs on Windows,
but it's easier to set up an optimal environment on
Linux, so, people with
Windows Servers fire up a Linux VM, if they don't just
use a Linux host os. [ Reply to This | Parent | # ]
|
Reading the Serevan testimony I so wished I had been Google's lawyer. I would
have torn him apart and made sure the jury wouldn't believe Serevan if he told
them the time. Was he intentionally misleading or just
incompetent?
Oracle: Has Oracle ever redesigned the
APIs?
Edward Serevan: No. There is no reason for Oracle to redesign the
APIs, and it would be a lot of work (and a lot of
expense).
Hellooooo? As any Java developer who's been in the
field for a few years knows, there have been extensive redesigns of the API
during the development of Java, in particular with respect to the older APIs
(which make up most of the 37 APIs at issue).
One quote from the documentation
to the java.util.Hashtable class:
As of the Java 2 platform v1.2,
this class was retrofitted to implement the Map
interface"
And this is not the only example. There have been
many redesigns of the API where new interfaces were introduced (and even new
language features) and other classes (such as Hashtable) were changed to fit in
with the new design. The specifications of these classes have
changed.
This is particularly important with respect to another piece
of misinformation he spread:
Oracle: Asked about the different
editions of Java-- Are there edition forks or fragmentation?
Edward
Serevan: No. It's all about the capabilities of the device on which the software
runs.
This and his other testimony suggests that it's just
different subsets of a greater whole, that there's simply some classes which
will not work on one device because it lacks the respective capabilities. This
is simply untrue. I have personally developed for J2SE and J2ME. It's not simply
a matter of only using the subset of features supported by both devices. You can
NOT write a Java program which will work on both without using wrappers and
adapters (not part of Java). Not only do the 2 platforms have different classes.
The classes that exist in both are often different, have different
specifications.
But it's even worse than that. You can not even write a
J2ME program that you can be sure will work on different Java-enabled
phones.
In the mobile world Java has always been deeply fragmented, even
if only Sun's original J2ME releases were used. That's because J2ME consists of
so many optional parts which a device may or may not support. Talk to any
developer of mobile phone games BEFORE Apple and Android. It was the complete
horror. You developed your game and then you gave it to your testing team which
tested it on FIFTY different phones and would report back with at least TEN
different failure modes.
With respect to mobile, Google did not fragment
Java. Quite the opposite. Finally it's possible to write a program in Java that
will run on all phones right away.
I hope we soon get to hear the true
form of "Write once, run anywhere", the way almost every actual Java programmer
out in the field knows this principle:
Write once, debug
everywhere!
See this article from 2002.[ Reply to This | Parent | # ]
|