j#.not

[Brad O'Hearne]

As a developer who started professionally in the Microsoft world, and using
J++ and COM/COM+ and shipped a commercial product during the time when MS
basically dumped Java, and am now an experienced Java developer, I have some
direct experience in the evolution of Java in the MS world.

First off, it should probably be outright stated that J# is not a destination...it
is a bridge. Bringing Java developers to J# is not the intended end of the
road -- C# is. J# is nothing but the "bait" in a "bait and switch". This
is Java vs. C#, or more appropriately, MS's new angle on owning the Java
market that they couldn't own by bastardizing the Java platform specifications.
This brings me to my next point.

In his article, Russel Jones writes:
"Sun has, for years, gone out of its way to ensure that Java doesn't interoperate
with COM—in fact they went to court to enforce that isolation. Years later,
Java still doesn't interoperate with COM. By following Microsoft's lead,
Sun is also attempting to ensure that "You can check in, but you can never
leave."

This is patently untrue. There is nothing the Sun has done to prevent interoperation
with COM, or for that matter, other languages, as they have provided the
Java Native Interface (JNI) as a bridge to other languages. And for those
that want to try to classify JNI as some fringe API not often used, they
might want to consider the fact that large parts of all JDK's direct from
Sun rely heavily on this API. In addition, MS could have developed a COM-Java
API using JNI day one, but they didn't. In fact, until just recently, SQL
Server was about the only database that didn't have a vendor-developed pure
Java JDBC driver for it, which is an obvious display of the desire to integrate
with Java. In addition, it is absurd to think that Sun would dump development
effort into integrating a non-Java technology the competed with EJB (and
is arguably quite inferior to it as well) -- this would naturally be the
responsibility of the vendor of COM (MS), who apparently had no interest
in doing so (actually, the funny thing is that they already did this in the
form of COM-wrappers in J++, but rather than extend this technology to the
dev community in the form of an API, they just dumped J++ when the Sun-MS
lawsuit emerged -- I know about that one -- my dev group in 1998 had to do
a complete rewrite of our product in C++ one month after shipping our GA
code due to MS dropping Java-COM support).

But the most outlandish claim from Jones is that Sun "went to court to enforce
that isolation." Nothing could be more untrue. Sun's quarrel with MS was
based on the fact the MS tried to violate the Java specification by injecting
its own proprietary changes, and thereby defeating one of the primary (if
not the primary) tenets of the spec, which was platform portability. Java's
accommodation of multiple platforms is a testament to having all OS communities
embrace the product -- it is MS that seeks isolation of Java on its platform
of Windows only. This is clearly evident in MS's latest move of "Java apps
that will run only in .NET". This is another attempt to screw with the Java
spec.

The question of whether developer's would care for a version of Java that
worked only on .NET is moot -- read the Java specs -- such a language isn't
Java.

Again, another point of Jones:
"Sun ignores its developers' need to write robust native Java desktop applications".

Not so -- heard of Swing? For all the trashing it gets, the number one development
IDE for Java several years running just happens to be a pure Swing app (JBuilder),
and I personally am part of a team developing our mission-critical GUI in
pure Swing. While Swing has understandable overhead, it is more than sufficient
for a rich-featured GUI, and better yet, it is portable.

And finally, from Jones:
"Today, developers are faced with an unpalatable choice: One language for
all platforms or one platform for all languages."

This is a gross over-simplification of the reality. The real issue includes
these:

1)Implementation vs. specification.
2) Single vendor vs. multi-vendor.
3) Single choice vs. Best-of-breed.

These are huge issues that Jones completely overlooks. The implications
of these:
1) MS delivers full proprietary closed implementation of its products, while
Sun delivers specifications which must be followed for compliance, but can
be flexible based on implementation needs.
2) The MS way puts all your eggs in one basket...whereas there are vendor
alternatives using Java.
3) Because of 1), there are no choices the MS way, but you are given a best-of-breed
choice using Java.

