22 March 2007
J# retired and I just now caught this! That's wonderful news!
From the announcement (http://msdn2.microsoft.com/en-us/vjsharp/default.aspx), the following:
Retirement of J# language and Java Language Conversion Assistant from future versions of Visual Studio 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. For more information, see Expanded Microsoft Support Lifecycle Policy for Business & Development Products.
Now of course, there are some issues. Apparently they've introduced 64 bit support and that ends in 2017. So if nothing else, we have 2 (conflicting) dates: 2015, or 2017.
Bah. Either way, we'll be rid of it within a decade :-)
To read the announcement, you'd think they're being burdened by it! Which is true. They are. As they are burdened by maintaining the VB6 to VB.NET migration pathways. And the C++ to managed C++ pathways. If .NET debuted with anything in particular as gospel, it was "forward thinking, backwards compatible." Now it seems like they're abandoning a lot of this for the pretense it was. I still don't quite understand what their pitch to the java world is though. The Petstore(s), I don't think, swayed any opinion. This is especially true given what was perceived to be botched politicking on Microsoft's part behind the first one. Is there anyone who actually used Java and then preferred having Visual Studio wizard-away everything previously done in ant build file? That is, who would switch to get WYSIWYG-everything?
The main cause for defection in the Java camp is ease-of-use, but those concerns are (seemingly) better addressed by Ruby on Rails, or PHP.
Or, it could be I'm missing everything all together.