Mr Joel Realubit on 17 Feb 2004:
> why WOULDN'T they? i mean, if the standards are out in the open (i.e.,
> specs are submitted to a public standards body), all previous smacking
> MS got from Sun would not be relevant anymore, and nothing would stop
> MS from implementing their own Java and still call it "Java" or some
> such variation... and THEN append ".NET" to it. given that MS is MS, i
> dont think they are above that. probably the only thing that would

IIRC, and AFAIK:
1) Java was initially submitted to the ECMA-- and was later withdrawn
due to the fact that MS was the chair for that particular
standardization group, and Sun feared that MS was going to using its
clout to 'pollute' the standard.

Besides, even if Java were to become a formal standard, what's to
prevent MS from *not* following the standard, or to follow it but
implement "extensions" to it?

> hold MS back would be the fact that they've already invested so much
> on C#/.NET. OTOH, they could "pretend" to just support Java openly
> again, and then try steering it back to "well hey C# still does the
> job better than java afterall" later on. the solution to this, i
> think, would be for Sun to simultaneously open-source their JDK's and
> JREs, so everyone can have a hand in Java development as a whole, no
> matter what MS does. (and it would be interesting to see what IBM does
> when this happens)

2) You probably mean the Sun Java VM implementation (including the
HotSpot JIT compiler). Migs Paraz (over an IM conversation I had w/ him)
pointed out that the VM is essentially a software version of a CPU.
Releasing source on the VM is like Intel releasing their complete
microcode. And besides, the Sun Java Community Process pretty much does
what you mean-- allow the community a hand in the development in Java
(hence, the new features in 1.5, mostly due to JCP).

Anyway, the language itself + bytecode specification is pretty much in
the open. 


Microsoft went ahead and sent the CLI and C# specs to ECMA. What's
preventing them from adding more instructions to MSIL? What's preventing
them from improving on .NET and Visual C# to take advantage of those
instructions? Technically, they're still following the standard they
sent to the ECMA.

Heck, the NT line is supposedly POSIX-compliant, another standard.

The standard is there to guide implementors, but really, standards allow
some latitude in implementation. Annex E of the ECMA standard for the
the Common Language Infrastructure gives a list of things an implementor
can touch. For example, Annex E of the CLI ECMA spec says that the
security policy is implementation-specific. What's stopping MS from
implementing a security policy in .NET that breaks, say, code that works
on the Mono implementation? Or changing stuff in the classlib? Or adding
classes pertaining to security? (I.e., Mono and other implementors would
have to play a game of catch-up) 

---
JM Ibanez


The information contained in this communication is intended solely for the use of the 
individual or entity to whom it is addressed and others authorized to receive it.  It 
may contain confidential or legally privileged information.  If you are not the 
intended recipient you are hereby notified that any disclosure, copying, distribution 
or taking any action in reliance on the contents of this information is strictly 
prohibited and may be unlawful. If you have received this communication in error, 
please notify us immediately by responding to this email and then delete it from your 
system. Asia Online is neither liable for the proper and complete transmission of the 
information contained in this communication nor for any delay in its receipt.


--
Philippine Linux Users' Group (PLUG) Mailing List
[EMAIL PROTECTED] (#PLUG @ irc.free.net.ph)
Official Website: http://plug.linux.org.ph
Searchable Archives: http://marc.free.net.ph
.
To leave, go to http://lists.q-linux.com/mailman/listinfo/plug
.
Are you a Linux newbie? To join the newbie list, go to
http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie

Reply via email to