The two communities are entirely different. Everyone needs to wake up and
smell the coffee. J# is a marketing stunt, and a migration path to C#.

[Mark Hurd]

"Brad O'Hearne" <brado@neurofire.com> wrote in message
news:3bd126a0$1@news.devx.com...
><snip>
>
> The question of whether developer's would care for a version of Java that
> worked only on .NET is moot -- read the Java specs -- such a language isn't
> Java.

This is what I've always seen as silly. There is no reason why a language has
to be tied to an implementation (except when you've signed a contract that
says you'll do just that).

That an entity that designed a language also had a goal to design an
implementation spec that makes it straightforward to target any system is a
good idea, but the language is a good OO language in its own right. (Is there
anything about the *language* that was clearly chosen due to the platform
indepence goal?)

The language and its virtual machine (computer science term) is separate from
an implementation.

If I produce an open source C runtime library that is structured so that it is
very clear that if a specific implementation passes a well-defined suite of
tests then the implementation will produce the same functionality, I then have
achieved the same goal, except the language is not OO.

I might add that part of the problem is the user interface look and feel that
must be the lowest common denominator. If there is an X widget and a Windows
control that don't have equivalent objects in another windowing system, then
should they be ruled out of Java programs?

Just like most multi-platform projects, the answer will be to conditionally
compile for each platform. And if your going to allow this for GUI
differences, why not allow it for other differences?

This is where the obvious alterative of not allowing any differences fits in,
but it is a design choice, not something that is tied to the language.

In other words, platform independence implies Java (or extra work and worry)
but Java should not necessarily imply platform independence if that is not a
goal of your project.

However I am confused. I thought C# existed because Java was not available.
How can MS get past the contract they were held to in the previous Sun vs. MS
court case?

( Also, if J# was coming, could it have been the bridge between C++ and
VB.Net? Then VB.Net could have had all of the features C# has got that VB.Net
ought to have too... :-) )

Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)

[Aaron Sevivas]

I agree with some of what u said but :

>Again, another point of Jones:
>"Sun ignores its developers' need to write robust native Java desktop applications".
>
>Not so -- heard of Swing? For all the trashing it gets, the number one
development
>IDE for Java several years running just happens to be a pure Swing app (JBuilder)

Jbuilder from, I believe 4.0 and up is java swing, earlier versions were
c++. And if you use it, it works fine, but u can't compare it to Ms' Visual
Studio ide as far as performance. Many believe the performance of Jbuilder
is great because they have become accustomed to using it (I have been using
it every day, 9-5 for the past 6 months and i agree, the performance is acceptable).
but if you do a side by side comparison between JBuilder and MS VS, JBuilder
hasn't a chance.

>And finally, from Jones:
>"Today, developers are faced with an unpalatable choice: One language for
>all platforms or one platform for all languages."
>
>This is a gross over-simplification of the reality. The real issue includes
>these:
>
>1)Implementation vs. specification.
>2) Single vendor vs. multi-vendor.
>3) Single choice vs. Best-of-breed.
>


>These are huge issues that Jones completely overlooks. The implications
>of these:
>1) MS delivers full proprietary closed implementation of its products, >while
>Sun delivers specifications which must be followed for compliance, but can
>be flexible based on implementation needs.

OR.. Microsoft black-boxes its implementations, assumes responsibility for
source code and allows the developer to worry about business needs whereas
Sun allows individual coders to break working implementations by creating
white-box dependent inheritence schemes with distributed classes.

>2) The MS way puts all your eggs in one basket...whereas there are vendor
>alternatives using Java.

I agree that as far as app servers, MS gives us very little choice, but the
supported languages the CLR supports are in the hundreds. The CLR is MS but
you can choose from hundreds of vendors for your language/ide s..

>3) Because of 1), there are no choices the MS way, but you are given a best-of-breed
>choice using Java.

Client/server using java.. Client is written in ? Server is written in ?
Unless your using your own cooked up protocol or SOAP, its Java. No choice
there.

>J# is a marketing stunt, and a migration path to C#.

true

my $.02

~aaron