Dalibor Topic wrote:
On Tue, Aug 22, 2006 at 04:18:48PM -0400, Geir Magnusson Jr. wrote:
Dalibor Topic wrote:
Geir Magnusson Jr. wrote:
Maybe - or just declaring a patent peace or patent commons. I think
that there's nothing wrong with proprietary software, so if they want
to keep competing using it, great.
I don't see a point in proprietary JVMs, and class libraries for major
operating systems, in today's situation.
The only purpose I could see them used for is as a tool for attacks on
the integrity of the platform through locking in users into proprietary
extensions.
How about performance, either in speed, real-time predictability, memory
usage/footprint, reliability, serviceability, manageabliity?
I am talking about proprietary extensions, you're talking about memory
footprint. One has nothing to do with the other. Could we stay on topic,
please?
I wasn't only talking about "memory footprint". How about native
integration with Tivoli? Proprietary and an extension, and something
that people will and probably do pay for.
How about real-time GC? Clearly an extension - the spec says nothing
about doing GC in real-time - but I bet the aeronautical and military
industry would pay for something like that...
I can see all of these, and none of these are an attack on the Java
compatiblity promise.
Sure, they are features that are beyond the scope of the specs, and
sure, you may be "locked in" in the sense you depend on some feature
(integration with your favorite management system), but your programs
are portable...
I don't think the market would be able to sort out a distributor with a
strong channel, like IBM, that went that route, as our experience in
Apache Harmony
with code using unspecified sun.* classes shows.
LOL. What experience is that? What we're doing this is just supporting
what has become the 'de facto' spec from Sun. :)
No. What we're doing is clapping our hands with forte because Sun has been
kind enough to announce that they'll open up all of their code base,
including the unspecified bits, which would allow us, in theory, to
integrate them, without having to reverse engineer them.
Do you want to take a bet that the next 'de facto' standard extensions
will be opened up within 10 years by their owners, or less?
I don't want proprietary Java vendors to waste our time in the future with
undocumented de-facto standards around proprietary extensions.
I think there's a big difference with someone choosing to use a base64
encoder that just happens to be in the sun package namespace because
they saw someones example doing that, and extensions that are intended,
designed and marketed to cause some kind of lock in.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
