Rob Abbe wrote:

> I can sum up Microsofts "Excellent Support" of it's developers in
> three chars... VB6


Yeah, the Unix/Java community learnt a lot from managed VMs combined
with simple languages such as VB! I can't imagine what sort of spin you
are going to put on the unmitigated success of VB.

>> So let me get this straight. Because MS wanted to use P/Invoke for
>> platform specific native calls, instead of supporting Sun's slow and,
>> ahem, developer unfriendly, JNI, you read this as a "blatantly
>> obvious" strategy to build dependence on Windows?

>
> There was alot more to it that just JNI... RMI for example was
> missing. This is just another example of the embrace extend and
> eliminate that we have seen from Microsoft over the years.


I was responding to Brad's point about calling native platform
functions. Perhaps you can answer that?

You're right that RMI was the other big sticking point. But it's a
similar issue. The contract MS originally signed with Sun in order to
implement a language and runtime, was extending beyond its scope to
define a platform. DCOM and CORBA already provided RPC functionality,
and these are being replaced with standard SOAP web services by the W3C.
The problem was that RMI was limited to Java-the-language in it's
transition to Java-the-platform, and completely controlled by Sun (still
is now, but less so).

Surely, with hindsight, you can understand the politics that were at
play here when Sun maintained tight control over the Java specs? JNI
and RMI extended the scope, effectively leaving MS as nothing but an
implementor of Sun's design. Thankfully, MS didn't roll-over, and we
still have a competitive development environment (.NET vs Java).

>> I don't get it. Why did Sun introduce JNI as a required standard,
>> if by definition, it is for making platform specific native calls.
>> Are you saying that JNI promotes portability because it is slow and
>> cumbersome compared to P/Invoke?!? Either you have a way to call
>> native code or you don't!

>
> It was for making native calls in a common way. I agree it could
> have been better, but that is beside the point. If it's supposed to
> be there to bare the Java brand, then it should have been there.


That is a tautology, not a justification.

>> I guess we disagree on what makes a "platform". For me, Visual Basic
>> and Smalltalk, for example, are languages, even though they also
>> contain a VM runtime. Admittedly it is a difficult distinction to
>> make, but given the scope of J2ME/J2SE/J2EE, and the replacement of
>> Windows platform features under the guise of "portability", Java is
>> effectively a platform itself that is *emulated* on the OSs it runs
>> on.

>
> Java is both platform and language. Java is an abstraction of a
> computer. It understands byte code rather than a specific machine
> language. This is becoming the norm for software plafrorms because
> it ensures binary compatibility of applications as long as the
> platform has been ported to the desired CPU. You still have to
> recompile VB applications to run on a new CPU architecture. Does
> that clear it up?


Nope, its wrong. Theoretically, VB byte codes could run on other
platforms. Robert Scoble likes to remind us that Bill Gates personally
told him that a VB VM for Mac was going to be delivered that would run
VB byte code. It didn't happen, but it was quite feasible. Smalltalk,
on the other hand, does have VMs for many platforms. VB and Smalltalk
VMs pre-dated Java by years. The Delphi/Kylix CLX framework is an
example that doesn't use a VM, and yet provides platform portability,
albeit with a platform-specific compilation step.

There are no doubt many more examples, but you are giving the Java
architecture too much credit. The biggest driver for Java has been wide
industry support on big iron, and justifiably so.

>> No, you are missing the point. C#/CLI != .NET! C#/CLI is a standard
>> foundational language and runtime. .NET is Microsoft's platform that
>> implements that standard, and builds a proprietary platform on top of
>> it. There is no distinction in Java, because Java *is* a platform in
>> it's own right.

>
> No, he's hit it right on the head. Microsoft released the CLR and
> CLI and C# to the ECMA however they control who can implement the
> spec. To be more like Java ASP.Net would and the rest of the
> platform would be released as well and the community would shape the
> future of the platform. Right not Microsoft shapes that future. The
> Java community process is far better.


Well, the ECMA licensing terms for C#/CLI have not been announced yet
AFAIK, but for now we can only assume that they will be "reasonable and
non-discriminatory" as required by the ECMA. So you are wrong to say
that MS control who can implement those specs.

For frameworks like ASP.NET built on the C#/CLI foundation, then you are
correct, and that is what I am saying. C#/CLI != .NET. The ECMA
members (MS, IBM, HP, etc.), will decide what gets added to the C#/CLI
specs..

>> Exactly, choice is important. The standard needs to be limited in
>> scope to foundational elements, in order to promote differentiation
>> in the frameworks built on that foundation. For Java certification,
>> you need to support all the frameworks like Swing and J2EE. Why
>> impose that on implementors if they'd rather implement better
>> alternatives. I don't know if SWT will be successful or not, but I
>> do think that Swing being a standard bundled with every JRE will
>> severely restrict it's adoption.

>
> These things are required to be in place so that you can ensure that
> your Java application will run on a Java certified runtime. Makes
> sense to me. If you use something nonstandard, then it's your
> responsibility to make sure everything required is installed. I want
> to ensure that anywhere a Java platform exists, that my program will
> run. With Java I get this right now. Why would I want it to change.
> If Joe Blow were allowed to create his own Java runtime with the bits
> and pieces he wants then there is no assurance my program will run
> unless I always use his implementation. This is the direction that
> .Net is headed and it sucks!!!!


And this discriminates against SWT, since Sun dictate that every
compliant JRE must support Swing. We were talking about choice, so if I
*choose* to use SWT then I am faced with all the same problems above
that you claim sucks for .NET. Are you promoting choice, or are you
arguing that choice should be limited to implementing Swing APIs?

>> You are a developer, not an end-user. End-user focus, is ultimately
>> more important then Developer focus.

>
> Huh?


I'm amazed you didn't understand that point. Perhaps this is the
dividing line between Java and .NET advocates. My purpose as a
developer is to provide solutions for my end-users, not to satisfy the
needs of my development studio that might contain Windows, Mac, and
Linux OSs.

>> The whole value proposition of Java is based around reducing choice
>> by standardizing the APIs. Sure, you have vendor choice, but the
>> platform is the same for end-users and developers. There is little
>> room for diversity.

>
> This is beneficial for both the customer and the developer. Most
> importantly the customer is not locked into one vendor and is assured
> that their investment will live on if they change vendors. The
> developer need only one set of APIs to leverage a large number of
> vendors platforms. The vendors are free to perform the
> implementation as they choose as long as the interface is compatible
> with the spec. How is this bad? Everyone wins.


Some customers (large enterprises) do care about being locked into one
OS vendor. IME, most small-to-medium enterprises don't care about the
OS vendor, they are far more concerned about being locked into the
solution provider... you!!! Tell them you plan on using .NET/Java, and
they'll nod patiently waiting for you to get to the point ;-)

--
David