Hi Harry (and apologies for out-of-sequence posts)
A. Harry Williams said:
Jeff,
Thanks for the update on Sun's positions, however unless there is
exclusivity in your license with IBM, there is no reason that Sun
could not provide it's own versions. Even though Microsoft and Intel
license the technology, you don't rely on them to be the sole provider
of Java.
Just to be clear we're on the same page: it's not that we license Java
to Microsoft or Intel, it's that Sun actually produces the Java
environments for Windows, Linux, and Solaris on the Intel and AMD
platforms. Sun engineers, not Microsoft, Intel, or AMD, develop and
support the Java implementations, just as Sun engineers produce the Sun
Studio and Netbeans IDEs that run on those platforms (and include the
platform-specific features relevant to each), that either come with your
PC your you can download for free.
I have no clue at all about whether there's any exclusivity clause that
prevents Sun from doing its own Java for z/Arch, POWER or OS/400. I kind
of doubt it (speaking whereof I do not know...), but think the reasons
comes down to business case and where to expend valuable resources of
money and staff expertise. In the case of Windows and Linux on x86 the
incentive for us is the immense volume of the developer community and
installed base.
Now Sun may have very legitimate business reasons for
providing Java on one platform and not another, and that is totally
within Sun's rights as a corporation, just as we have the right to
evaluate our own business objectives and acquire technology that we
best fits those objectives.
Of course.
Remember that the original question
dealt with developers wanting Java to be Sun's Java at a particular
level. Sun has made claims about portability of Java code. If it
was as portable as they claim, then developers would not need to request
Sun's Java at a particular level. Our experience is that Java is not
as portable as Sun claims. Since the original requestor's comment
that his developers were (insert adjective), I was simply pointing
out one additional bump in the road, that if he wasn't looking,
could derail his project, and potential ways to address the problems.
Sun is free to ignore any of our requests, but that is because Sun
has chosen to not do so, not because of a license with another vendor.
Java is extraordinarily portable, more than any other language
environment I've ever worked with, with even binaries executing across
platforms and operating systems. I _expect_ that a .jar or .class file I
compile or download will Just Work. Does that mean there are no
exceptions, or that there are no ways a programmer can make his stuff
not be portable? Definitely not. Or, is there a fear from an
adjective-wearing developer that may or may not be based in reality
(developers frequently don't want to be bothered with platform stuff
that in their opinion adds to their workload for no return to _them_ -
just like the rest of us).
Places where portability can be compromised:
- Edge conditions on memory model. A 3GB address space is (just) do-able
on a 32-bit implementation, but not in a 31-bit one. Or, (very common)
the default heap size allocated may be different in different
implementations making it hard to allocate extremely large objects.
- Differences in command-line parameters that are outside the scope of
the Java specification.
- Performance implications: there are things cheap on one implemenation
that may be more expensive on another. Timing in general is not in the
standard, so if people don't use the synchronization primitives
correctly, they can get different behavior on different platforms.
- Underlying OS implications: For example, Java's thread models allows
threads to operate at multiple priority levels. If a particular OS
doesn't have as many different levels as Java, then Java has to dispatch
threads intended to be at different CPU priorities at the _same_
priority (this happens with Windows). Potential result: new race or
starvation conditions.
- Programmatic use of language features in new versions that are not in
old versions. For example, generics added in Java 5
- Programmatic (or implicit) use of libraries (much of the functionality
is in libraries) that are not in the standard. javax.* imports, or
com.COMPANYname imports.
- Earlier features that have been deprecated and then removed (usually
in the javax.* space anyway, and a multi-release process. Example:
removal of JVMPI. There ARE differences from version to version, though
upwards compatibility is the rule.
- Native methods. If you call native C/C++ code all bets are off.
- Bugs in the alternate implementations (remember that our version is
the reference standard).
For a good reference, see:
http://java.sun.com/javase/technologies/compatibility.jsp which focusses
on inter-release compatibility.
Your last post is correct (IMO) - that up to now, at least, Sun has not
created a Java environment for z platform as a matter of (business
driven) choice. I think that's a very defensible choice, actually.
It's good to hear from you. Stay in touch.
/ahw
Thanks, and nice to hear from you as well.
regards, Jeff
--
Jeff Savit
Principal Engineer
Sun Microsystems, Inc. Phone: 732-537-3451 (x63451)
400 Atrium Drive Email: [EMAIL PROTECTED]
Somerset, NJ 08873 http://blogs.sun.com/jsavit/
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
