Visual J# .NET Released

Goalie_Ca writes: "Visual J# .NET was released at the Tech Ed 2002 Europe Developper conference today. Visual J# .NET is not a tool for developing applications intended to run on a Java virtual machine. Applications and services built with Visual J# .NET will run only in the .NET Framework; they will not run on any Java virtual machine. Download it here; Microsoft J# .Net site."

Re:Market-speak

[Anonymous Coward]

What the hell are you talking about?

"Visual" - used to describe a whole range of Microsoft's developer products, due to the enhanced visual nature of the GUI, as compared to earlier efforts which were text-based (compare gdb to the visual studio debugger, for example)

"J" - Microsoft's interpretation of the word "Java" (compare JScript to JavaScript, for example)

"#" - as used in "C#", meaning the successor to C++. So "J#" is the successor to their "J++" product.

".NET" - their new virtual machine based platform. Compare to old x86-based stuff.

It's really quite easy to decode, I don't understand why you are having such a hard time with it!

Different approaches...

[burnsy]

With Java, one language can create a program that runs on many platforms.

With dotNet, many languages can create a program that runs on one platform.

So what happens if MS decides to create a CLR for other platforms. Than you have many languages that can run on many platforms.

Re:I don't get it...

[Anonymous Coward]

Microsoft Java had a bunch of COM interop stuff in it, which Sun Java does not have. If you happen to have a Java/COM codebase (which was recommended as 'the way' by MS for a short period of time back in 98 or so), this is your migration path.

Of course 99% of the people who went down that path either switched to VB/COM or Pure Java. But at least Microsoft can say they didn't screw ya.

Re:Why .NET ?

[zero_offset]

Yes, you have missed something important, and unfortunately Microsoft marketing is to blame (again). Indeed a great number of MS programmers have missed it too, so you're not alone. Remember when .NET was called Next Generation Windows Services (NGWS)? Probably not, but it was for at least two years' time. NGWS is what's important about .NET.

This web services crap was basically smoke-and-mirrors. As someone else pointed out earlier in this topic, if MS or somebody else writes a CLR, suddenly, "Windows" programs will run on other operating systems without so much as a recompile. Given the DOJ problem which was looming large around the same time as the .NET unveiling, I think the "look at our web services" smoke-and-mirrors tactic intentionally diverted attention away from this potential portability option. Indeed, the portability concept was so important in their design phase, MS went as far as to segregate a great deal of highly-Windows-specific functionality in classes with names like Microsoft.xxxx (although this comprises only a tiny fraction of the full .NET model).

Don't get me wrong -- I like SOAP and have pushed for it (and used it, and early derivatives) inside my company for years -- but comparing .NET to "web services" is like comparing your desktop computer to one of those e-mail appliances for the computer illiterate. Sure it CAN do those things, but it's only a small fraction of the real story.

The .NET system object model is a top-down redesign of practically every part of the Windows API. Win32 is gone, GDI is gone, even COM/DCOM is gone (although still accessible). Instead you have this fantastically consistent MASSIVE system object model. Programming against this thing is pretty great. There are a few holes and a few decisions which strike me as stupid, but when you're talking about thousands of classes, everybody is bound to have a few pet peeves.

Unfortunately, it's hard to put an exciting marketing spin on a great new system-wide API strategy, and as I mentioned I don't think they wanted to play up the portability aspect at all, so we end up with the vague .NET marketing-speak hype machine.

There are other important and useful things in .NET, too, but to me the new comprehensive (and consistent) system object model is by far the most important (did I mention it was consistent?). People who compare it to Java either haven't compared them in-depth, are extremely Java-biased, or simply don't know what they're talking about. But that subject has been discussed to death in great detail all over the 'net, just search for it. (BTW, I was a professional Java programmer for over two years -- I'd say Java is merely "OK", not great -- I mention this as evidence that I'm not simply a MS-centric anti-Java nutcase, I did use it to make a living, for awhile.)

I think if .NET fails to gain momentum, it will be a great loss. Beyond the crappy marketing spin that seems to bury anything MS manages to do well, I think Microsoft itself may accidentally kill interest in .NET by only shipping it to the Great Unwashed as part of some new DRM-nazi consumer-unfriendly Windows -- call it WinDisney.

But from a purely technical perspective, .NET is pretty great.

Re:Different approaches...

[turgid]

Many languages have compilers which target, or interpreters which run on, the JVM. Google is your friend.

The definition of "Open source"

[melquiades]

Remember, open source just means the source is open for you to see and use, examples being the Microsoft Shared Source license

Wrong.

The definition of "open source" [opensource.org] includes several important points beyond simpy allowing people to see the code. Microsoft's insulting "Shared Source" license fails several of these points.

Most notable is free redistribution. As the OSI puts it:

The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.

Other notable trouble points with MS "shared source" include the OSI conditions of no discrimination against persons or groups and non-restriction of other software.

Here's the answer

[GCP]

J# isn't meant to run on a JVM. It's just one of the .Net family of languages.

All .Net languages are compiled to the same "bytecode" that MS calls MSIL. J# is no exception. It is compiled to MSIL, not to Java bytecode.

Whether you prefer to write your source in Java (using J#), or C#, or VB.Net, or Perl.Net, or whatever, the source gets compiled to the same MSIL.

The MSIL code then runs on the .Net framework in a thing called the "common language runtime", which is similar to a JVM, but designed from the start to *try* to accommodate as wide a range of source languages as possible.

After they become MSIL, they are completely interchangable, regardless of their original source language. You could grab a cool C# utility class off the Web somewhere and use Java "extends" to write a subclass in Java. If you find it easier to parse text with Perl than with Java (who doesn't?), then you could write just the text parser classes in your Java app in Perl.Net.

The idea is that you get to work in a source language that you choose. Unlike the Java world, .Net doesn't limit you to doing everything in a single language. (However, it *does* currently limit you to Windows only, quite unlike Java, but that's changing quickly. [go-mono.org]

The point of J# is to let Java lovers use Java to create .Net applications. When Ximian's Mono Project [go-mono.org] is fully up and running (Go Mono!), the MSIL output from J# will become executable on a Linux box. When that happens, a Java programmer who wants to deploy on Linux will suddenly have two excellent class frameworks to choose from: the Java standard and .Net.