The Demise Of J#

There was a very interesting announcement at the Microsoft Visual J# Page … to the effect of the immediate retirement of J#.

I can’t say I’m surprised really. The lack of properties was always going to be a headache. Plus Microsoft didn’t seem all that fond of Visual J# either — there was no support for Compact Framework applications, for instance, and all code examples are invariably C# then VB.NET.

Still, at least it got a presence in the Visual Studio IDE, which is more than I can say for JScrpt.NET

  1. Who on earth users JScript.NET
  2. WHY do you use it?

Some time back i thought it was being positioned to be the bash scripting equivalent but PowerShell superseded that.

But I digress … back to J#

The only reason i looked at it, other than curiosity, was access to is  libraries, such as java.util.zip that was not directly in the framework. I was also giving serious thought to checking out the equivalent of applets, but with WPF/E, I don’t think I’ll bother.

What is interesting about the announcement is the wording:

Since customers have told us that the existing J# feature set largely meets their needs and usage of J# is declining, Microsoft is retiring the Visual J# product and Java Language Conversion Assistant tool to better allocate resources for other customer requirements. The J# language and JLCA tool will not be available in future versions of Visual Studio. To preserve existing customer investments in J#, Microsoft will continue to support the J# and JLCA technology that shipped with Visual Studio 2005 through to 2015 as per our product life-cycle strategy

Take especial note of the bold section (emphasis mine). This has got to be the most ludicrous thing I have ever read. The word audacity comes to mind. This is clearly an attempt at spin. Such sentiments would be at home with the following

We’ve stopped refining penicillin because customers have told us that penicillin largely meets their needs — Alexander Fleming

We’re sticking to bleeding because customers have told us that it largely meets their needs. — Medieval nun

We’re sticking to horse and carriage because customers have told us that it largely meets their needs — Medieval cab driver

Whoever wrote that announcement should have just cut to the chase

Visual J# is a pain in the caboose. Really. Much as we have guys who can write hello world applications in J# on campus, both of them have moved to the Microsoft Bob team. It tortures our souls to even type import java.io.*. The C# team plays nasty pranks on the J# team, like removing the space bars from their keyboards, or sneaking in at night, uninstalling J# and installing Java 1.6.

We are tired of having J# compared to Java, and being asked if it supports Java 1.6 features, dammit! And in this regard we are summarily pulling the plug, printing out the source code and summarily shredding it.

 

kick it on DotNetKicks.com

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • blogmarks
  • co.mments
  • del.icio.us
  • digg
  • Fark
  • feedmelinks
  • Furl
  • LinkaGoGo
  • Ma.gnolia
  • NewsVine
  • Reddit
  • TailRank
  • YahooMyWeb
 

Other posts

4 responses


  1. Well, it’s about time. J# drools, IKVM rules, at least server-side (there’s only very limited support for any kind of Java-style windowing, since they are all built on AWT ultimately). IKVM allows you to compile Java code into .NET/Mono assemblies, or to run Java bytecode directly at runtime (it’s JIT-compiled into CIL first).


  2. FYI, I *like* JScript.Net.

    1. It’s good for simple scripting, and trivial to embed in your .Net application. If you want to offer users the ability to script your system, JScript.Net is an easy solution.

    2. It’s the only .Net language that supports eval(). (Well, IronPython probably supports it now, along with some third-party languages. But it’s the only one in the SDK.) This makes it useful for all sorts of things.

    3. I like it for shell scripting and running a simple interpreter in a command window.

    Certainly, no one is likely to compare C# and JScript.Net and decide to write a full-blown windows or web app in JScript. But that’s not really what it’s for. It’s useful because it’s different from C#. By contrast, J# is basically just a very close cousin of C#, which makes it hard to differentiate them.


  3. For one of my clients, I converted several Java libraries from a third party into a J# project to integrate them with my C# project. Without J#, Java Language Conversion Assistant, and tlbimp, I would have had to rewrite the third-party code in C# by hand.

    Actually, after further reading, it sounds like they’ve only retired J# from Visual Studio… so maybe the Java Language Conversion Assistant will still be available separately, and Visual J# Express may still be around, too.

    I’m guessing “customers have told us that the existing J# feature set largely meets their needs” is in reality more like, “If we profit from J#, Sun’s lawsuits against us carry more weight, but Visual J# Express is free.”


  4. Funny 2 2=5 for large values of 2
    Which one? or is that the joke?

One trackback

Leave a Reply